When a vSAN “cache” disk fails and gets replaced you need to rebuild the entire disk group that the cache disk belongs to. The normal way of doing this is to put the host in maintenance mode and then click the three dots next to the disk group and select “remove” (see picture below) – but unfortunately most of the time you get this error when trying to remove the disk group:

General vSAN error. vSAN disk data evacuation resource check has failed for disk or disk-group vsan: <UUID>

Luckily there is an easy way of removing the disk group from ESXi CLI that does seem to work every time (at least for me!). Enable SSH on the host containing the defective disk group. Locate the diskgroup UUID and run the following command (remember to replace <UUID>):

esxcli vsan storage remove --uuid <UUID>

If you are unable to find the UUID for the diskgroup then you can run this command:

esxcli vsan storage list

Which will give you an output like this:

Important! – if your host has more than one disk group find the correct one by searching for an belonging disk (naa.xxxxxxx – first red arrrow). When a disk in the group that you need to delete is found, note the “vSAN Disk Group UUID” (second arrow) – this will be the UUID you need to delete with “remove” command mentioned earlier!

If you are uncertain what is going on here – then call VMware support. Deleting the wrong diskgroup can have fatal consequences!

For more information see VMware KB2150567 – link

You are not very likely to bump into Windows 2003 physical servers anymore – but nevertheless that just happened to me a week ago. The task was clear – this server needs to be virtualized into a vSphere 7 environment, running vSAN.
The problem with this task is that to convert (P2V) a 2003 server you need to install vCenter Converter 6.2 on it, since the latest release 6.3 simply doesn’t work on 2003 servers (It won’t install).
Next problem is that vCenter Converter 6.2 doesn’t work with vSAN 7 – only “traditional storage” can be used as target – but in this case there were no other storage than vSAN that could be used as target.
What to do? – read on…

Continue reading

update installation failed, vCenter Server is non-operational
Problem: update installation failed, vCenter Server is non-operational

I recently ran in to this error upgrading my homelab vCenter from 7.0.0.10400 to 7.0.10600:

vCenter: update installation failed, vCenter Server is non-operational

Luckily, the fix was easy – all I needed to do was to delete the file “/etc/applmgmt/appliance/software_update_state.conf”

So you just need to SSH to your vCenter and execute this command:

rm /etc/applmgmt/appliance/software_update_state.conf
The fix: rm /etc/applmgmt/appliance/software_update_state.conf

A few days ago, I decided to update my vCenter server to version 6.7 U2c – normally this is an easy task with the update section in the VAMI interface. But this time I just encountered this error message when I tried to search for the update:

Error in method invocation ({‘default_message’: ‘Manifest verification failed’, ‘id’: ‘com.vmware.appliance.update.manifest_verification_failed’, ‘args’: []}, ‘Verification Failure\n’, ”)

Continue reading

I’ve just seen this in the release notes for VMware vCenter Server Appliance 6.7 Update 1b:

Removing a virtual machine folder from the inventory by using the vSphere Client might delete all virtual machines


In the vSphere Client, if you right-click on a folder and select Remove from Inventory from the drop-down menu, the action might delete all virtual machines in that folder from the disk and underlying datastore, and cause data loss.

This issue is resolved in this release.

I’ve just checked this in my lab on the 6.7 U1b release – when I delete a VMfolder with a VM inside – the VM gets removed from inventory but not deleted on the datastore!

If I delete a VMfolder containing a VM, in vCenter 6.5 the VM gets deleted in the datastore!

Be careful when deleting virtual machine folders!

A couple of days ago I was visiting a customer to setup their Lenovo host to run vSAN – after the initial setup of vSAN kernel IPs, disk groups and so on, I took a look at the “VSAN Health check” to make sure that everything was healthy and supported.

Under the “hardware compatibility” part all checkmarks where green, but the Controller firmware version was not detected – so I did found it a bit strange that it reports the disk controller as supported without knowing what version it actually was running.


This issue is not new to me, as I have seen it a couple of times before, but this time it was different after all.

Continue reading

This morning I faced a strange issue in my vSphere Lab when a wanted to login to VAMI interface – of course to install the newly released “vSphere 6.7 U1” update.

I opened the VAMI URL for my Platform service controller (PSC): https://<FQDN>:5480 and typed in my root credentials as a normally would. However, the only thing that showed on the screen was a message saying: “Unable to login”.

After this I tried to type in my password multiple times to make sure that I was actually typing in the correct one, but still, I just got the same error message.

Continue reading