Today Nutanix has released the Xtract for VM’s product. With this tool you will finally be able to directly move your existing vSphere infrastructure to the Nutanix Cloud platform on AHV without any 3rd party tooling or workarounds.
Previously there where several ways to move from ESXi to AHV. The first way was to use 3rd party tooling like starwind to convert the disks. The other ways where completely manual by adding existing disks to new VM’s, use the cross hypervisor DR functionality or in place ESXi > AHV conversion if both clusters where already running on Nutanix. While these are tested and well documented scenario’s, there was no easy way to just test this and it could require a large maintenance window with a lot of manual actions. Rolling back could be a pita as well so it might end up being a costly effort.
In the spring Nutanix already announced Xtract, a tool that would solve all these headaches for you. With it you can schedule the migration and it will insert the required drivers and network settings for you. This results in a migration with hardly any downtime. You can setup the sync from ESXi to AHV wel advance so it is possible to test the complete migration procedure well in advance of the final cutover.
Release of new Nutanix tool called Xtract for Vm’s that efficiently and safely automates the move of your vm’s from ESXi to AHV.
After doing several Acropolis (CVM) & NCC (Health check) upgrades before on my customer’s Nutanix clusters today was the first time to do an actual hypervisor upgrade. Since we run everything on VMware we wanted to go from 5.5u2 to 6.0u2. The first things to do is to check all compatibility charts and with Acropolis at 4.6.4 and NCC at 2.2.8 we had green lights all over the board.
What I always do first before doing anything is running a health check. Since NCC 2.2 you can run some of the checks parallel to save some time:
ncc health_checks run_all -parallel=4
After the check and make sure DRS is set on automated and vSphere HA is turned on as it should otherwise you won’t be updating anything!
Next up is heading to Prism, no we’re not doing any cli work when a GUI is better and just as fast!
The first thing to do is upload the software (Offline bundle zip file from VMware.com and json file from Nutanix.com)
Go to Software Upgrade
Select Upload the hypervisor Binary
Select the binary and the Json files and hit Upload Now
When this is done hit the arrow besides the upgrade button and select the pre-check (the real upgrade also does this but it is never wrong to check twice!)
Enter the IP of the vCenter (not DNS!) and credentials
This won’t take long but if you get bored hit the Nothing do to button for a game of 2048 presented to you by our friends at Nutanix
You might need to re-open the Software Upgrade but but somewhere it will be done now
When this finishes successful it’s time to hit the real upgrade button
You know what to do here right?
The waiting game has started since there will be a lot of vMotion’s and reboots
This it might be time for this again
If you re-open the Software Upgrade bit it will show the versions of ESXi the cluster is now running
Aaaaaaand we’re done
So actually creating this post took longer then the preparation and actions for the upgrade themselves. For me that was 5 minutes work in preparation and about 20 minutes per host for the upgrade itself.
Something I still hear a lot that system engineers take their vSphere environment for granted and hardly check anything on a daily basis. I always point them at Alan Renouf‘s brilliant health check script while there are other ways to get your daily dose of health this one still rocks for me. You can remove unwanted plugins or make different selections of plugins for daily, weekly or monthly checks. Now and then I still hear people that had issues because of snapshots and there is no need for that anymore and hasn’t been for years! This script has saved me lots of times already + it helped me get management support for limiting other people’s access to the environment because they had no idea what they where doing.
Something I still see now and then, and have had big issues with in the past, is the time on ESXi hosts. Sometimes no ntp servers have been set or the ESXi hosts can’t connect to them. Other times ntp servers have been set but not the time so they’re still off. Normally this shouldn’t be a problem but since a VM always takes on the time of the hosts it is moving to during a vmotion this can cause issues on database servers.
In my last situation the ntp servers where correct but the time was off and somehow never properly synced to the ntp hosts. To fix this I created 2 scripts, one to check the ntp settings and current time and another to set the time.