There are a number of approaches and different technologies within the umbrella of Virtual Desktop Infrastructure.
Virtual Desktop Infrastructure (VDI) can mean different things to different people. Having more than one definition can lead to some confusion, but fundamentally, it’s a way of using virtual machines (VMs) to deploy desktops in a datacenter. You can assign these VMs to a particular user (personal VMs) or a pool of available VMs shared among users with the appropriate permissions (pooled VMs).
The modern VDI typically has some built-in intelligence. Users often don’t even have to know the name of the VM they want to use. The connection broker confirms the user credentials upon connection and finds the most appropriate VM for that user based on the permissions and rules.
The closest analogs for VDI are sessions, unmanaged user VMs and blade PCs:
Microsoft Remote Desktop Services supports desktops hosted from both sessions and VMs. You can extent the Microsoft RD Connection Broker with third-party tools to support other resource types, like blade PCs. Microsoft VDI uses the Hyper-V hypervisor and requires Windows Server 2008 R2 or later (some VDI features require Windows Server 2008 R2 SP1).
Those new to desktop virtualization may wonder whether VDI or session-based virtualization is the better choice. Generally, sessions should be the default choice. Session-based desktop virtualization is less expensive than VDI, and you can support more people on the same server with sessions than with VMs. However, VDI is a good choice when sessions aren’t an option. For example:
You can use session-based desktops and VDI to complement each other when you have differing user needs. If only a few people require VDI functionality, you can save money by giving sessions to most of your users and using VDI only for those people for whom it’s important.
You can use RemoteFX enhanced bitmap remoting with sessions, but for USB redirection or a virtualized GPU, you’ll need to use VDI. Those RemoteFX features are available only on Microsoft VDI (for more information on using RemoteFX with RD Session Host, see the links at the end of this article).
To set up a simple Microsoft VDI deployment, you’ll need:
For a lab or small pilot deployment, you can put all these roles onto a single physical server (Greg Shields wrote about doing this). For a production environment, you’ll likely split the roles among more than one physical server to improve redundancy and scale.
Setting up Microsoft VDI involves the following steps:
Sizing the VDI deployment is mostly a matter of sizing two servers: the RD Virtualization Host and the RD Connection Broker. The links at the end of this article point you to sizing guides for both RD Virtualization Host servers and the RD Connection Broker.
Sizing the RD Virtualization Host is like sizing other Hyper-V servers. The load depends on how many VMs you expect to be active, and each VM’s memory, processor and disk I/O demands. You can’t virtualize the RD Virtualization Host server because it’s a Hyper-V server.
Given the RD Connection Broker doesn’t proxy the connections to the VMs, sizing the RD Connection Broker is a matter of working out the number of simultaneous connections that the broker will need to handle. Once you’ve identified the target VM to the client, the broker is no longer involved. You can then virtualize the RD Connection Broker.
This covers what VDI is, and why you might deploy pooled or personal VMs. There are differences between sessions and VMs, and different times when each is the more appropriate virtualization choice. This ought to help you implement a simple VDI deployment. Next month’s article will cover the RD Connection Broker and its central role in VDI and RD Session Host farm deployments.
A VM snapshot will take the machine back to a particular point in time. With that in mind, make sure the VM is in a clean state when you snapshot. No one should be logged on to the VM. If the VM is powered down, do so cleanly (you don’t want the VM reverting to a state where it asks you if you want to enter safe mode).
Not a TechNet Subscriber?
Confidently evaluate Microsoft software and plan deployments with a Microsoft TechNet Subscription.