RDS-V provides remote desktop access to managed desktop environments hosted in Hyper-V on Windows Server 2008 R2.  OK, there are way too many technical buzzwords in that last sentence, aren’t there?  Simply put, in the same way that RemoteApp makes applications available to users through individual Remote Desktop Services sessions, RDS-V provides access to specific virtual machines (desktops) through a similar mechanism.  So, what does it really do?

RDS-V uses the Remote Desktop Connection Broker to determine where the user is redirected.  If a user is assigned and requests a personal virtual desktop, RD Connection Broker redirects the user to this virtual machine.  If the VM is not turned on, RD Virtualization turns on the VM and then connects the user.  If the user is connecting to a shared virtual pool, then the RD Connection Broker checks to see if the user already has a connected session in the pool.  If the user has a disconnected session then they are reconnected to that VM.  If the user does not have a disconnected session, a VM in the pool is dynamically assigned to the user – if one is available.  A quick note here, the Hyper-V server role has to be installed on the same system that has the RD Virtualization role service installed.  Let’s take a quick look at the fairly simple high-level RDS-V topology:

The different components of RDS-V are as follows:

• Connection Broker – given an authenticated user and their associated request for an application or desktop, the Broker determines which RDS Server or VM image can best satisfy the request
• Redirector – RD Session Host Server whose purpose is to query the Broker on the RDS Client’s behalf.  After querying the Connection Broker, the Redirector sends an RDP redirection packet back to the RDS Client
• RDS Assignment Database – representation of the AD Schema extensions that provide end-user mappings to a particular VM Host image
• Web Portal – web page that shows the user all the applications / desktops they can access
• VM Host – Machine on which the VM images are hosted.  The VM Host Agent service runs on this machine.  The service is controlled by the Connection Broker and can perform certain actions such as spinning up a VM image

The diagram above breaks out the different components and their functions.  Let’s take a closer look at the Connection Broker’s functions:

There are some basic steps that the Connection Broker performs.  If the endpoint for the request is a farm, then the Connection Broker has to check the cache of user sessions to see if there is an existing disconnected session within that particular farm.  The key here is that the disconnected sessions are farm-specific. If the user does not have a session, the Connection Broker chooses the best machine or VM image within the farm.  There is also some machine logic that takes place.  Connection Broker calls into the type-specific VM Plug-in to carry out what is called Placement.  This action involves the plug-in move the necessary VM image to the best VM Host and then return the name of that host.  For VM calls specifically (as opposed to RemoteApp requests), the Connection Broker calls into the VM Host Agent to spin up the VM image.  This is called Orchestration.  The return value of this step is a list of IP addresses for the final machine / image to which the RDS Client should be redirected.  These steps are executed each time a user connects.  In addition, the Connection Broker also has a “Pool Creator”.  This component coordinates the creation of VM farms by directing VM Host Agents to create farm-joined VM instances out of template VM images.

Source: http://blogs.technet.com/askperf/archive/2009/10/17/windows-7-windows-server-2008-r2-remote-desktop-services-virtualization-rds-v.aspx