Lab Expansion Part IV – vCenter Reconfig

One thing I was very interested to explore was if there was some exotic way, these days, to utilize EVC (Enhanced vMotion Compatibility) to mix architectures.  In other words, to vMotion from AMD to Intel.  Now of course we know intuitively that this is super unlikely.  The reason for this being, as covered in the entry on virtualization modes, that x86 virtualization passes instructions from the guest directly through to the host via the virtual machine monitor and does not provide any sort of emulation of the compute tier.  As a result, a guest that is up and running knows whether or not it is on Intel or AMD (since these days both Windows and Linux optimize for specific architectures) and shifting the rug out from under it, as happens with the live movement that occurs with vMotion/DRS moves, would be disruptive.  Still, virtualization software continues to get ever more clever with each new wave, so it’s worth checking in now and again to see if the landscape has shifted.  Unfortunately, it has not.  EVC remains useful for normalizing across generations of one vendor (either AMD or Intel), in some scenarios (not all), but still cannot be of assistance in normalizing between them.  So with that said, I went ahead and created a new cluster for the two new AMD hosts and creative called it “AMD”:

Screen Shot 2013-03-26 at 12.35.49 AM

As the screenshot shows, the absence of EVC support for hot migrations across architectures certainly doesn’t prevent cold migrations between them.  With the new hosts installed into the vCenter, licensed, and added to the new cluster, it was time to give them some workloads to run.  Cold migration is super easy.  All that is required is to turn the VM off and follow the same migration process we walked through earlier with the datastore move, only this time pursuing that host migration path.  There is an opportunity to move datastores again, but in this case all hosts are pointing to the same iSCSI target so there is no need.  Migration in this scenario is very fast and within a minute or so the VMs were ready to be restarted on the new hosts.  Windows 2008 returned without a hiccup and activation was not retriggered (interesting).  Windows 2003 didn’t fare nearly as well and actually crashed on restart.  I will take a closer look and figure out what is going on with the W2k3 guest, but in theory it should be able to recover without major issues in moving from Intel to AMD (I’ve actually moved physical installations of Windows 2003 the other way from AMD to Intel), but plug and play is a bit less robust on W2k3 and I am fairly certain that an activation will be triggered at the very least.

With the VMs rebalanced now across 4 hosts, I brought Active Directory back up across the VPN connection to EC2 and proceeded to bring the AD back in sync across the two sites.  I kept my fingers crossed for this one as I know there were times I ran the EC2 DC without my on-prem DCs being up so there was a genuine risk of the tombstone period having been exceeded which leads to a manual cleanup and a world of hurt that I have grappled with before both in the lab and, unfortunately, at customer sites.  Thats an ugly scenario always best avoided and, fortunately, the AD stayed healthy.

With everything looking good I braced myself for a final disappointment and checked in on DirectPath IO.  Last time this was a no go as Intel VT-X support is limited to a specific set of server, and high end enthusiast, chipsets and processors.  I pretty much knew that the same would be true in this case, but AMD is better with the breadth of their virtualization support so I figured IOMMU might have a slim chance.  Unfortunately, the 760G chipset doesn’t have the support for IO virtualization (or at least the BIOS on the Gigabyte motherboard doesn’t expose it) even though the FX6100 can do it.  Not a big loss, but some day I will see that option light up!

wah, wah, waaaaaaah
wah, wah, waaaaaaah

With the new lab humming along I am ready to start testing some interesting hybrid cloud scenarios and more advanced management and orchestration options between vCenter and EC2, but those are topics for future entries.  Until then, thanks for reading!


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s