After procrastinating for a while, I finally started the upgrade process in my home lab to go from vSphere 6.0 to 6.5. The PSC upgrade was smooth, but I hit a roadblock when I started the upgrade process on the vCenter Server appliance.
After going through some of the first steps in the process, I ran into the following error when trying to connect to the source appliance.
The exact text of the error reads:
“Unable to retrieve the migration assistant extension on source vCenter Server. Make sure migration assistant is running on the VUM server.”
I had forgotten that I even had Update Manager deployed. Because my lab is small, I generally applied updates manually to my hosts via the CLI. What I do remember, however, is being frustrated that I had to deploy a full-scale Windows VM to run the Update Manager service.
VMware has generally been a step behind with VUM for the last few releases of vSphere. In 5.5, you were forced to use the legacy vSphere Client for VUM functionality. In 6.0, you could use the Web Client, but couldn’t run VUM as an appliance. Finally, in 6.5 we have full integration of VUM services right into the vCenter Server appliance.
That said, the need for a migration tool makes a lot of sense. The vSphere 6.5 Upgrade doesn’t include an in-place upgrade for VUM, but rather the migration of VUM from a standalone box into the integrated appliance. I certainly don’t want or need VUM to reside in a dedicated Windows VM, so this is a positive move in my mind. I’m sure many customers feel the same way as they’ll free up a costly Windows Server license that can be better used elsewhere.
The VUM Migration Process
After hitting the roadblock, I looked around and came across the official VMware documentation on the process here.
The process is pretty straight forward and can be summarized as follows:
- Mount the vCenter Server 6.5 ISO to the VUM Windows Server.
- Copy the migration-assistant directory to a location somewhere on the VUM Windows Server.
- Launch the VMware-Migration-Assistant.exe file.
- In the window that opens, enter the SSO administrator account password.
- When prompted, leave the window open and continue with the vCenter Server upgrade process.
Although it may have been possible to run the migration assistant from the mounted DVD ISO, I copied the entire migration-assistant directory to the machine’s desktop and ran it from there.
The total size of the directory is about 150MB, so make sure you have some free space available. Once I ran the file, I was prompted to enter the administrator@vsphere.local password and then after a minute or two was instructed to leave the window open.
Once it was ready, I returned my focus to the vCenter Server installer to continue the upgrade process. This time, it passed all pre-checks and stage 1 of the new appliance deployment was successful:
The Woes Begin
Toward the end of the second phase of the upgrade progress, a rather ominous looking error message greeted me:
The error message read:
“Error attempting Vcintegrity Export file does not exist or is corrupted, abort import”
Thinking it may have just been a storage hiccup, I retried the process and hit the same problem. Upon further investigation, I came across VMware KB 2150982.
The KB describes the problem as occurring when the VUM services are located on another Windows machine. I suspect that means that it’s on a machine other than a Windows vCenter. Anyone running a vCenter Appliance and a Windows VUM server would then in theory be susceptible to this.
Until this can be fixed, KB 2150982 lists the resolution as uninstalling VUM and then attempting the upgrade again. I did this using the following process:
- Uninstall VUM from Add/Remove Programs
- Uninstall SQL 2012 and related components from Add/Remove Programs (This is the embedded database installed by VUM)
- Power off the old VUM Windows Server.
If for whatever reason the VUM plugin lingers after removal, you can consider using KB 1025360 to unregister the extension from the managed object browser (MOB). In my case the plugin was removed successfully by the uninstall process.
Conclusion
In summary, had I known I’d be jumping through all of these hoops, I would have simply removed Update Manager from the get-go. Unless you’ve got a lot of custom baselines or other configuration added to VUM, it’s probably easiest just to start fresh once you get to 6.5. I’d expect that existing custom baselines may no longer be valid anyway if they were created in 6.0.
Has anyone else run into these VUM migration issues? If so, were you able to find an effective workaround?
vswitchzero 
Thanks for this, I uninstalled VUM but it still barked it was there. Ended up having to remove via /mob page