How to enable EVC on ESX 3.5 with No Downtime
Posted by craig 
- on September 8th, 2008 in Virtualization | 14 Comments »
To improve the compatibility of the Processors chipset during the VMotion for Virtualization, the recent release from VMware had the option of EVC for both INTEL and AMD which allow you to VMotion around all your VM even it is not running the same processor family. Previously you may faced compatible issues if you try to Vmotion from INTEL 7 series to 5 series processors family. With this new option, that problem will gone. Really thanks and appreciate to the effort from VMware as well as INTEL and AMD to bring this success and easier our life.
Here I would like to share my experience on how I get this enable without interrupt my existing production environment. By default, the features will tell you to power off all your VM before you can enable this features. Here is the tweak around solution you may want to try. Most of the time, we run critical application on VM which able to minimize the down time for us.
To have Enhanced VMotion Compatibility(EVC) working, 1st you need to create a new cluster. This cluster is not necessary to have HA/DRS running itself, because is to really allow you to move the existing production VM to the temp servers. At the same time, you can setup 1 or 2 temporally ESX Server with the evaluation edition, which have similiar configuration with your production ESX. This is to allow Vmotion happen between the ESX host.
Once you had those ready, start to VMotion all the VM out from the production ESX to the Newly build temporally ESX, until your existing production ESX cluster is empty with any of the VM power on and running.
Your cluster is now ready to configure for EVC. Right click your cluster and choose Edit Setting, and click on the VMware EVC. Select the option Enable EVC for Intel or AMD ( This will depend which processor you are using in your environment). Click Ok after that and the cluster will enable the EVC for you.
Once finish, you have EVC ready for your environment and say goodbye for processor incompatible on the Vmotion. Now you can vmotion back all the VM into this HA/DRS production cluster, and decommission your temp ESX servers you just built.
Please note that the 2 temporally ESX servers are not compatible for Vmotion before the EVC enable.
Related posts:
Tags: ESX, ESX 3.5, EVC, Virtualization, vmotion, VMware
14 Responses
In thinking about your method, if you have sufficient additional resources in the cluster on which you wish to enable EVC, it should be possible to move one host from the production cluster to the temporary cluster, then VMotion guests to it. Once you’ve transferred a sufficient number of guests to the host in the temporary cluster, you should then be able to move another host, and so on, until you’ve evacuated all the VMs in the cluster. Once you’ve accomplished that, it should be possible to enable EVC in the production cluster, then reverse the process used for the VM transfer. This will eliminate the requirement that you “stand up” one or more temporary ESX hosts to keep the VMs in production.
You are right, some how, my experience about vmotion to maximize the utilization of the ESX host is quite danger, which could respond slow experience on the VM as well as packet drop or delay. To minimize this impact, you may want a workaround on that. But your suggestion is correct and I do agree with your opinion
Please feel free to check Understanding VMware EVC: http://www.itworld.com/virtualization/56292/understanding-vmware-evc
Doesn’t quite work like this, well not for me anyway in my AMDG2/G5 cluster. You can vmotion the VMs to the temp cluster fine, and then enable EVC on the original empty cluster, fine, but then you try and VMOTION the VMs back to the EVC cluster, the VMOTION prerequisites fail with a CPUID mismatch. This makes sense when you think about it, because EVC essentially masks features across all CPUs in the cluster that VMs may be actively using in the temp cluster….
Would like to check with you, the AMD processor for your ESX are come with AMD Opteron range?
You can also check on the link posted by superman for further understanding about EVC. Hope it will help your issues
They are both opteron. One is 585G2 the other is 585G5. The VMs cold migrated into the EVC cluster, I can vmotion out of this cluster into the non-evc cluster and back again. So it’s something to do with CPU masking on the VMs that are already running in the non EVC cluster, requiring the VMs to be shutdown first. The masks aren’t something we’ve enabled, I suspect it’s a result of a previous version of ESX.
Yes, is cause by the previous version of ESX. Most of the time, we did not reboot the VM when we upgrade the ESX, so you will have a VM never reboot for more than 60 days but your ESX which had been upgrade for twice.
I’m facing the same problem as Kimono but with Intel E5450 CPU’s. Once I enable EVC in a temp. cluster and try to move virtual machines to the temp. cluster it gives me a CPU mismatch error.
you may want to check the version of CPU option you select to your EVC, could be something like core 2, core i7, 45nm and etc
hope this will be helpful for you.
[...] I am able to get the ESX 3.5 to be manage by the latest vcenter. A vmotion from ESX 3.5 to vsphere 4 had been successes too, but the latest version of virtual machine which built from vsphere 4 might not compatible to vmotion back to the ESX 3.5 hosts. At the same time, if you have different processors chipset in the environment and require EVC to be turned on, it may be a little challenge to do so. You may want to ensure the EVC to be done with no down time. You may need to refer to my previous post about how to enable evc with no down time. [...]
We came across this issue and the advice above but it doesn’t work because, as previous comments state, it still shows CPU mismatch when you try to VMotion the VM’s back.
My Advice? Create a new cluster with your new incompatible head or spare head (or create a spare head by moving VM’s off), then clone the machines one at a time, choosing to run the cloned VM’s in the new cluster. Once complete, boot the cloned machine WITHOUT ETHERNET, then switch it across by disabling ethernet on the old and quickly enable ethernet on the new. Although there may be a small lag doing this, it’s a million times better than all the down time turn VM’s off.
Hi Leigh, I understand the difficulty you may face which may result the solution we put in here does not work with the latest chip set, unless. This post had been quite some times before the nehalem from Intel had launched. Is your VM currently running on a ESX host with Intel Nehalem?
[...] This post was Twitted by sideshowtob [...]