Migrating VCSA

[Artaheri]

We currently have two ESXi hosts with replication of VMs handled by Veeam. We have a vSphere Essentials license so no vMotion.

Our virtual environment is connected to Veeam using vSphere on a VCSA VM that sits on one of the hosts.

I am trying to plan the best method for migrating the VCSA VM for the purposes of updating the host it sits on. I assume I can't do a regular planned failover, because as soon as Veeam shuts down the VCSA VM as part of the process it will lose connectivity with the environment.

One idea is to temporarily add the ESXi hosts via IP, perform a quick migration or failover referencing the VCSA VM through this connection, and then do the same to move it back before removing the IP referenced hosts.

The other would be to perform a "non-planned" Failover, so the original source VCSA instance stays up until the replica is online, before being shut down. However I am not sure if having two instances online at the same time would be ideal.

Is there an option I am missing, or would one of these be the best way to migrate a VCSA instance to a new host?

Thanks for any advice

[HannesK]

Hello,

However I am not sure if having two instances online at the same time would be ideal.

I'm sure that this is a bad idea Starting from IP address conflict, Veeam would connect "somewhere"...

For updating a host, I would just keep VCenter down (I did not see why you want to have it running).

non-planned failover works if VCenter can live with "power-off" (which it should). Adding he ESXi hosts directly would be an alternative. But the software might run into licensing issues.

Best regards,
Hannes

[Origin 2000]

We also have a lot of customers with Essentials or just one Hosts. Questions is for what reason VCSA needs to move and does it matter when VCSA is not available for a period of time which shouldn't be a issue in a very small SMB environment.

Is your goal patching a ESXi with VUM indeed VCSA needs to move i see 2 options
1. Clone the VCSA VM with help of vCenter to the other Host and when finishing shutdown the first VCSA off and power up the clone. Same can be archive with a normal Veeam restore/replication. Indeed when you would like to use instant restore you need to add the ESXi directly into Veeam and not only "trough" vCenter. This can be done by add the Host by IP or FQHN(need the opposite compared how added into VCSA). If you are done with patching shutdown the clone and fire up the original again
2. patch the ESXi from the command line which takes 60sek. and a Host reboot when ESXi is allowed to reach *.vmware.com. Otherwise use a OfflineBundle. VUM can be later used to check if the Host is up to date

Regards,
Joerg

[Artaheri]

For updating a host, I would just keep VCenter down (I did not see why you want to have it running).

Hi Hannes, the reason for having vCenter running would be so we can use VUM to perform the update.

non-planned failover works if VCenter can live with "power-off" (which it should). Adding he ESXi hosts directly would be an alternative. But the software might run into licensing issues.

I assumed a non-planned failover would fail if vCenter was powered off, because Veeam uses vCenter to access the virtual environment. This is why I was thinking of adding the hosts via IP for the duration of the update process.

[Artaheri]

Is your goal patching a ESXi with VUM indeed VCSA needs to move i see 2 options
1. Clone the VCSA VM with help of vCenter to the other Host and when finishing shutdown the first VCSA off and power up the clone. Same can be archive with a normal Veeam restore/replication. Indeed when you would like to use instant restore you need to add the ESXi directly into Veeam and not only "trough" vCenter. This can be done by add the Host by IP or FQHN(need the opposite compared how added into VCSA). If you are done with patching shutdown the clone and fire up the original again
2. patch the ESXi from the command line which takes 60sek. and a Host reboot when ESXi is allowed to reach *.vmware.com. Otherwise use a OfflineBundle. VUM can be later used to check if the Host is up to date

I think option two may be the easiest. I do like using VUM for updates but the command line or offline bundle would probably be an easier way than having to deal with the vCenter migration.

Option one with adding them by IP is the other option I was considering, but it maybe is just too much extra work to add the hosts via IP then remove them again, combined with command line updates.

[Origin 2000]

+1 for Option 2.

[HannesK]

as I read my answer again... I think I chose bad wording... with "non-planned" failover my idea was to just power on the VM directly on the ESXi host.

I would go for upgrade without VUM. That whole process sounds too complicated to me.

[Artaheri]

Thanks for the thoughts, command line seems to be the way to go!