3

Recently we moved to a new Intel-based ESXi 6.0 server from an older ESXi 5.5 AMD-based server, both with 64bit processors. We just copied the VMs folders from the old server to the new one, then powered them on and answered "I moved it" to the question that pops up. Everything went good, but today I tried to revert a VM to an old snapshot taken in the old server: ESXi does not complete the operation, and gives these two errors:

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

As far as I understood, EVC is a technology related to vCenter and vMotion, it prevents vMotion between servers with different processors/architecture, but I have a single server ESXi environment, without these features. Is there a workaround these erorrs? Maybe editing VM configuration files?

3

Were the snapshots taken while the machine was powered on? If so the VM snapshot state requires the CPU features match the original state. Otherwise the feature set of the CPU would wildly change in the middle of powered-on operation, that's a huge no-no.

If it's powered off, yeah that makes no sense, it shouldn't matter.

NOT SUPPORTED BY VMWARE, TRY AT YOUR OWN RISK

You could try opening up the "vmsd" file and deleting the "snapshotX.type = 1" (where X is the index of the snapshot) line to make VMware think it's no longer a running VM snapshot. The vmsn file has binary data relating to the CPU that is running but it may ignore that when the type doesn't match. My homelab does not have differing CPU types so I cannot test this. :(

| improve this answer | |
  • 1
    Yes, the snapshot was taken while the VM was powered on. – J.B. Apr 5 '16 at 11:09
1

Your snapshots won't be useful here. The original snapshots came from a system with a completely different architecture, so the error you're receiving is very clear in its message.

AMD and Intel are not compatible in vmotion or EVC terms.

| improve this answer | |
  • 1
    Sorry for the -1, but your statement only makes sense if the snapshot was taken while the VM was powered on (which is actually the case); if it was powered off, processor family wouldn't have mattered at all. – Massimo Apr 5 '16 at 19:28
  • @Massimo but the OP said the system was on when the snapshots were taken. – ewwhite Apr 5 '16 at 19:29
  • 1
    And if you have a snapshot chain where even one snap was taken while the VM was on, reverting to it would not be possible on a different architecture. – ewwhite Apr 5 '16 at 19:30
  • Agreed. I was only commenting on your absolute statement of "Your snapshots won't be useful here. The original snapshots came from a system with a completely different architecture". IMHO you should add that this is only true when the snapshots include a powered-on VM, otherwise there is no issue. – Massimo Apr 5 '16 at 19:52
  • I'm pretty sure most people taking VM snapshots are doing it with powered-on systems? The same rules of EVC and vMotion apply here, and the error was self-explanatory. The OP appears to have resolved this himself, so I don't think there's a need to qualify my statement. This is totally an edge case. – ewwhite Apr 5 '16 at 20:09
0

I tried to edit .vmx file without success, so I ended up powering on the old server, moving the VM on it, than reverting to the snapshot and finally moving the VM back to the new server. Now the VM runs normally on the new server, and I deleted the snapshot.

| improve this answer | |
  • Do you now understand why that was necessary? – ewwhite Apr 5 '16 at 11:45
  • Yes, I thought that the incompatibility was only between 32 and 64 bit architecture. – J.B. Apr 5 '16 at 13:04

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.