Nerdio AVD desktop pools are great. They enable auto-scaling to save on costs and simplify image management with a centralized template that can be pushed out to all session host. In this article, we’ll break down the logic behind the operation of Nerdio AVD desktop pools, explain some use-cases, and discuss some terminology to be aware of.
First and foremost, it’s important to understand the different components of a Nerdio AVD desktop pool. As you can see from the image below, there are three key components:
- Golden Image desktop
- Nerdio AVD desktop Pool Template VM
- Individual AVD Session Host VMs
Golden Image Desktop (GI) – This is the standard image for your environment. All pool template VMs & individual users’ virtual desktop sessions will get created based on the GI. We encourage admins not to make very specific user customizations to the GI. It should contain applications that are common to all, or most, of the users in the deployment.
AVD Desktop Pool Template VM – The pool template is where most of the customizations begin. It’s the standard for every session host within that specific pool. So, this is where you set things like the VM series size (CPU and RAM), drive capacity (OS disk size and performance), unique applications specific to the members in that pool, and anything else that would apply to all users being assigned to that specific pool.
- Our partners sometimes ask why they should create multiple pools. Couldn’t they just place all users onto one pool? While in theory that would be possible, there are many reasons to assign different users to different pools. Below are just two examples:
- User specific performance requirements: Let’s say you have three different user types: Task users, knowledge users, and power users. You don’t want to put all of them on a single desktop pool based on a single template VM. A single power user could max the resources of a lower VM series, making any subsequent users who login experience slowness because of low system resources. In contrast, a task user assigned to a large VM series pool might have a session host spun up that’s 10x larger than what they need for their session.
- Geographic Location: In large deployment that have locations across the country or the world, you wouldn’t want session hosts to begin scaling in at the end of the day for the East Coast branch, and subsequently cause performance issues for the West Coast one. Similarly, you wouldn’t want extra VMs left running when not required simply to accommodate the different time zones. Separating these locations into their own separate AVD desktop pools solves these issues.
Session Host VMs – It’s best to see session hosts as non-persistent VM’s. They are deleted at a frequent rate, by default, through the autoscaling rules in place on the Pools. As a result, it’s important to remember that any permanent changes that are intended to be persistent across the environment should take place on the Template VM, not an individual session host. The only time to make a change on the session host is when testing. The hosts give you a good non-persistent environment that you can work on testing changes. If things go well, simply apply the final changes to the template VM, set it as image, and update the individual session hosts. However, if the changes aren’t working in your testing, simply delete the session host, create a new one (which will create as a clone of the template VM) and continue working as if nothing happened.
That covers the different components of a Nerdio AVD desktop pool. Now, let’s take a look at some terminology that you should be aware of.
Terminology
Scale-In vs. Scale-Out – The addition or subtraction of a session host within a specific desktop pool.
- As an example, if I currently have four session hosts in Pool_A, then scaling-in would bring the number down to three, and scaling-out would bring the number up to five.
Scale-Up vs. Scale-Down – Increasing or decrease the size of the session host (or template) VM by adding or removing CPU, RAM and storage.
- As an example, if my template is currently running with a D4sv3 VM series (4C / 16GB RAM), then to Scale-Up would be to change the VM size to a D8sv3 (8C / 32GB RAM) and to Scale-Down is to reduce the VM size to a D2sv3 (2C / 8GB RAM). This change would be made to the Template VM level and then get pushed to the session hosts in the pool via the update process.
Standby Host
A Standby Host is configured to be a session host that is created but powered off (de-allocated in Azure). This way when a user tries to sign into an already over-allocated host, and the scale rules get applied to add a new host, Azure simply needs to boot up the Standby host, rather than completely recreating a new host from scratch. This saves time and allows for session host capacity to be available to service user requests sooner.
Final Thoughts
This concludes our conversation regarding AVD pools. The most important thing to remember when making modifications in a AVD pool is the hierarchy of Golden Desktop Image>Pool Template VM>Session Host>User desktop session. As long as you keep that in mind and understand that any changes made to the session host VM get blown away after a scale-in/out or update, you should be good to go.
