Skip to main content

Migration Assistance (Migrating Windows vCenter to VCSA 6.5 )




Migrating vCenter from one version to another was always a complected task earlier. With the introduction of migration assistance tool which was introduced in 6.0 u2 version,life of the administrator become far easier without worried about multiple components configuration task during migration as most of the task performed in this tool are automated. The risk of mistake and miss-configuration has become lesser during deployment.
So, lets gets started. 
Here we are migrating windows based vCenter with embedded PSC to VCSA 6.5
Download the ISO or binary of VCSA 6.5 from the VMware portal.
Once you have ISO of VCSA mount it into vCenter.
Step 1
Run the migration assistant tool which is present under <Mounted Drive>:\migration-assistant\VMware-Migration-Assistant
Note: This "Migration-Assistance tool need to be executed on windows vCenter and once run, it will automatically detect the vCenter instance runing on the machine.
windows-to-vcsa-1
Step 2
Once the administrator@vsphere.local’s password is keyed in, it will start running the scripts to do pre-checks of the required configuration.
windows-to-vcsa-2
Once the prechecks are complete, the wizard then preps the windows vCenter to be migrated to the vCSA. This window has to run until the migration completes failing which the process will fail.
windows-to-vcsa-3
Step 3
Now since one of the steps in migration is to power of the source VC and move it’s network identity to the newly deployed vCSA
The next steps of the actual migration process itself have to be run from any other machine which has connectivity to the source VC and the destination infrastructure to deploy the new vCSA server.
Mount the v6.5 ISO to the identified machine that meets the above condition and run the migration wizard by going to : <Mounted Drive>:\vcsa-ui-installer\win32\installer
Once the below wizard pops up, click on Migrate
windows-to-vcsa-3-1
Step 4
This starts another wizard that starts the deployment of the vCSA appliance. This again is broken down into two stages. The first one involves deploying the appliance and the second one involves configuring it
windows-to-vcsa-4
Accept the EULA and continue.
windows-to-vcsa-5
The next step requires the details of the source windows vCenter and the credentials for the SSO administrator
windows-to-vcsa-6
When the wizard establishes a connection to the source VC, it presents the certificate thumbprint which has to be accepted to proceed further. Click on Yes and continue.
windows-to-vcsa-7
The next step is to provide the details of the destination vCenter or the ESXi Server where the new vCSA will be deployed.
windows-to-vcsa-8
Accept the certificate thumbprint and continue
windows-to-vcsa-9
Specify the VM Name and root user password for the vCSA
windows-to-vcsa-10
Select the deployment size for the vCSA. Since I had a small deployment with an embedded PSC, I’m choosing the tiny instance. Note that the resources consumed by the vCSA changes across the deployment sizes
windows-to-vcsa-11
Select the datastore where the vCSA will be deployed, choose thin disk if required
windows-to-vcsa-12
In order to have an IP communication with the source vCenter, the deployed vCSA will need a temporary IP during the migration phase. Once the migration is complete, the network identity of the source VC will be assigned to the vCSA
windows-to-vcsa-13
Review and Finish. This will start the deployment of vCSA
windows-to-vcsa-14
This will kick-off the deployment process
windows-to-vcsa-15
Once the stage 1 is complete, the appliance configuration will start
windows-to-vcsa-16
Step 6
You can see from below picture that there is a green tick for stage 1 which means the Stage 1 has completed successfully with no error.
windows-to-vcsa-17
When you click Next, the pre-migration process kicks in
windows-to-vcsa-18
This checks the compatibility with all the components and extensions that are registered with the source vCenter and the vCSA once the migration completes. I have an older version of vRO which might not work with the new one, hence the warning.
windows-to-vcsa-19
The vCSA can be joined to the domain using the AD credentials
windows-to-vcsa-20
In the next step, the wizard let’s us select the data that needs to be migrated from the source to destination. This can only be configuration or everything including events, tasks and the performance data
windows-to-vcsa-21
Once that is completed, you can optionally join the CEIP. I usually skip this
windows-to-vcsa-22
Confirm the details and start the migration
windows-to-vcsa-23
Note that the source VC shutdown during the migration as it’s network identity will be migrated to the vCSA. Also, this is the exact reason this wizard should not be run on VC as the migration status will not be known if the machine shuts down
windows-to-vcsa-24
The data transfer might take anywhere between 15 mins to an hour depending on the amount of data that has to be migrated
windows-to-vcsa-25
Once the copy is complete, the machine is configured with the required services and data is imported
windows-to-vcsa-26
The impressive thing about this method of migration is that it preserves everything from source to destination. You can see that even the certificates are imported and applied on the vCSA. And another good thing is the shiny new UI that the new vCenter is built on
windows-to-vcsa-27


Enjoy using vCenter 6.5 
In VCSA 6.5 try to take advantage of HTML based vSphere client. Its having quite cool features.

Happy Sharing.... :)

Comments

Popular posts from this blog

Changing the FQDN of the vCenter appliance (VCSA)

This article states how to change the system name or the FQDN of the vCenter appliance 6.x You may not find any way to change the FQDN from the vCenter GUI either from VAMI page of from webclient as the option to change the hostname always be greyed out. Now the option left is from the command line of VCSA appliance. Below steps will make it possible to change the FQDN of the VCSA from the command line. Access the VCSA from console or from Putty session. Login with root permission Use above command in the command prompt of VCSA : /opt/vmware/share/vami/vami_config_net Opt for option 3 (Hostname) Change the hostname to new name Reboot the VCSA appliance.   After reboot you will be successfully manage to change the FQDN of the VCSA . Note: Above step is unsupported by VMware and may impact your SSL certificate and face problem while logging to vSphere Web Client. If you are using self-signed certificate, you can regenerate the certificate with the

Issue : Configure Management Network option is Grayed out into ESXi

Last week I got into an issue of one of my client into Vsphere environment where one of its ESXi went done out of the network. Issue was IP address was showing 0.0.0.0 on main Esxi screen and when I tried to change the network configuration, its " Configure Management network option was greyed out.  I tried to gid into it and try to analyis its vmKernal and vmwarning logs. What I found is its VMkernal switch got removed due to unexpected reason. So to resolve the issue I tried to reconfigure its vswitch0 (vmk0) by going into Tech Mode of that Exi. Below are the steps which I followed to resolve the issue. 1) Login to ESXi 2) Press F2, Check if you " Configure Management network " is greyed out or not" if yes,    follow below 3) Press ALT+F1 to move the ESXi screen to tech mode   ( This is command line like dos) 4) login with root account 5) Run the following command into it esxcli network ip interface add --interface-name= vmk0

Collecting Logs from NSX-T Edge nodes using CLI

  This article explains how to extract the logs from NSX-T Edge nodes from CLI. Let's view the steps involved: 1) Login to NSX-T  Edge node using CLI from admin credentials. 2) Use of  " get support-bundle " for Log extraction. get support-bundle command will extract the complete logs from NSX-T manager/Edge nodes. nsx-manager-1> get support-bundle file support-bundle.tgz 3) Last step is to us e of " copy file support-bundle.tgz url " command. copy file will forward your collected logs from the NSX-T manager to the destination(URL) host from where you can download the logs. copy file support.bundle.tgz url scp://root@192.168.11.15/tmp Here, the URL specified is the ESXi host ( 192.168.11.15) under /tmp partition where logs will be copied and from there one can extract it for further log review. Happy Learning.  :)