Back in 2006, I posted an article about how to get Glass running in a VM. 
The trick was to use Remote Desktop on a Glass-enabled machine to TS into a VM which is running the same OS.  If the build of the OS on your workstation is different than the one in the VM, Glass won’t work.

With the release of the Windows Virtual PC for Windows 7 Release Candidate, this subject has come up again in a post from the RedmondPie.com folks.  They noticed that if you enable the Integration Services in a Windows 7 VM, you’ll get Aero Glass!

This may be news, but it’s actually the same ol’ story.  The reason that enabling Integration Services gives you Aero Glass is because it uses Remote Desktop technology to show you the video from the Virtual Machine.  That also helps to explain why installing Vista (or a build of 7 that is different than the one on the host) doesn’t give you Glass.

Now, you might be asking yourself why – if this is true – do you not get Glass in Hyper-V while using VMConnect?  After all, VMConnect uses Remote Desktop technology to show you the VM Video, too. 

To explain this, I asked Ben Armstrong what was going on, just to make sure that I understood it correctly (for the record, I didn’t).  Ben thought deeply for a second, and knew that the best way to explain this to me was to draw pretty pictures on my whiteboard.  I’ve tried to reproduce them below1:

Windows Virtual PC

Hyper-V
My picture is prettier than Ben's was. Yay Visio!
 
In the illustrations above, you can see that the architecture is somewhat similar between Windows Virtual PC and Hyper-V (with respect to video, anyway).  In both cases, an application that uses the RDP ActiveX control (MSTSCAX.DLL), like VMWindow.exe or VMConnect.exe,  for video remoting hooks into a process which hosts the RDP encoder.  If no integration components are installed in the guest OS, video is handled by our emulated S3 video adapter, which gets passed back through to VMWindow or VMConnect.
 
If integration components are installed and enabled, there’s a different option. 
 
In Hyper-V, the RDP encoder talks to the Video Virtual Device (VDEV), which communicates with the child partition via a communications bus called VMBus, allowing it to talk directly to the synthetic video adapter (SynthVid VSC) that is running in the child partition.  SynthVid then sends frame buffers back across VMBus, back to the Video VDEV, where it’s picked up by the RDP encoder, finally making the video show up in VMConnect.
 
In Windows Virtual PC, the RDP encoder makes a connection to an RDP endpoint inside the guest OS via a communications bus called VPCBus.  In this specific scenario, VPCBus is essentially acting as a network transport, allowing an RDP connection to be made from the host OS to the guest OS without the use of a network (which is why this works even if you don’t have a network adapter in your guest OS).  Now, you don’t have an RDP connection to the guest all the time – when the guest boots there’s obviously no RDP endpoint to connect to.  At that point, you’re using emulated video.  As soon as the integration components come online and are successfully enabled, Windows Virtual PC creates a Remote Desktop connection to the guest OS, and seamlessly switches over to using that for video.
 
And that’s the secret sauce behind getting Glass in Windows Virtual PC and not in Hyper-V:  Hyper-V transmits frame buffers which are then rendered into video by the RDP encoder, while Windows Virtual PC actually creates a Remote Desktop connection, which can use all of the pixie dust necessary for Aero remoting to work.
 
So why doesn’t Hyper-V do this too? 
That’s a topic for another blog post.
        

1Please note that these images are not necessarily technically accurate – their only purpose is to help demonstrate concepts relevant to the conversation.