vCenter Server Migration

[andrewpeplinski]

I've got an odd one, looking for advice (and before I get started, I know the use-case is a bit odd, but it's what has been identified as the chosen architecture configuration):

We have an existing set of linked vCenter Server Appliances sitting in a cluster using a standard switch, they are the only two vCenter instances, and handle everything; we need to migrate them to a stand-alone host which is off the DVS while ensuring no loss of data and minimal downtime.

My thought is to either use the vSphere Replication Appliance to replicate them, fail them over and not fail back, break replication and just use them where they are; another option I considered was to clone them over to the new location and cut over (although that would take 1-2 hours for each one, so leave a mismatch in data between the two instances, as well as leave a "-clone" named VM as the vCenter server); the third option is to back up the vCenter instance, deploy a new one in the new location and apply the backup (but then you're dealing with data mismatch again); the "final option" would be to shut down the vCenter server, copy it to the new location and bring it up there (but there are so many things that could go wrong there I was not really entertaining it as an option).

Like I said it's an odd one, and I can't find anything resembling a "best practice" for this, so I'm looking for advice or guidance.  Thanks in advance :).

[a_p_]

It's hard to give an advice without any knowledge of your environment.

Anyway, wouldn't it be an option to temporarily add the standalone host to the vCenter Server environment, to perform a live migration?

André

[markey165]

@andrewpeplinski  - I can't even begin to imagine why it would be designed in the way you describe for architectural reasons. By doing this, you are removing every feature of vSphere that makes your vCenter resilient, eg HA, DRS etc. In the setup you describe, your ESXi hosts are Single Points of Failure! I'd be keen to understand the reasoning behind the design choice if you know why? I can't think of any benefit that running it on a single host provides?

Assuming you have to plough ahead, of the options you've suggested, i would personally just go with the last one. Its a perfectly supported and easy way to move a VM between hosts. Simply power it off on the source ESXi host, export it as an OVF, then re-deploy the OVF on the target host. Power it on, and its back online. Very easy. What are the things you're worryied about that could go wrong? The only thing you have to ensure is you have the same network available on the target host, and if any problem arises, just power the original VM back on again. If you want to test it first, simply create a VM of the same size, and run a test migration with that first. That will allow you to see how long it will takes. No messing about with replication or cloning required.

HTH 😊

[andrewpeplinski]

@a_p_ We've already added the stand-alone host to vCenter, but because of the cluster settings we can't vMotion the vCenter VM to the other host.  I guess we could disable the cluster settings temporarily, but some of the features (thinking EVC here) might require restarting the vCenter VM.

[andrewpeplinski]

@markey165 Thanks - yeah, I've tested the cloning and it takes a couple of hours, so we'd have to plan a good maintenance window.  My issue was in the copying - sometimes if it's interrupted it can cause data corruption; I had forgotten about an OVF export, that could solve that issue.

The other possible snag is that it's in linked mode with a second vCenter (which will likely also have to be migrated).

The primary answer of why to architect it this way is because that's how it was architected previously, and we are attempting to get back to original-state.  Above and beyond that, it does allow for some consistency of host management in the remaining hosts - currently the vCenter VM is on a standard switch, so it's limited to a single host anyway, so the existing host profile is complaining regularly.

[a_p_]

>> ... but because of the cluster settings we can't vMotion the vCenter VM to the other host.

No need to add the host to the cluster. As long as the new host supports at the current hosts' CPU features (likely with a newer host) you should be able to do a live migration.

André

[andrewpeplinski]

@a_p_ Yes, I understand - I didn't add it to the cluster at all, but the settings on the existing cluster (EVC etc) prohibit migration.  And further (sadly) the target host is woefully out-of-date, and its hardware isn't even close to matching the spec of the existing host.

Here are the errors it lists:

Use a cluster with Enhanced vMotion Compatibility (EVC) enabled to create a uniform set of CPU features across the cluster, or use per-VM EVC for a consistent set of CPU features for a virtual machine and allow the virtual machine to be moved to a host capable of supporting that set of CPU features. See KB article 1003212 for cluster EVC information.

CPUID faulting is not supported.

Fast string operations (Enhanced REP MOVSB/STOSB) are unsupported.

Supervisor Mode Execution Protection (SMEP) is unsupported.

Instructions to read and write FS and GS base registers at any privilege level are unsupported.

RDRAND is unsupported.

Half-precision conversion instructions (F16C) are unsupported.

MOVBE is unsupported.

FMA3 is unsupported.

[andrewpeplinski]

@markey165 I've actually read a few places that having vCenter external to the cluster is a bit of a "best practice" as it still manages all the hosts correctly, does all of its work, but isn't subject to the constraints of the production cluster.  Now, in a perfect world we would have at least two external hosts in their own HA situation so as to accommodate any host failures (at least one), but that's not what I've been given (not even getting into the fact that the VM will be sitting on local storage on that target host).

[andrewpeplinski]

We went with the VSphere Replication Appliance, and it worked fine (once I stopped panicking that I couldn't log in to the VAMI with the SSO admin).  We will continue to use it for backup of the VM to shared storage in case of that host failure, so overall a pretty solid process and we are good to go.

Thanks both of you for the assistance and opinions.