Monthly Archives: April 2016

Unable to revert snapshot: “the vendor of the processors in this machine is not the same”

Written by William Roush on April 6, 2016 at 5:24 pm

Warning: This is not supported by VMware, not recommended and I am not responsible for any data loss related to trying this. Snapshots are not backups and you should not rely completely on them. If you’re willing to risk data loss this may however save you… Have backups of the VM’s current state before attempting to do any of this.

On this Serverfault post a user is confused due to EVC configuration. For most people EVC only has to do with clusters and vMotion, however if you snapshot a running VM the VM’s CPU feature flags are set depending on the EVC settings of the VM. So a cold migration may leave you unable to revert the snapshot with the following error:

feature requirements of this virtual machine exceed capabilities of this host’s current evc mode

the vendor of the processors in this machine is not the same

We’re going to go ahead and try to take a live VM snapshot and convince VMware it’s a powered off snap. Sadly in my lab I do not have an EVC enabled cluster up with differing hardware so we’re going to take the best swing we can at it. We’re going to start with a powered on Windows VM, snapshot it while it’s powered on and attempt to remove all traces that the snapshot was taken while it was powered on so hopefully those sticky EVC settings won’t stick.


So we’re going to try to trick VMware into thinking the VM was powered off when the snap happened. There are 3 major differences in these files:

  • SnapshotTest.vmsd – A ‘snapshot0.type = “1”‘ line that denotes it’s a powered on snapshot
  • SnapshotTest-Snapshot1.vmsn – Additional binary data in the snapshot config file, may be related to state, likely has CPU flags in here somewhere
  • SnapshotTest-Snapshot1.vmem – The dump of the RAM onto disk.

The easiest way to attempt to do this is to open up the .vmsd file and remove the type line, and remove and re-add the VM to your inventory, this will trick the hypervisor into thinking the snapshot was powered off and won’t load the vmem file.

However I cannot test CPU flags mismatching in my lab, it’s entirely possible that the vmsn file will still conflict, which would require you to do some file surgery with a powered-off snap file as you base file (very risky).

Deleting the snaps will remove the vmem file even if the vmsd file has been updated to declare the VM as “powered off” during the snap, so cleanup should be easy (always check though, we’re doing funny stuff to VMware).

Cannot Consolidate Disks on VMware

Written by William Roush on April 6, 2016 at 1:27 am

Due to the error: “Unable to access file since it’s locked” details may say something like:

An error occurred while consolidating disks: msg.fileio.lock.
Consolidation failed for disk node ‘scsi0:1’: msg.fileio.lock.
Consolidation failed for disk node ‘scsi0:0’: msg.fileio.lock.

Make sure your VM doesn’t have it’s disks mounted in another VM, in this case our Veeam virtual machine did not release the disks when it was done backing it up for some reason, removing the disks allowed us to consolidate the VM.