kgsivan wrote:

Rebalance is not a simple delete and re-create action. Even the Desktops are non-persistent, there are persistent disks associated with it. like (Internal disk)

These carries data like domain membership trust and all. Therefore, without a shared datastore, preserving and migrating such internal disk is impossible (and prevented).

Now for you case, since it is floating desktops (non- persistent),

1. De-select the datastore of the host to be patched by editing the pool.
2. Logoff active sessions (if any) for the specific VMs / put the VM into maintenance mode.
3. Delete Those specific VMs through *View administrator Pool Inventory*
4. Configure back the datastore spec layout after patching host,
5. And then increase the pool size to the desired numbers

I understand that the move and refresh operation will indeed be quicker, and this is not possible with local storage.

It would be nice to have the option on rebalance to "delete and recreate" or "move and refresh (default)" - but perhaps I am in a unique position where there is not enough demand for this type of feature.

One thing - after deselecting the datastore, I did notice that choosing rebalance did "do something" to some desktops. I'm not sure what. There were the desktops that had "task halted" as well.

Oh well.

Anyway, thanks for your advice. I am doing:

1. Done (as per your 1)

2. Delete any remaining "active/provisioned" desktops on that datastore (Through Pool Inventory).

3. Instead of forcing users to logoff (as they are still using sessions) we wait for logoff. On logoff the, desktop is deleted. -- Once this has happened, there should be no more desktops on this datastore.

4. Done (as per your 4)

5. This is a strange one - I didn't decrease the pool size in the steps above (our servers have enough overhead to take the full pool size with one server down). I'm assuming that when desktops on the other datastores are deleted (logged off) one by one, they will be spun up on this restored datastore (one by one)?

Thanks