Migrating from vCenter 5.5 on Windows to the vCenter 6 VCSA

Towards the start of the year, I made a post about my vCenter to vCenter migration process, which can be used to update from vCenter 5.5 to vCenter 6 (or for that matter, to downgrade, or whatever).  Since then, I've done a lot of these migrations and the scripts/procedure have matured.  Jeff and I have fixed many bugs, but the reason that I'm posting about this (again) is that I recently added a new feature and have polished our migration process.

The latest versions of the migration scripts (the ones that get the settings from the source vCenter and then recreate those settings on the destination vCenter) now support DRS Rules!  The native support for DRS Rule manipulation through PowerCLI is a bit lacking... but fortunately, the community has solved that problem!  Matt Boren and Luc Dekens have created a module called DRSRule that is built to help with the reading and manipulation of DRS Rules (pretty self explanatory, right?).  I took advantage of that module to modify my vCenter object migration scripts so that they can read the DRS Rules from the source vCenter and then recreate those rules in the destination vCenter.

So, the current versions of the scripts record and then recreate all vCenter Roles, VM Folders, VM placement in those folders, Permissions assignments and DRS Rules.  In addition, the Set script checks the cluster configuration on the destination to ensure that EVC Mode matches and that all expected ESXi hosts have been added back into the cluster.

How do we use these to upgrade from vCenter 5.5 to vCenter 6?  Well, the high level workflow is pretty simple:
  1. Prepare the vCenters
  2. Prepare the Hosts to transition between vCenters
  3. Transition the hosts between vCenters
  4. Clean up
The actual steps required for each of those major steps is highly dependent on what is in the environment, but here are the basic things that I usually do.

Prepare the vCenters

I begin by recording all of my template names and converting them to VMs (get-template | select name | export-csv templates.csv; get-template | set-template -tovm); after all, templates are vCenter objects and would become unmanaged when their host is removed from the vCenter inventory.  

Next I use the Get-SourceSettings.ps1 script to record the source vCenter settings and run my first pass with the Set-SourceSettings.ps1 script on the destination vCenter.  At this point, I use the -roles, -permissions and -folders options in order to create those core objects.  Obviously, there is nothing yet existing in the destination vCenter for the -vms or -DRS switches to manipulate (since there are no VMs to place in folders or assign to DRS Rules), so I skip those.  

At this point, I also create an empty cluster (with appropriate HA Admission Control and EVC settings) and a Distributed Switch to match the source side.  On the Source side, I disable HA Host Monitoring and set DRS down to Partially Automated.

Prepare the Host to transition between vCenters

The most important detail for most of my customers in preparing the hosts to transition between vCenters is to get off of the Distributed Switch.  The VDS is great, but it is an object that is owned by the vCenter server.  If you are going to transition between vCenter servers, you've got to get back onto a Standard vSwitch, which is an object that is wholly owned by the ESXi host itself.

In order to do this, I first create a standard switch on the host that I'm going to transition (with some variation on the command: get-vmhost <hostname> | new-virtualswitch -name Temp-VSS).  Once the standard switch is created, I use my make-vss.ps1 script to clone all of the Distributed Switch Port Groups onto the standard vSwitch.  With the Port Groups created, I take half of the physical uplinks from the Distributed Switch and put them onto my Standard Switch (you'd better not be using etherchannels when you do this...).  Next, I migrate my VMKernel interface onto the VSS via the GUI.

Once the VSS is verified as being functional and configured, I use my migrate-to-VSS.ps1 script to move all of the VMs off of the VDS and onto the VSS.  Once they're all on the VSS, I remove the host from the VDS entirely.

Transition the host between vCenters

The next step is to move the host into the new vCenter.  To do that, I simply add the host to the new vCenter's inventory; I do not place the host in maintenance mode first (or even disconnect it from the source side).  My goal is to keep all of the VMs running for this entire process.  Once the host is added to the new vCenter, I then join it to the new VDS (using the same physical NICs that it was using on the old one) and migrate the VMK interface onto the VDS.

Next, I migrate all of the VMs onto the VDS via my migrate-to-VDS.ps1 script.  Why use a script instead of the GUI?  I just love scripts!  Well, that, and I don't want to get carpel tunnel syndrome from clicking all of those network interfaces and their new port groups... and I don't want to mess it up by accidentally selecting the wrong port group... and it's easier/faster to use a script!  I use this methodology of splitting my physical uplinks between the VSS and VDS for all of these transitions in order to minimize the impact of the transition on the VM.  If I used the wizard and moved uplinks around at the same time as the VMs, there would be a period where the uplinks had been moved but not yet all VMs.

Finally, I destroy the VSS and reassign those physical uplinks to the VDS.  At this point, the host is fully transitioned to the new vCenter inventory... so I just repeat the prep/move processes for each host in the environment.

Clean Up

After all of the ESXi host have been transitioned to the new vCenter environment, there's a little cleanup that needs to happen.  I use the Set-SourceSettings.ps1 script again, this time giving it the -vms, -permissions, and -drs switches.  This will replace all of the VMs into their proper folders, reassign any permissions that were directly assigned on the VM (bad!) and recreate any required DRS Groups and/or Rules.  The final step is to convert the template VMs back into templates (get-vm (import-csv template.csv).name | set-vm -toTemplate -confirm:$false), and you're done!

Script Links

It occurs to me that I've referenced a lot of scripts in this post.  Rather than using gist-it to append them all to this post (and end up with a 30 page post or something), I figure that we're all best served by a collection of links.  So, here they are:
So, that's it!  This is the procedure that I use and the tools that I use to do it.  Ultimately, I'm just a guy and while this has worked for me in the environments where I work, that's no guarantee that it'll work for you in your environment.  Test everything thoroughly, and please let me know if you fix anything!

Update (9/20/2016):
I just saw that VMware has released a new version of the VCSA - Update 2m.  What's the "m" stand for?  Migration!  It looks like we may have an easier way to get from Windows vCenter 5.5 to VCSA version 6.0, as long as your source vCenter is configured correctly.  It looks like they currently have a restriction regarding how the VC/PSC configuration is built (based on the source side's vCenter/SSO relationship), but that might be a better route to go than doing all this by hand!

Comments

  1. Your script warns that virtual apps have to be manually recreated. Is there a problem with the get/set/new VApp cmdlets that makes them unsuitable to the task?

    ReplyDelete
    Replies
    1. Yeah, the script will move the VMs over without issue, I'm just not confident that it'll grab all of the extra settings that can be configured in a vApp. The latest version actually does a really good job of dynamically creating the list of attributes that it needs to recreate, but vApps have so much variability to them that I don't know if it will catch everything in every situation.

      Delete

Post a Comment

Sorry guys, I've been getting a lot of spam recently, so I've had to turn on comment moderation. I'll do my best to moderate them swiftly after they're submitted,

Popular posts from this blog

Orphaned VMDK Files

Migrating from one vCenter to Another, Improved

Copying VM Folders and Permissions from One vCenter to Another