VMware Cloud Community
athurston
Enthusiast
Enthusiast
Jump to solution

vSAN vCenter Migration

Hi All,

I'm just looking for some clarification on a few things before migrating some of our hosts to a new vCenter.

We have multiple vSAN clusters with distributed switches. To migrate the hosts to a new vCenter is there anything i should be aware of before hand? I have migrated the distributed switch to the new vCenter already.

I have read through these links but they don't seem to match am I missing something? The current hosts are 6.5 and will be migrated to a 6.7 vCenter appliance.

VMware Knowledge Base

VMware Knowledge Base

Thanks

Alex

Reply
0 Kudos
1 Solution

Accepted Solutions
TheBobkin
Champion
Champion
Jump to solution

Hello Alex,

"To migrate the hosts to a new vCenter is there anything i should be aware of before hand?"

KB 2151610 has gradually been added to and improved since it was created and I can confirm that it does account for all the vSAN-specific variables in play.

Once a vSAN cluster is set-up it doesn't actually require vCenter to function - hosts still communicate with one another via the vSAN network, degraded components will still get rebuilt etc. . Though obviously making (some) changes, HA, vMotion wouldn't be possible until it gets vCenter back.

The only thing I can think of that that article doesn't mention is verifying the unicastagent lists + vSAN-level cluster membership vs the vSphere cluster membership before disabling IgnoreClusterMemberListUpdates and clicking the 'vCenter state is authoritative' button via the Health check.

Another tip would be re-applying the Storage Policies in bulk (but not too many- check resync after each batch) which you can do from some panes in the Web Client (but not others) using shift select, or alternatively via PowerCLi or via RVC using spbm. options.

One other thing that article doesn't mention (but assumes/implies) is adding the necessary licensing for the vSAN cluster, I will make a note with aim to have this added.

The process of migrating a vSAN cluster consists of recreating all the elements that are tied to a specific vCenter, namely: the vSphere cluster, Storage Policies and vDS. Provided these are done correctly you shouldn't encounter any major issues - though if in doubt at any point, do reach out to us at GSS.

As it sounds like you are going to be performing this with a number of clusters, I would advise doing a trial run on a lab set-up or least-critical cluster so that you can get a better feel for the steps and checks involved throughout the procedure.

Bob

View solution in original post

6 Replies
TheBobkin
Champion
Champion
Jump to solution

Hello Alex,

"To migrate the hosts to a new vCenter is there anything i should be aware of before hand?"

KB 2151610 has gradually been added to and improved since it was created and I can confirm that it does account for all the vSAN-specific variables in play.

Once a vSAN cluster is set-up it doesn't actually require vCenter to function - hosts still communicate with one another via the vSAN network, degraded components will still get rebuilt etc. . Though obviously making (some) changes, HA, vMotion wouldn't be possible until it gets vCenter back.

The only thing I can think of that that article doesn't mention is verifying the unicastagent lists + vSAN-level cluster membership vs the vSphere cluster membership before disabling IgnoreClusterMemberListUpdates and clicking the 'vCenter state is authoritative' button via the Health check.

Another tip would be re-applying the Storage Policies in bulk (but not too many- check resync after each batch) which you can do from some panes in the Web Client (but not others) using shift select, or alternatively via PowerCLi or via RVC using spbm. options.

One other thing that article doesn't mention (but assumes/implies) is adding the necessary licensing for the vSAN cluster, I will make a note with aim to have this added.

The process of migrating a vSAN cluster consists of recreating all the elements that are tied to a specific vCenter, namely: the vSphere cluster, Storage Policies and vDS. Provided these are done correctly you shouldn't encounter any major issues - though if in doubt at any point, do reach out to us at GSS.

As it sounds like you are going to be performing this with a number of clusters, I would advise doing a trial run on a lab set-up or least-critical cluster so that you can get a better feel for the steps and checks involved throughout the procedure.

Bob

dbray925
Contributor
Contributor
Jump to solution

Bob,

One of the things KB 2151610 doesn't cover is the maintenance mode. Right at the end of the host import, during the "Review and finish" process, you are warned:

Hosts will enter maintenance mode before they are moved to the cluster. You might need to either power off or migrate powered on and suspended virtual machines.

Past (non vSAN) migrations, the hosts did not need to be in maintenance mode, and the VMs would stay up and running during the entire migration. KB 215610 doesn't really hit on that topic, so I'm curious what the actual results would be. Do we need to place the hosts into maintenance mode prior to migration? Obviously that would be a little difficult if VCSA was in use.

Reply
0 Kudos
TheBobkin
Champion
Champion
Jump to solution

Hello dbray925​,

"One of the things KB 2151610 doesn't cover is the maintenance mode. Right at the end of the host import, during the "Review and finish" process, you are warned:

Hosts will enter maintenance mode before they are moved to the cluster. You might need to either power off or migrate powered on and suspended virtual machines."

Well, it doesn't mention Maintenance Mode (MM) as this isn't required for disconnecting a host from one vCenter and connecting it to another one (either into a newly created cluster Object or directly under the DC Object).

You need MM only to move a host out of (but not into) a vSAN cluster to another cluster or directly under a DC Object within the same vCenter - additionally, disconnecting it, removing it from inventory and re-adding it (wherever) actually can get around the MM requirement for moving it out of cluster to somewhere else in the same vCenter (but obviously this isn't a good idea as the MM check is there for a reason).

What "host import" process are you specifically referring to here? 'Add Host' process does not mention MM neither does 'disconnect' or 'remove from inventory'.

Bob

Reply
0 Kudos
dbray925
Contributor
Contributor
Jump to solution

Bob,

Thanks for the response. The process I'm following is:

1.) Disconnect host from old vCenter

2.) Remove host from inventory in old vCenter

3.) Add host directly to vSAN ready cluster on new vCenter

...click through and it warns about MM. This is on the latest 6.7 update 1 install.

Thanks.

Reply
0 Kudos
TheBobkin
Champion
Champion
Jump to solution

Hello dbray925​,

"...click through and it warns about MM. This is on the latest 6.7 update 1 install."

Very interesting - not updated lab yet and not had the chance the play with vC 6.7 U1 yet.

It is likely an intentional guardrail change but if this is the case then it presents a problem for a) clusters without Enterprise Plus vSphere and cross-vCenter vMotion that require everything to remain up during vCenter switch and b) clusters that are functional but for whatever reason don't have a functional vCenter and need to be attached to a new one/backup. Let me look into it on my side as this needs more clarity and whether we need to update documentation and/or alternative solutions here (bear with me as likely won't be able to look at this until after VMworld).

Bob

Reply
0 Kudos
dbray925
Contributor
Contributor
Jump to solution

Thanks Bob, I'll be doing the same, and troubleshooting this further in my lab environment.

Hope you enjoy VMworld!

Reply
0 Kudos