Solving problems invented by others...
Migration from Windows vCenter Server to vCenter Server Appliance

Migration from Windows vCenter Server to vCenter Server Appliance

Well, i again realized that i was to lazy to write this article. The informations here are already obsolete because VMware published vCenter Server 6.0 U2M. Therefore the following informations are only for the people who are interested in how migrations were done in the good old days before U2M.


This was my path to migrate a Windows vCenter to the vCenter Server Appliance.

1.) My source environment

  • vCenter on dedicated physical Machine
    • Windows 2008 R2 SP1
    • SQL Server 2008 R2 SP2 (Build 10.50.4339)
    • vCenter 5.5.0 Update 2e (Build 2646482)
  • Hosts
    • 35 x ESXi 5.5 Patch 4 (Build 2403361)
  • Configuration items
    • 4 x dvSwitch Version 5.5.0 00000
    • 4 x Clusters
    • DRS Groups and Rules on most clusters

2.) My intention

  • Update environment to the actual versions because of known security vulnerability in that old versions.
  • Migrate to a vCenter Server Appliance #migrate2vcsa
    Easier update, no more dependencies to operating system or database.
  • Want to have redundancy for the vCenter in case of a hardware crash.
    I even want to be able to start my vCenter in another datacenter if primary datacenter is unavailable.

3.) Installation of the vCenter Server Appliance

  • Create a DNS A and a PTR record for the appliance.
    I observed that the installation will not work if the appliance can´t make DNS name resolution (forward and reverse).
  • Create a new dvSwitch portgroup with ephemeral binding
    Because you had to connect the VCSA installer directly to a host to create the VM, the host can not use portgroups with static binding. (If you still use local vSwitches you don´t have to do anything.)
  • Install the vCenter Server Appliance
    Follow the VCSA deployment guide ->
    (I chose to install everything on one VM to reduce complexity.)

I run into two problems while installing the VCSA:

  • The installation did not run because the newly created VM had their network interfaces disconnected.
    While the installation runs it used the old vSphere Client to connect to the host, went to the settings of my new VCSA VM and changed the status to the vNICs to connected. After that the installation runs without errors.
  • Although i told the installer to set the correct NTP settings, the resulting VCSA did not have this settings. Therefore i had to set it manually, following KB#2113610.

4.) Create empty clusters in the new vCenter

Since i had only 4 clusters i simply created them manually in the new vCenter. I my environment it was important to set the right EVC mode. Because it is not possible to  activate EVC later when you have running VMs in the cluster.

I created them with the same names and the same settings like in the old still running vCenter.


5.) Alarms

In my source environment i changed some alarms to get a mail when something happened. But after years of working on the old vCenter i could not remember which ones i changed. With the help of PowerCLI it was really simple.

First i checked which alarms are not defined at the vCenter level:

Get-AlarmDefinition | Where-Object -FilterScript { $_.Entity.Type -ne "Datacenter" }

That way i got all alarms which were defined at a custom folder oder VM level and are not part of the default alarms vCenter bring along.

Second i checked which alarms had a email action defined:

Get-AlarmAction | Where-Object -FilterScript { $_.ActionType -eq "SendEmail" } | Select-Object -Property AlarmDefinition,To | Sort-Object -Property AlarmDefinition

This gives me a list of all default vCenter alarms which i modified. Because when i did this i always want them to sent me a email.


After i now had a list of modified alarms i configured them manually on the new vCenter.

6.) Templates

The process of moving the hosts to the new vCenter does not move the templates.

You could just re-register the templates in the new vCenter after the migration is complete like described in KB#4136634, but if you have more than 10 templates in different folders like i do this is not the easy way.

Instead i converted all Templates to VMs just before i migrated the hosts. Then they will go smoothly to the new vCenter and all i had to do is to convert them back to templates.

To know where my templates are, i exported a list with PowerCLI:

Get-Template | Select-Object -Property Name,@{Name="Datastore";Expression={$_.ExtensionData.Config.DatastoreUrl.Name}},@{Name="Config";Expression={$_.ExtensionData.Config.Files.VmPathName}} | Export-Csv -Path D:\VMware-Migration\templates.csv -Encoding UTF8 -NoTypeInformation

With that list just convert your templates into normal VMs.


7.) vApps

While searching for information about how to migrate to the VCSA if found this excellent blog article of Jason Coleman.

He describes that vApps makes a lot of problems migrating to a new vCenter.

A quick “Get-VApp” shows me that i don´t have one. 😅


8.) Host profiles

To export host profiles in the old vCenter i did:

Get-VMHostProfile -Name "HostProfile Cluster 1" | Export-VMHostProfile -FilePath C:\vmware\HostProfile-Cluster-1 –Verbose

To import in the new vCenter:

Import-VMHostProfile -FilePath C:\vmware\HostProfile-Cluster-1 -Name "HostProfile Cluster 1".

If you had set the root password in the host profile you had edit the imported host profile because passwords will not be imported that way.


9.) Folders

Again if found a lot of useful informations on Jason Colemans site:

First i had to be sure that there are no two folders with the same name. The following command displays all folder names which are used more than once:

$a = Get-Folder | Where-Object -FilterScript { $_.Type -eq "VM" } | Sort-Object -Property Name; $b = Get-Folder | Where-Object -FilterScript { $_.Type -eq "VM" } | Sort-Object -Property Name -Unique; Compare-Object -ReferenceObject $a -DifferenceObject $b

I had to rename some folders so that every folder has a unique name in the inventory.


After the folder names are unique i could export them into a file:

$dc = get-datacenter
$dc | Get-Folder | Where-Object -FilterScript { $_.Type -eq "VM" } | Select-Object -Property Name,Parent | Export-Clixml -Depth 10 -Path "C:\vmware\folders.xml"

And then import them into the new vCenter:

$dc = get-datacenter
foreach ($thisFolder in (Import-Clixml D:\VMware-Migration-Produktiv\folders.xml | Where-Object -FilterScript {!($_.Name -eq "VM")})) { $dc | Get-Folder $thisFolder.Parent | New-Folder $thisFolder.Name -Confirm:$false}


10.) Datastore and network folders

A special attention should be given to the datastore and network folders. Since these folders could not be created with powershell i had to create them by hand. Luckily i had only a few of them.

Although you can not put VMs into these folders the migration will fail if one of them has the same name as a VM folder. Take care that these folders also have unique names.


11.) dvSwitches

The most error-prone step are dvSwitches. The problem here are the unique keys every distributed port group object has in the vCenter database. I it absolutely important to keep these IDs while migrate the configuration. Only with the correct IDs the VMs could be reconnected to the right portgroup on the dvSwitch in the new vCenter.

To export the dvSwitch configuration in the old vCenter you can simply right click it and select export to a file.

To import the dvSwitch configuration you can create a new dvSwitch from a configuration file in the new vCenter. On this task you have the option to keep the IDs while importing. This is absolutely necessary.

You can also import the configuration to a existing dvSwitch in the new vCenter. But this task don´t give you the option to keep the IDs. Therefore always create the dvSwitch new from the configuration file.


12.) Roles

To export my roles in the old vCenter i did:

Get-VIRole -Name "MyRole*" | Export-Clixml -Path C:\vmware\roles.xml

To import the roles into the new vCenter:

foreach ($thisRole in (Import-Clixml -Path C:\VMware\roles.xml)) {New-VIRole -Name $thisRole.Name -Privilege (Get-VIPrivilege -Id $thisRole.PrivilegeList)}


13.) Access rights

Since i had not much additional access rights defined, i could just list them via:

Get-VIPermission | Select-Object -Property EntitiyId,Entity,Role,Principal

With that list i set it by hand in the new vCenter.

14.) Export the location of every VM

First i had to check if i had no two VMs with the same name:

$a = Get-VM | Select-Object -Property Name
$b = Get-VM | Select-Object -Property Name –Unique
Compare-Object -ReferenceObject $a -DifferenceObject $b
Compare-Object -ReferenceObject $b -DifferenceObject $a

If the last two commands list some VMs you had to rename them and give them a unique name.

After all VMs have unique names i exported their location:

$dc = get-datacenter
$dc | Get-VM | Select-Object -Property Name,Folder | Export-Clixml -Path C:\vmware\vm-locations.xml

15.) Customization specifications

Since i had only a few ones i simply exported them in the old vCenter and imported them into the new vCenter. Like the host profiles i had to enter the passwords in the customization specifications again after importing into the new vCenter.

16.) Deactivate HA and DRS

I did this because i don´t want changes in my environment while i migrate the hosts from one vCenter to the other.

17.) Migrate the hosts to the new vCenter

Disconnect the running hosts with the running VMs on it in the old vCenter, after that you can remove them from the inventory.

Register the hosts in the new vCenter. At this step it is important to add the host at the cluster level. If you register the host at the datacenter level you can not move it into a cluster without shut down the VMs and put the host into maintenance mode.

After the hosts are registered i had to manually add them to the dvSwitches. This step normally automatically recognizes the right settings so you can just click “Next” on all steps. I select to manage the physical and the VMKernel adapter to add them to the dvSwitch.

After that it is necessary to reboot vCenter. This is because i got a error while migrating a VM from one host to another. The port groups of the dvSwitch doesn´t show up in the migration dialog window. After vCenter was rebooted it worked.

18.) Move VMs into the right folder

After registering the hosts all VMs are placed into “Discovered VMs” folder. To move them back into the correct folder i did:

$allVMs = Import-Clixml -Path C:\vmware\vm-locations.xml
foreach ($thisVM in $allVMs) { Get-VM $thisVM.Name | Move-VM -Destination (Get-Folder $thisVM.Folder) }

19.) Activate HA and DRS

After that i activated HA and DRS on the clusters and manually recreated the DRS groups and rules.

20.) Move datastores and networks into folders

Because i organized my datastores into different folders i had to manually move them into the right place. Same thing for networks.


21.) Host Update

After vCenter was migrated i configured AutoDeploy and and install vCenter Update Manager on a Windows Management VM and updated all my hosts to ESXi 6 and patched them to the actual level.

But that is another story…

Leave a Reply

Your email address will not be published. Required fields are marked *

thirty two ÷ four =