01-10-2020 02:14 AM
01-10-2020 02:14 AM
My question centers around the resizing\scaling up of personal desktop VM's in WVD without having to redeploy brand new VM's to users. I have tried the following 2 tests and both have been successful. Any reason why this would cause any issues?
Resized a VM (personal desktop) from D2s v3 to D4s v3 through the portal.
Used the ARM templates for deploying 3 personal desktop with a rdshVmSize value of Standard_D2s_v3. Ran the ARM template again deploying an extra VM with a rdshVmSize value of Standard_D4s_v3
01-29-2020 05:46 AM
No error for either. It was more a question around supportability of the two scenarios
Are there any support concerns with changing the SKU size of a single session host within a host pool?
Are there any support concerns with changing the SKU size of session hosts of a subsequent ARM deployment into an existing Host pool. i.e. existing session host SKU is D2s v3 and new session hosts will be D4s v3. So in effect, a mix of SKU's in same Host pool.
01-29-2020 07:03 AMSolution
No issue scaling up/down. The main thing you want to watch for is if you are using the ds series and provision premium ssd disks, you won't be able to scale to a size that doesn't support premium disks (aka sku's without the s).
I provisioned a WVD initially on an E sku then swapped it for a B (bursting) sku as it was a better price/performance for my clients work habits.
In some cases to see all available sku's you need to shutdown the vm, resize then boot it back up.
As for mixing sku's in a pool. The main issue you might find is how it load balances. They just have a basic breadth/depth load balancing option. If you have one machine larger, to my knowledge there isn't a way to say machine A gets 70% of logins while machine B (smaller) gets 30% (assuming multi-session). If these are assigned vm's then basically ignore what I've posted above.
01-31-2020 04:46 AM