Highlighted
Enthusiast
Enthusiast

What is the best way to move the VCSA to a new host cluster?

Jump to solution

We have servers (ESXi host machines) that have reached end of life and also an older storage system that was connected to those hosts that we are transitioning from and will eventually power off and remove from this vSphere instance.  We now have added replacements for the hosts which are using Intel CPUs in place of AMDs, the new storage is also set up with those hosts, networking has been linked for the new hosts to the same distributed switch used on the old cluster, and we've tested migrating the VMs with the following configuration as described:

vCenter: VCSA 6.7 (currently operating in the old host 6.5 cluster)

Cluster 1 (old):

5x AMD ESXi 6.5 hosts

Fiber attached SAN A

distributed switch uplink set A (vDS-1)

Cluster 2 (new):

5x Intel ESXi 6.7 hosts

Fiber attached SAN B

distributed switch uplink set B (vDS-1)

We've been warned that, since the new ESXi hosts are Intel (not AMD, like the old hosts), we would need to power off the VMs before moving them to the new Intel 6.7 cluster, so a live migration/vMotion to the new cluster would not work.  We did that and had success with a few test VMs (both storage and compute resources).  We will repeat with the remaining VMs.  However, we have one VCSA managing this entire environment among those VMs, and vCenter is what manages the vMotion, correct?  So, if we must shut that appliance VM down, like the other VMs to move it to the new cluster, what is the best procedure to do this safely without negative impacts?

0 Kudos
1 Solution

Accepted Solutions
Highlighted
Virtuoso
Virtuoso

1. If one of the new Hosts have access to the SAN Storage where the VCSA is placed. Shutdown VCSA and unregister VM from old host. Register it on the new Host and power it on

2. Use VCSA to clone them self into the new Cluster. Shutdown the original... power on the clone and move on

3. Backup&Restore / Replicate the VM as any other which needs to restore from backup

4. VCSA contains a integrated Backup now. You can use this backup file and start deploying a new VCSA based on that Backup file

Most of the time i choose 1 or 2.

Regards,
Joerg

View solution in original post

0 Kudos
6 Replies
Highlighted
Virtuoso
Virtuoso

1. If one of the new Hosts have access to the SAN Storage where the VCSA is placed. Shutdown VCSA and unregister VM from old host. Register it on the new Host and power it on

2. Use VCSA to clone them self into the new Cluster. Shutdown the original... power on the clone and move on

3. Backup&Restore / Replicate the VM as any other which needs to restore from backup

4. VCSA contains a integrated Backup now. You can use this backup file and start deploying a new VCSA based on that Backup file

Most of the time i choose 1 or 2.

Regards,
Joerg

View solution in original post

0 Kudos
Highlighted
Enthusiast
Enthusiast

You can follow the below procedure to run your vCenter server on the new servers:

VMware Knowledge Base

1. Shutdown your vCenter server.

2. Login to one of the new ESXi hosts HTML5 interface.

3. Navigate to storage then open the folder that contains your VCSA VM files.

4. Right click on the .vmx file of your VCSA VM and choose Register VM.

After doing this you will see you VCSA VM in the inventory VM list of that new ESXi host. Power you vCenter VM and you will be good to go.

Please consider marking this answer "correct" or "helpful" if you think your question have been answered correctly. Cheers, @vExpertConsult www.vexpertconsultancy.com VCIX-DCV 2018 | VCIX-NV 2019 | VCAP7-CMA Design | vSAN Specialist | vExpert ** | vExpert NSX | vExpert vSAN
0 Kudos
Highlighted
Virtuoso
Virtuoso

If the vDS also use use a portgroup for the VCSA VM this port group need to be from type "Ephemeral". Otherwise you have to create such a portgroup because when you choose option 1 from above the normal vDS portgroup is not "visible" when working directly on ESXi level. The Ephemeral  Portgroup solve that problem.

Regards,

Joerg

0 Kudos
Highlighted
Enthusiast
Enthusiast

This procedure assumes both clusters have access to both storage SANs.  Unfortunately, that is not the case here.  Our original plan was to tie the two SANs together temporarily so that we could migrate the VMs this way, but we discovered that we could still vMotion the compute AND storage resources of the VMs in the old cluster to the new cluster, which is using a new SAN cluster available only to the new hosts.  The VMs still have to be powered off because the CPUs are different brands/families, but as mentioned, the vCenter is controlling the vMotion and shutting it down might complicate that process when migrating itself.

It seems, as others here have pointed out, that cloning the VCSA to the new host cluster and to the new storage cluster, shutting the original down, then powering on the clone (ensuring all properties match - i.e., network, MAC address, etc.) via the new host's GUI, would be the best course of action here.

It has also been suggested that running the VCSA as an HA/FT pair might work as well.  Anyone have any experience running a VCSA HA pair?  Is it a good idea to do this, even generally?

0 Kudos
Highlighted
Enthusiast
Enthusiast

Thanks.  Looks like option 2 would be best here since the new cluster's storage SAN is not available to the old cluster and vice versa.  The 2 clusters only share a distributed switch.  I'll have to report back with the results.

0 Kudos
Highlighted
Enthusiast
Enthusiast

I went with option 2.  I cloned the VCSA while running to a host in the new cluster and on a separate SAN datastore, then shut the VCSA down via the host it was running on, then from the new host the clone was on, powered it back on.  I took note of the MAC address (as I've read there could be issues, in which case, you'd have to assign the original MAC address to the new adapter), but didn't run into any issues once powered back on using the new adapter.  Once the services were started, I was able to get back into the web client and it's now managing the vSphere clusters.  Thanks!

0 Kudos