Splitting Up My Cluster for VDI

[Super6VCA]

Good Morning Everyone,

We currently have a cluster consisting of 5 hosts running vSphere 6 with 175 VM's (servers and VDI).  I would like to take two hosts and Dedicate them strictly to my VDI and leave all the Servers on the other 3 hosts.  Am I able to create a new cluster with another vCenter server and move the VM's or do i need to start from scratch.  Never had to perform anything like this so any help is appreciated very much.  Thanks

[kermic]

First question - are there any requirements to implement a second vCenter? (licensing f.x., like in case you are moving from Add-On to All-Inclusive Horizon license)

If not, you can just create 2 clusters under your existing vCenter. Preferably leave the original cluster for View, create another cluster for server workloads and then move intended hosts and server VMs to the new cluster.

By leaving the original cluster for View you can potentially eliminate re-configuring your View environment for this change.

If you need to implement a second vCenter so that one manages strictly VDI and another one works with everything else, again it is probably easier to leave the existing vCenter for View (you can easily change the license on it after moves are done) and implement a new one for everything-else-but-VDI workloads. At this point you might need to take a look at vCenter migration articles and tools. Depending on complexity of your inventory (whether things like resource pools, tags, folder hierarchies, distributed switches, custom roles and permissions, etc. are in use) this might be a piece of cake or not so piece of cake type of task, but it's definitely doable.

Assuming the infrastructure pre-requisites are in place, you should be able to perform any of the scenarios above without any downtime.

Hope this helps.

[Super6VCA]

Awesome!  Thank you!  The environment is pretty simple.  No dis Switches or complexity involved in this cluster at all.  I was more concerned with the Vcenter database and the View database.  We are licenses for a view environment with it's own vCenter and thought it might be better that way since we are getting bigger with VDI.  Any other suggestions you might have i would appreciate it.  Thanks again for the reply.  I really appreciate the input. 

[kermic · Accepted solution]

Splitting up VDI vs vServer environments is normally a best practice (now called Guideline)

If you have Ent+ license and external PSC, you could join the new vCenter to the existing SSO domain during installation which would allow cross-vCenter vMotion. Nice and neat feature, could be helpful when moving objects from one vCenter to another.

If license is Enterprise or lower, you should still be able to move everything without downtime. There are automation tools and scripts out there, however if the environment is simple enough, this can as well be done manually.

Below procedure uses hosts as "vehicles" for live transportation of VMs from one vCenter to another

1) install the new VC

2) put the first host, intended to move, into maintenance mode and move out of the cluster into datacenter (depending on HA configuration, admission control might prevent you from entering maintenance mode. if so, disable it temporarily, remember to re-enable once migration complete)

3) migrate a bunch of server VMs (intended to move to new VC) to the host outside the cluster (do some planning so that remaining to-be-moved vms can actually fit on remaining to-be-moved hosts in terms of cpu/mem)

4) remove the host from original vcenter

5) add the host to desired place in inventory of new vcenter. All VMs should still be there, still running, still connected to standard portgroups and operational

6) repeat steps 2-5 for remaining hosts and vms that you intend to move

7) configure the new vCenter's inventory as needed

😎 long live the new vCenter!

The new vCenter will read automatically from added hosts:

- registered VMs

- standard switch config

- connected datastores

- local host settings

The new vcenter will not have the following:

- tags, if any were used on source VC

- folder hierarchy

- custom roles and object permissions

- host profiles

- cluster settings and resource pools

- VM templates

- vApps

- performance history

Everything (except performance history) from non-migrated things can and should be recreated on destination VC manually.

I'm typing from top of my head with quite a few assumptions in mind therefore please check accordingly if any deviations / additions are needed in your particular environment. Potentially you could do a test-drive of one host with a not so critical VM on it, forth and back.

[Super6VCA]

Awesome post!  Thank you for that.  Would you still suggest leaving all the VDI in the original vCenter?  Reason i ask is that i think Horizon View uses the folder hierarchy and didn't want to mess that part up.  

[kermic]

Yepp, don't move the VDI objects. If need to move, move everything else (unless you forgot to mention that you have a monster add-product infrastructure tied up to your vCenter and working with server VMs / private or public clouds etc).

View has quite a few moving parts, especially if you use linked clones / composer (that thing is tied up to a particular VC and stores quite a bit of info about vCenter VMs in it's own database). View can be re-pointed to another vCenter however that would most likely involve reprovisioning some if not all of your desktop pools. Not sure if you want to go down that route. I wouldn't, as long as there is at least a slight chance to avoid it

Another thing that popped up in my mind, probably worth considering - in one of the clusters you will most likely be left with 2 hosts. Failure or maintenance of a single host in that cluster results in 50% decrease in compute and IO resources and no further availability protection. Good reason to either wait with the split operation or start negotiating purchase of an additional host soon. Good news - if you have the full View license, only hardware and provisioning costs involved. Bad news - hardware procurement and provisioning costs are still there. (management definitely needs to be made aware of the bright side :smileygrin:)