This week VMware announced that VMware Tools – the agent that sits on the guest operating system is now a separate product. This means that it’s subject to its own product lifecycle, and admins can modify their approach to keeping tools updated. It’s all grown up, and got a home of it’s own. Continue reading
In the process of upgrading a vSAN ReadyNode cluster from ESXi 6.5 to 6.7 a warning appeared in the vSAN Health check. The first host in the cluster had gone through the upgrade and was now showing the warning “Controller driver is VMware certified” (Note 1 in the image below, click on it for a larger view). The Dell HBA330 card was using an older version of the driver (2 in the image below) than recommended (3).
All workloads were still online, but running VMware Update Manager (VUM) did not clear this warning. Looking in the VUM patch listing showed the driver for ESXi 6.5 (4) but not the version recommended for 6.7.
It was necessary to manually load these replacement drivers in. A quick google showed they could be sourced from VMware’s download site. Extract the ZIP file from the download and then use the “Upload from File” option in VUM (5) to upload the ZIP file which was inside (in this case “VMW-ESX-6.7.0-lsi_msgpt3-17.00.01.00-offline_bundle-9702440.zip“). The new driver should then appear in the list (6) and will automatically be added to the “Non-Critical Host Patches” baseline (7). Final remediation is now just a case of applying that updating baseline to the host.
In this particular instance the hosts were Dell PowerEdge R630 vSAN ReadyNodes with the HBA330 SAS HBA Controller option but the principles outlined in this post should apply to other configurations with the same symptoms.
If you’re running VMware vCenter and ESXi 6.0 it’s time to start planning to upgrade as General Support ends on 12 March 2020- one year from now and five years from it’s release. Thankfully the upgrade from 6.0 to 6.5 or 6.7 is usually quite straightforward, and VMware have put a lot of work into streamlining this process.
Looking at the Product Lifecycle Matrix other notable products in the VMware stable worth keeping an eye on include NSX for vSphere (NSXv) 6.2, Site Recovery Manager (SRM) 6.0 and 6.1, and vSAN 6.0-6.2.
A powered off VM on ESXi 6.5 will not power on and returns the error “Failed to power on virtual machine…. The attempted operation cannot be performed in the current state (Powered off)”.
(i.e. the VM cannot be powered on BECAUSE it is not powered on!)
Prior to being powered down the VM properties had just been modified. In this particular case it was immediately following a manual Ubuntu install and the install DVD (from a datastore ISO) was disconnected and the CD Drive switch to” “Host Device”. These operations were performed from the ESXi Web interface.
Repeated attempts to start the VM all fail the same way.
Unregister the VM, then locate the vmx file in the datastore and re-register it. The VM should now power on.
- The VMware vSphere ESXi UNMAP command doesn’t release space on some or all volumes on a Dell EqualLogic SAN array running v8 firmware (may apply to other versions too). Using the following command in an SSH session to a 6.0u2 host (again, will apply to other versions):
esxcli storage vmfs unmap –l MYVOLUMENAME
- The volumes are VMFS5 (and always have been- they haven’t been upgraded from VMFS3).
- Replication is enabled for the volumes that won’t rethin.
UNMAP doesn’t work on the EqualLogic when Replication is enabled. It doesn’t return an error to the SSH session, and the temporary rethinning file is still created, but the disk is not thinned.
Disable replication on the volume, re-thin the volume using the UNMAP command, then re-configure replication. Unfortunately this means the entire volume must be re-copied to the replication partner and this may impact bandwidth usage and replication schedules on larger volumes.