vm

Changing DNS on Azure IaaS VM’s NIC forces RDP / network disconnect

by

I  just noticed this happen to a VM I was connected to this evening.

All I did was change the primary DNS from automatically assigned to manual, gave it a DNS server IP, and provided a backup secondary IP, and my RDP session was instantly dropped. Other HTTPS traffic to the box stopped too.

I had to restart the VM in Azure to get connectivity back. This VM was deployed using the classic portal, but I’ve seen reports of it happening on newer ARM deployed VMs too. Here’s a thread with others that have found the same issue.

Hopefully Microsoft will resolve this soon.

Fix for VM console error – unable to connect to the mks the operation is not allowed in the current state

by

Bit of a strange one this – I have not dug deeper to find the root cause, but here is a quick fix for anyone with the issue.

mks-console-error-vm

 

I found we could not open VM console sessions in a vCenter 5.5 environment today. Usually one’s first thought is that it is a DNS or port issue when you see the classic MKS console error in a VM, but in this case I knew that DNS and ports were not an issue, as RDPing direct to the vCenter Server itself, logging in with the C# client and opening VM consoles from there were giving the exact same message. This was the case for the web client as well as the C# client.

The issue was either with the host that VMs were running on, or with the VMs themselves – the simple fix:

vMotion the VM to another host. As soon as this was done, I could open the console session. The underlying issue is still out there, but I have not had the time to dig any deeper to find out the root cause. More discussion and info available from this VMware communities thread: https://communities.vmware.com/thread/450294

Solving VMware Fusion 6 and Windows 7 VM performance issues

by

I have been struggling along with various VM performance issues over the last couple of months using VMware Fusion 5.x, as well as the latest 6.0.3. I just didn’t get the time to dedicate to find a fix for the performance degradation I was seeing until just recently.

I have the following specifications on my Macbook Pro Retina which I use for development purposes:

macspec1

I have a Windows 7 Professional VM running in VMware Fusion, with a spec that I had tried all kinds of different configurations on – mainly 2 vCPUs, and 4GB RAM though. This VM is running on the built-in 256GB SSD.

Nothing seemed to fix the performance issues I was seeing, which was that by at least half way though a typical work day of using Visual Studio and a few tabs of Chrome/IE/Firefox, the VM would slow down to an absolute crawl. I knew it was the VM though, as everything in OSX Mavericks, the host OS was perfectly normal. Most of the time just restarting the Windows VM itself would not help though – I would have to reboot the whole macbook.

The other week I decided enough was enough, and spent a bit of time googling and looking around the VMware Communities forums for a fix. Here is the combination of settings that seems to have resolved my issues now.

  • Settled on a VM spec of 3 x vCPUs (helpful for Visual Studio), and 4GB RAM.
  • Disabled app nap for VMware Fusion (Applications -> Right-click, Get Info on VMware Fusion, and tick the box that says “Prevent App Nap”.
  • Added 3 x new entries into my VM’s configuration file (.vmx file). To edit the .vmx file you’ll need to right-click your VM and select “Show Content”. This will allow you to browse the file content of the VM, and you’ll need to locate your VM’s .vmx file. Right-click this file and open it in your text editor of choice. I added the following lines to the bottom of the file:
MemTrimRate = "0"
sched.mem.pshare.enable = "FALSE"
prefvmx.useRecommendedLockedMemSize = "TRUE"

Don’t forget to disable App Nap for Fusion.

prevent-app-nap
Disable app nap for Fusion

Three PowerCLI scripts for information gathering – VMs, Hosts, etc

by

 

I was on a vSphere upgrade review engagement recently, and part of this involved checking hardware and existing vSphere VI was compatible with the targeted upgrade.

To help myself along, I created a few PowerCLI scripts to help with information gathering to CSV for the VI parts – such as Host Versions, build numbers, VMware tools and hardware versions, etc… These scripts were built to run once-off, simply either by copy/pasting them into your PowerCLI console, or by running them from the PowerCLI console directly.

They can easily be adapted to collect other information relating to VMs or hosts. To run, just launch PowerCLI, connect to the VC in question (using Connect-VIServer) and then copy/paste these into the console. The output will be saved to CSV in the directory you were in. Just make sure you unblock the zip file once downloaded if you execute them directly from PowerCLI, otherwise the copy/paste option mentioned above will work fine too.

There are three scripts bundled in the zip file:

  • Gather all hosts under the connected vCenter server and output Host name, Model and Bios version results to PowerCLI window and CSV
  • Gather all hosts under the connected vCenter server and output Host name, Version and Build version results to PowerCLI window and CSV
  • Gather all hosts under the specified DC and output VM name and hardware version results to PowerCLI window and CSV

Short and simple scripts, but hopefully they will come in handy to some. As mentioned above, these can easily be extended to fetch other information about items in your environment. Just take a look at the way existing info is fetched, and adapt from there. Also remember that using | gm (get-member) on objects in PowerShell is your friend – you can discover all the properties and methods on PowerShell objects by using this, and use those to enhance your reports/outputs in your scripts.

[wpdm_package id=’2025′]

 

VM provisioning from e-mail using Python and the VMware Perl SDK

by

This is a bit of a fun project that I did as a part of my presentation of the vPi project. It doesn’t necessarily achieve anything useful (at least not on the surface), but it does demonstrate some techniques that could be put to far greater use.

 

vpi-provision-script

 

In summary, this integration turns e-mails from people into Virtual Machines on a vSphere environment. It consists of the following components:

  • Raspberry Pi running the vPi image
  • Python script
  • VMware Perl script (vmcreate.pl) + a bit of XML used for the VM template.
  • VMware Perl script (vmcontrol.pl)

The way it works, is a Gmail mailbox is setup to capture e-mails sent to a specific e-mail address. The Raspberry Pi runs a Python script that logs into Gmail, and looks for any new e-mail that has arrived. If an e-mail is found, it takes the FROM address and splits it up into components, determining the sender’s first and last names.

The script then opens up the XML template file that the vmcreate.pl script uses as a basis to creating VMs, and searches it for a bit of bespoke text we placed there called “TEMPLATE_NAME”. Once found, it strips this out and replaces the TEMPLATE_NAME with the sender’s name.

We then move onto the next procedure, which involves invoking the vmcreate.pl script from the Python script, passing it in the parameters required (such as the server to connect to, credentials, and the all important XML template). This runs against the vSphere environment in question, and creates a VM named after the e-mail sender, (appending a random string of text and numbers to the end to ensure that multiple e-mails from the same person do not cause an issue with duplicate named VMs).

Once the VM is provisioned, the Python script invokes the vmcontrol.pl script using the name of the VM we just provisioned to power the VM up. Lastly, the Python script sends an e-mail back to the sender, stating that their VM has been created and powered on. After that, voila! You will have a new VM created and deployed in your Datacenter all triggered from a simple e-mail.

vpi-example

The script files required + XML and XML schema files are available for download below. The main python script is fairly lengthy, so I won’t include the content direct on this post. Just download the file to grab everything.

Notes to get the script up and running:

  • I found the vmcreate.xsd (XML Schema file) for the VMware vmcreate.pl script did not work, so I had to modify it to change some of the property names to match those of which the vmcreate script was expecting. My updated version is included in the download below if you get any errors from the vmcreate.pl script. It’s default location is: /usr/lib/vmware-viperl/apps/schema
  • You will need to find and edit some variables in the main Python script – your mailbox name and password, plus the IP, username and password for the vmcreate.pl and vmcontrol.pl perl script calls.
  • In the vmtemplate.xml file you should define the characteristics of your VMs that are created. GuestOS, Disk size, etc… Of particular importance, is the name of your host to deploy to, Datacenter name, Datastore name to deploy to, and default VM network to use. These are all of course unique to your own environments.

 

[download id=”26″ template=””]
 
[download id=”27″ template=””]

 

Once you start to think of other ways of using this, you can begin to imagine some really great (and even crazy) solutions. As a start, it would be quite easy to begin extending this, so that e-mails undergo some sort of validation first. E.g. does the domain the sender sent from exist in our “Whitelist” of people allowed to provision e-mails, or does a specific “password” required exist in the body of the e-mail etc…

How about having a standard e-mail template, where the sender can specify more details, such as vCPUs, RAM, disk sizes, OS to install? You could then provision from VM templates instead of creating new VMs, that have customization specs attached. Once powered up and provisioned, a script within the VM could be initiated to accept parameters the VM was created with, and use those to send the requestor an e-mail to say “Hey! I’m now ready for you to connect, and here is the IP you can use…”.

 

Of course, this is not limited to vPi and the Raspberry Pi – that was just the platform I demonstrated this on. Being standard SDKs and scripting languages, you could use the above solution anywhere.