Skip to main content

vSphere: Attempting to add NFS datastore – “Error performing operation: Unable to create object, volume Name not valid”

We’ve had this error on ESX 3.5 and 4.0 hosts, both ESX and ESXi.
When trying to add a new NFS datastore we get the above error message, both in the vSphere Client and when using the command-line tools.

Logging on to the Service Console on an affected host, “esxcfg-nas -l” also results in the same error.

The cause is invalid entries in the /etc/vmware/esx.conf file. Fortunately, it seems to be possible to remove the bad entries and the host then starts working properly without a reboot.

In our case, the bad entries looked like:
/nas/./enabled = "false"
/nas/./host = "1"
/nas/./share = "0"
whereas valid entries are recognisable:
/nas/vmdesktop/enabled = "true"
/nas/vmdesktop/host = "10.0.0.100"
/nas/vmdesktop/readOnly = "false"
/nas/vmdesktop/share = "/vol/vmdesktop"

As I mention above, fixing it on ESX isn’t too hard, just edit /etc/vmware/esx.conf using nano or vi as root, being careful not to affect any other lines.

On ESXi, it’s a little more tricky as you can’t readily log on and edit files without enabling Technical Support mode.

It is, however, possible to edit esx.conf via the Remote CLI (Linux or Windows) or using the vMA.

Below are some example commands which grabs the esx.conf file, edit it using ‘sed’, and then put the altered file back on the host.

vifs -get /host/esx.conf work.conf
cat work.conf | sed -e '/\/nas\/\./d' > fixed.conf
vifs.pl -put fixed.conf /host/esx.conf

The ‘sed’ command will probably need to change for you, depending on what the invalid lines look like. You can just use nano or vi on Linux or the vMA to do the edit, but if you’re using Windows you may find that Notepad and Wordpad either don’t display the file clearly or convert the line endings from Unix format to DOS. Using the free VIM for Windows (http://www.vim.org/download.php) will let you keep the file in the same format.

After making those changes, it was possible to add NFS datastores as normal.

VMware, , , ,

Add multiple datastores to multiple vSphere hosts

In large vSphere environments it can be very tedious to add multiple NFS datastores to lots of hosts.
PowerCLI comes to the rescue as usual.

I needed to add some datastores to all the clustered hosts in a single datacenter, but to skip our non-clustered standalone hosts which are used for backups.

A bit of PowerCLI which should be fairly self-explanatory:

  1. #
  2. #  Add Datastores to all hosts in all clusters in a specified datacenter
  3. #  If a host isn't in a cluster it won't get the datastore
  4. #  Easy enough to change to do all hosts in a datacenter, all in vCenter etc
  5. #
  6. #  Change the value below to point it to your own vCenter
  7. $myvCenter = "vcenter.example.com"
  8.  
  9. # Array of arrays below holds NFS-hostname, NFS-path and Datastore name, should be easy to add to
  10. $nfsArray = @(
  11. 			  @("nfsserver1","/vol/nfspath1","VMstore1"),
  12. 			  @("nfsserver2","/vol/nfspath2","VMstore2"),
  13. 			  @("nfsserver3","/vol/nfspath3","VMstore3")
  14. 			 )
  15.  
  16. $datacenter = Read-Host -Prompt "Datacenter name"
  17.  
  18. Write-Host "Datacenter is $datacenter"
  19.  
  20. connect-viserver -server $myvCenter
  21.  
  22. #
  23. # Get all hosts in all clusters in the named datacenter
  24. $ObjAllHosts = get-datacenter -name $datacenter | Get-Cluster  |  Get-VMHost 
  25.  
  26. ForEach($objHost in $ObjAllHosts){
  27. 	ForEach($nfsItem in $nfsArray) {
  28.  
  29.       Write-Host "Adding datastore" $nfsItem[2] "with path" $nfsItem[0]":"$nfsItem[1] "to" $objHost
  30.       New-Datastore -Nfs -NfsHost $nfsItem[0] -Path $nfsItem[1] -Name $nfsItem[2] -VMHost (Get-VMHost $objHost)
  31.     }
  32. }
  33. disconnect-viserver -server $myvCenter -Confirm:$false
VMware, ,

vSphere 4.1 ESXi Installable on USB?

Looking at the ESXi Installable Setup guides for 4.1 and 4.0 reveals a change. In 4.0 under System Requirements, a USB drive was listed as a possible boot device, as well as being usable for installation. So you could stick in your installation media and select USB as the destination.

Under 4.1, USB is no longer listed in the documentation as a bootable device, though boot from SAN devices via HBAs is now supported.

I’ve not checked whether you can actually install ESXi Installable 4.1 to a USB drive. It may well be possible, but I suspect it’s dropped off the “Supported” list of options.

The only reason I can see to drop support for putting Installable onto USB is to encourage people to purchase and use ESXi Embedded from their hardware supplier instead.

**UPDATE 2nd March 2011**

VMware have posted a clarification Knowledgebase article about the support for USB and SD for booting ESXi.

You can install ESXi 4.x to a USB or SD flash storage device directly attached to the server. This option is intended to allow you to gain experience with deploying a virtualized server without relying on traditional hard disks. However, VMware supports this option only under these conditions:
  • The server on which you want to install ESXi 4.x is on the ESXi 4.x Hardware Compatibility Guide.

    AND

  • You have purchased a server with ESXi 4.x Embedded on the server from a certified vendor.

    OR

  • You have used a USB or SD flash device that is approved by the server vendor for the particular server model on which you want to install ESXi 4.x on a USB or SD flash storage device.

If you intend to install ESXi 4.x on a USB or SD flash storage device while ensuring VMware support for it and you have not purchased a server with embedded ESXi 4.x, consult your server vendor for the appropriate choice of a USB or SD flash storage device.

So as I suspected, it’s only supported if you install either using “Embedded” or on a device approved by the server vendor.

It does work absolutely fine on a normal USB stick, the host that this web server runs from boots from such an item in fact. It’s just not supported by VMware.

Worth noting that an approved 2GB USB stick from HP will cost you approx £75, about 15 times the going rate…

VMware, ,

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,