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

[aj800]

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?

[IRIX201110141]

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

[aj800]

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.

[MohamadAlhussein]

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.

[aj800]

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?

[AhhOkay]

I have used vCenter HA in the past to move my virtual center across clusters that were using different EVC levels and different vSAN storage.  Worked great and would be the way I would go if I had to do it again.  That is if my clusters didn't have shared storage.  If so I would probably just remove from inventory on the original cluster and add to inventory from a host in the target cluster.

I set it up and was able to fail the 6.7 vCenter over to the new cluster and then disabled HA.  You have to add some networking but once you figure that out it easy enough.

https://docs.vmware.com/en/VMware-vSphere/6.7/com.vmware.vsphere.avail.doc/GUID-4A626993-A829-495C-9659-F64BA8B560BD.html

[NickDaGeekUK]

Is it possible to use your backup solution if you have backed it up? Veeam has a replication feature that might solve your problem of having the VCSA powered down. Failing that I have used VCSA to copy itself whilst running to another host, then powered down the existing VCSA and power up the copy.

https://community.broadcom.com/vmware-cloud-foundation/discussion/difference-between-cloning-and-cold-migration#bm458e3ade-184a-4360-be14-9447c1cd4d9b might be helpful

Kind Regards,

Nick

[NickDaGeekUK]

https://4sysops.com/archives/how-to-migrate-vcsa-to-a-new-host-without-vmotion/
also of possible help

Kind Regards,

Nick

[IRIX201110141]

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

[aj800]

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!

[BB9193]

I'm about to perform this same procedure but was planning on changing the MAC of the cloned instance to match that of the original instance.

So you didn't have to change the MAC to match and all worked with a different MAC address?

[Higgster]

How did you make out?  I'm about to migrate mine from a legacy chassis/VNX config to VxRail, and I'm nervous about the networking because VxRail doesn't use standard switches. I'm not even sure a clone would work in my case, though FWIW live vMotion on other VMs has been smooth as butter.  But live vMotioning the very thing that actually manages live vMotion doesn't seem feasible. 

Also, beware the advice here, so many people have poor reading comprehension or attention spans yet offer up advice to others;  they told the orig poster to just reregister his vcsa,  completely ignoring that he clearly stated he is doing a data migration as well.  It's scary that these people run systems, but that's the 21st century for you.

[CSpreha]

Another trick is to use any kind of NFS you may have installed, or even install free TrueNAS in a VM to create an NFS datastore, mount it to the hosts required, do a live storageVMotion to the NFS datastore, shut down VCSA, unregister, register on new host, boot up, strorage vMotion to its storage.  I do that in my home lab a lot.

[hdhjclark]

Apologies for resurrecting this old thread. IN case anyone else finds their way here I wanted to throw out another solution. It is similar to #4 IRIX201110141 . VCSA deployment will do the process for you. Download the ISO, mount it, run the GUI Installer. It will ask you where you want to put the new VCSA and replicate the entire configuration from the "old" VCSA. It will also shut down the old and spin up the new when it is complete.