In a migration scenario I need to change the CPU masks without a chance to poweroff the VMs for that changes.
Is there a way to do that without crashing it ?
I dont have the exact parameters yet but I can give them later.
For now all hints are welcome
These are vCenter advanced settings (set the value to false);
Administration --> vCenter Server Settings --> Advanced Settings
Here is the sledgehammer approach;
config.migrate.test.CpuCompatibleWithHost
- With this parameter set, all CPU-related compatibility testing throughout the vCenter Server is disabled. If you have ESX/ESXi hosts on different hardware, the CPU compatibility won't be tested, and this could have serious knock-on impacts to the VMs.
But you may want to look at using one of the following instead;
config.migrate.test.CpuCompatibleMonitorSupport
- With this parameter set, then "product version does not support features" errors will be suppressed, but other CPU compatibility errors will still be tested for.
config.migrate.test.CpuCompatibleError
- With this parameter set, then CPU compatibility warnings will still be displayed in the migrate wizard, but they won't block the migration.
Cheers,
Jon
Hi Uli,
Im not sure how to change the mask on the fly, but you can certainly supress the CPU compatibility checks by adding in a vCenter advanced setting ... I have used this method to save my bacon in the past - I will send you the exact parameters when I get to my desk, ETA 30min.
I have actually tested this by doing a live migration between clusters of different CPU family ... ie, live migration from Intel Host to AMD host and visa versa ... I wouldn't recommend this as normal operations, but there are times when this is really handy.
What it will give you is the opportunity to migrate a VM between hosts until you can schedule the downtime and reset the CPUID masks appropriately.
Cheers,
Jon
These are vCenter advanced settings (set the value to false);
Administration --> vCenter Server Settings --> Advanced Settings
Here is the sledgehammer approach;
config.migrate.test.CpuCompatibleWithHost
- With this parameter set, all CPU-related compatibility testing throughout the vCenter Server is disabled. If you have ESX/ESXi hosts on different hardware, the CPU compatibility won't be tested, and this could have serious knock-on impacts to the VMs.
But you may want to look at using one of the following instead;
config.migrate.test.CpuCompatibleMonitorSupport
- With this parameter set, then "product version does not support features" errors will be suppressed, but other CPU compatibility errors will still be tested for.
config.migrate.test.CpuCompatibleError
- With this parameter set, then CPU compatibility warnings will still be displayed in the migrate wizard, but they won't block the migration.
Cheers,
Jon
Hi Uli,
you may try to do the change online via a PowerCLI script (see http://www.v-front.de/p/howtos.html#EditVMAdvCfg for an example) and then stun/un-stun the machine.
As far as I known a stun/un-stun can not only be performed by a vMotion task, but also by creating/deleting a snapshot of the VM.
- Andreas
Jon, this is awesome, many many thanks! ... I was looking for this kind of information for a very long time. All the instructions that are around for disabling vMotion compatibility checks do not work for vCenter 5.x, but these advanced settings really do the trick.
I tested this in the lab, was really able to vMotion from AMD to Intel (and vice versa). And I had to write a blog post about this: http://www.v-front.de/2013/04/how-to-vmotion-from-intel-to-amd-and.html.
- Andreas
Hi Andreas,
Glad you found this useful
Thanks for the blog post, this covers the topic comprehensively and has saved me posting a lengthy article on my own blog!
Cheers,
Jon
Thank you for the info, but with the advanced settings in place I still receive the CPU compatibility errors that prevents the migration. Do I need to enable EVC in both the source and target clusters for the settings to take effect?
~Eric