Skip to main content

After vSphere 4.1 – what will be going

vSphere 4.1 has been out for a couple of days now.

As well as the new features which have been covered extensively (see What’s New), the release notes list some future changes for the product range. They’re not really hidden but haven’t been given much publicity.

  • ESX will be dropped in future releases, with ESXi being the hypervisor product for vSphere.
  • Future versions of vCenter Update Manager will not scan or remediate guest OSes. I presume the cross-licensing costs of using Shavlik were outweighing any benefit. UM will continue to scan and update ESXi hosts. and presumably aid in conversion of ESX hosts to ESXi.
  • VMware vCenter Converter plugin and VMware vCenter Guided Consolidation are also going away in future versions. Converter will continue in a standalone format rather than a vCenter plugin.
  • Web Access isn’t available on ESXi so that’ll be going away when ESX is dropped too

There are a few other items being dropped such as support for some versions of Linux in guests, VMI paravirtualization support, and MSCS in Windows 2000 but they aren’t as widely used.

VMware,

Passing info from PowerCLI into your VM using guestinfo variables

For a project at work we’ve been trying to pass information into a VM without connecting the VM to the network.
This is in order to set up some config within both Windows and Linux VMs. We decided to explore the use of GuestInfo variables which are held in memory in VMware Tools within the Guest VM, but which can be set from the host.

From the ESX Service Console of the host you can use
vmware-cmd <cfgfile> setguestinfo <variable> <value>
 to set a value and vmware-cmd <cfgfile> getguestinfo <variable> to read the value. Note that you don’t need to use the “guestinfo.” prefix when using these commands.

Within the VM guest OS the values can be set/read using:
(Windows)
vmtoolsd.exe --cmd "info-set guestinfo.<variable> <value>"
vmtoolsd.exe --cmd "info-get guestinfo.<variable>"(vmtoolsd.exe is usually in C:\Program Files\VMware\VMware Tools)

(Linux)
vmware-guestd --cmd "info-set guestinfo.<variable> <value>"
vmware-guestd --cmd "info-get guestinfo.<variable>"(vmware-guestd is usually in /usr/sbin)

It wasn’t immediately obvious where the guestinfo variables live with regard to the PowerCLI vmConfig properties. Googling didn’t reveal much useful info, so I though I’d try the wonders of new technology and use Twitter. I’ve been following Carter Shanklin of VMware on Twitter since I attended a London UK VMware User Group meeting a couple of months ago, and as he’s the Product Manager for PowerCLI and the SDK, I thought I’d ask.

He quickly pointed me at the VMware SDK documentation for the ConfigInfo object and the extraConfig object in particular.

A bit of further reading led me to some experiments let me to try the following code:
$vmConfigSpec = New-Object VMware.Vim.VirtualMachineConfigSpec
$extra = New-Object VMware.Vim.optionvalue
$extra.Key="guestinfo.test"
$extra.Value="TestFromPCLI"
$vmConfigSpec.extraconfig += $extra
$vm = Get-View -ViewType VirtualMachine | where { $_.name -eq "MyVMName" }
$vm.ReconfigVM($vmConfigSpec)
That will set the guestinfo.test property to “TestFromPCLI”. Once that’s been set it can be read by the VM.

The guestinfo property can have multiple Key/Value pairs so you can pass quite a few variables through to a VM. These can only be set when a VM is powered up and running VMware Tools as the value is stored in the VMs memory, and as far as I can tell, the contents are lost when the VM reboots.

However, there is another extraConfig object which can also be set which is the machine.id. Again this can be read from within the VM (replace guestinfo. with machine.id in the above code snippets), but this one gets written to the VMs VMX config file and will thus survive reboots.

You could squish several bits of info into that one object/variable, for example a unique identifier and the VM name so that the VM can self-configure.

VMware,

Unable to upgrade from Virtual Center evaluation license

I encountered a problem with Virtual Center (VC, vCenter) 2.5 Update 4 where trying to change from the evaluation license to a proper license server resulted in a message that there were “Not enough licenses for this operation”.

There were various suggestions on the web, mostly involving stopping and starting the Virtual Center and License Server services. None of them worked. The only other suggestion was to remove all the hosts from the Virtual Center, add the license, then re-add the hosts back in. This would lose any nice filing of VMs in the “Virtual Machines & Templates” view, and would generally be a bit of a pain.

As a last resort, I thought I’d have a Google round for possible registry settings which may affect licensing.

I found a blog posting about changing the license type that VC looks for within the registry, which also mentioned a “LicensePath” key.

Looking in the registry of my VC server there was no “LicensePath” key, so I created one, stopped and restart the Virtual Center service and found that VC now found the license server correctly and didn’t complain about “Not enough licenses”.

So to recap, open regedit, navigate to
HKEY_LOCAL_MACHINE\SOFTWARE\VMware, Inc.\VMware VirtualCenter

Create a new String key calledLicensePath and enter the info for your license server, e.g. 27000@vc01.example.com

VMware, ,

Hostname/IP bug in ESXi 3.5 Update 3

Last week I was working on an HA cluster of VMware ESXi hosts.

Whatever I tried I couldn’t get the hosts to play nicely when HA was turned on. Further investigation showed that the hosts were resolving their own names to a previous IP address.

Checking the console on each host showed the correct information, but the error messages when turning HA on indicated that they were still resolving to their old incorrect addresses.

The usual problem with HA is that DNS records don’t match what is actually set up, but in this case DNS checked out fine.

It would appear that:

  1. ESXi uses a local ‘/etc/hosts’ file for resolving names in preference to DNS. You can view this file by pointing a browser at http://youresxservername/host/hosts
  2. The local hosts file doesn’t get updated when you change the settings using the console interface. It keeps whatever was in there the first time you set up the hostname and IP address for the host

Most of the time this doesn’t matter much as the host doesn’t often need to look itself up, but when VMware HA is turned on, name resolution becomes much more important.

There are two ways to edit the /etc/hosts file. Because ESXi doesn’t have a normal Console Operating System (COS) that full ESX enjoys, both methods are relatively awkwards.

  1. Use ‘unsupported’ mode to get a local root shell and edit using ‘vi /etc/hosts’
  2. Use the Remote CLI to change the file remotely.
    1. vifs.pl –sessionfile <yoursessionfile> –get /host/hosts C:\temp
    2. Edit the file with notepad
    3. vifs.pl –sessionfile <yoursessionfile> –put C:\temp\hosts /host/hosts

With that done HA started working again. Probably worth doing a reboot just to make sure it’s ‘taken’.

VMware, , , , ,