Virtual Varia : Hyper-V Here's Why

Aero Glass? In my Virtual Machine? It’s more likely than you think…

mikekol — Thu, 13 Aug 2009 02:37:05 GMT

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 below¹:

*Windows Virtual PC*	*Hyper-V*

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.

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

Does restoring a snapshot break domain connectivity? Here’s why.

mikekol — Wed, 18 Mar 2009 23:55:09 GMT

This is a pretty common question on our internal mailing lists, and I’d imagine that it’s common outside of Microsoft as well, so I thought it would make a nice blog post (since I’m way behind on blogging…).

So, you have a VM that’s joined to a domain and working perfectly. You take a snapshot so you can restore to this magical point of workingness at any time, and life is good.

One day, you need to fire up this VM and test something, so you revert to your snapshot and start the VM. That’s when you’re told that the domain doesn’t trust your (virtual) workstation anymore. What the heck just happened? No changes were made to the snapshot! That’s why it’s called a snapshot! Why did this break?

Well, you’re right. No changes were made to snapshot, and that’s part of the problem.

It’s part of the default Active Directory domain policies for a domain member to change the password for it’s account every now and then. You’ve no doubt had to change the password for your User Account occasionally, so this shouldn’t be a surprise. What may be a surprise is that the same thing happens for Computer Accounts. That’s right – computers have accounts, too.

Every now and then (by default, it’s 30 days, but the value is configurable via domain policy), the workstation will negotiate a new password with the domain. It all happens behind the scenes, so you’d never know it. It just works.

Unless you, you know, have a domain-joined VM with snapshots.

The problem comes about because the workstation – at some point – negotiated a new password with the domain and recorded it for future use. Then the snapshot was applied, and you turned your VM into a time traveler. This VM from the past was brought into the future, and has no knowledge of anything that happened in the interim. So, it thinks that it’s old password is still good. And it tries to use that password. And the domain says “um, no”.

Well that’s stupid. Why does Hyper-V let this happen?

It’s not just Hyper-V. Many years ago, in my previous life as a network admin, this happened all the time to my VMWare images. The same thing will happen in any situation where you convince Windows that the computer account password is something that it’s not (like restoring a snapshot or any other kind of backup).

Fine. What can I do about this?

There are three possibilities that I’m aware of. If anyone has any other suggestions, please feel free to leave them in the comments.

If you can, change the default domain policy, or get an exception created for your computer account(s).
This is not the best option because it opens up a security hole (small as it may be).
Log into a local administrator account on the system and leave the domain. Then rejoin it. The computer account will get updated with a new password that your workstation knows. Alternately, you could use NETDOM.EXE to reset the computer account password.
You could even automate this if you need to.
Sysprep the VM and create an unattend file that will configure it to your liking, and that will automatically join the domain for you. Once the machine is sysprep’d, make a snapshot and restore to that one from now on.

Hope that helps.

How to use VMConnect to create an .RDP-like shortcut directly to your VMs

mikekol — Wed, 03 Dec 2008 00:42:50 GMT

The Remote Desktop application in Windows has a nifty little feature where you can save all of your custom settings for a specific remote computer to a single .RDP file, and then just use that .RDP file as a shortcut to connect to that remote computer instantly.

VMConnect, which is the name of the application that you use to connect to the console session of a Hyper-V Virtual Machine, doesn’t have that option.

Curses! What is an administrator to do!?!

Well, if your VM is running Windows, you could always Remote Desktop directly into the guest OS, but that won’t connect you directly to the console (i.e. you won’t be able to watch the VM boot).

But there’s a better way. VMConnect allows you to specify the name of the Hyper-V server and the name of the VM you want to connect to on the command line.

So, let’s say that you have a Hyper-V Server called “MyHost” and a VM called “My Guest” that you want to connect to quickly. All you need to do is create a shortcut that points to VMConnect.exe with the following syntax:

Remember to use quotes around the VM name if it contains spaces! Also, if the VM exists on the same machine as the one you’re creating the shortcut on, you can use the name “localhost” for the server.

Click Next, name the shortcut whatever you want, and you’re good to go.

Problems with QueryPerformanceCounter on Windows Server 2003 Multi-Processor Hyper-V guests? Here’s why.

mikekol — Thu, 16 Oct 2008 02:03:00 GMT

A friend of mine from another group came to me with a problem he’s been having on some Windows Server 2003 guests.

They’re doing some nifty stuff with the .NET Stopwatch() class, and some WPF animations, which uses the QueryPerformanceCounter Win32 API to figure out the timing during the animations. Apparently, when they run their code in Hyper-V, the animations look sort of… not good.

They’re using Windows Server 2003 SP2 x86, which has been allocated two virtual processors.

It turns out that our performance guru, Tony Voellm, has already encountered something like this. From Tony’s blog post:

The root issue comes about from the Win32 QueryPerformanceCounter function. By default it uses a time source called the TSC. This is a CPU time source that essentially counts CPU cycles. The TSC for each (virtual) processor can be different so there is no guarantee that reading TSC on one processor has anything to do with reading TSC on another processor. This means back to back reads of TSC on different VP's can actually go backwards. Hyper-V guarantees that TSC will not go backwards on a single VP.

The fix for this is to modify the guest’s BOOT.INI file by adding the /USEPMTIMER switch to your operating system’s boot entry. This tells the system to use a different timer for QueryPerformanceCounter-related tasks, and should alleviate the problem.

Update: It looks like some people are seeing this as an error in their event logs. The event number is 1054, and the event source is UserEnv. This is the same problem with the same solution, it's just a different way of showing up.

-mk

KB950050 Isn't Installed After I Insert and Install the Integration Services Setup Disk. Here's Why.

mikekol — Thu, 26 Jun 2008 22:44:00 GMT

In the RC0 release of Hyper-V, you may recall, you had to use the same QFE to Windows Server 2008 host and guest machines to get the Integration Component versions matching.

In RTM, you simply need to choose the Insert Integration Services Setup Disk option from the Action menu in VMConnect, just like you do for Windows XP, Windows Server 2003, and Windows Vista.

However, after you get the ICs working and you connect up to Windows Update, the Hyper-V QFE for Windows Server 2008 (KB950050) is still listed. That little logical paradox causes you to check which QFEs are actually installed on your system, and you find that KB950050 isn't in that list.

What sort of crazy voodoo magic is this?

Well, according to Occam's Razor, the simplest answer is typically the correct one.

The simplest answer in this case is that Windows isn't lying - KB950050 isn't installed. For RTM (actually, this happened in RC1), we added another QFE to the mix so that the standard way of installing the ICs (the VMGuest.ISO, which is what gets inserted into the VM's DVD-ROM drive when you click Insert Integration Services Setup Disk) worked for Windows Server 2008.

Since the RTM update actually contains an updated VMGuest.ISO file, it would be impossible for us to put the RTM update in the ISO (it's a classic "chicken-and-egg" problem).

So, we added another QFE that just contains the Integration Components and nothing else to make life easier for all of you. You can still apply KB950050 if you want to. In fact, you can just apply KB950050 if that's your thing. Or, if you want to be totally up to date, you can apply both of them.

Ok, now I'm really going to the ship party. Honest.

I still get an error while installing the Integration Components on Win2k3 after I installed Win2k8 RC1 on the host! HC?

mikekol — Tue, 15 Jan 2008 03:53:09 GMT

In an earlier post, I said that you should install Windows Server 2008 RC1 with Hyper-V Beta if you're getting error 61658 while trying to install the Integration Components in Windows Server 2003.

And you should.

But some people are still seeing it. If you happen to be one of them, here's why:

You probably didn't really install Windows Server 2008 RC1 with Hyper-V Beta; you probably installed Windows Server 2008 RC1, which contained the Hyper-V CTP.

I won't go into the reason behind having two similarly named releases so close together because I wasn't involved in that discussion, so any attempt to explain it would be pure speculation on my part. Needless to say, the situation we find ourselves in is that there is a Windows Server 2008 that has our beta bits in it, and one that has our old CTP bits.

If you've yet to install any build of RC1, you can get a link to download the one that has Hyper-V Beta here.

If you've already installed it and you're curious as to whether or not you've got the CTP or the Beta bits of Hyper-V, you can easily tell. If you had to double-click on any MSU files to get the role to show up in Server Manager, you have the CTP release.

After Blogging Mint:

I don't know if anyone else out there ever saw these videos, but when I was in High School, my physics class had to watch some lectures given by a man named Paul G. Hewitt. While describing miscellaneous laws of physics, he would commonly prove the law via some demonstration, then ask his class "HC?" which stood for "How come?"

My "Here's why" series of posts wasn't exactly inspired by Professor Hewitt, but I've yet to write a post without thinking about those videos in some way, so I consider them to be a sort of tip of the hat.

Does your mouse stop working when you TS into a host machine and try to use a guest OS? Here's why.

mikekol — Wed, 09 Jan 2008 23:17:12 GMT

To continue my "here's why" series of posts, I figured I'd talk about something else that a lot of our users have run into - the infamous disappearing mouse when you try to use a Hyper-V guest while TS'd (that's Terminal Services - or Remote Desktop) into the host machine.

Here's the scenario: You've got a VM that you need to use, so you TS into your host machine, start up the Hyper-V Management Tool, connect to your VM and try to use it. Suddenly, your mouse doesn't work anymore, so you try to release it using the CTRL-ALT-Left Arrow hotkey. That doesn't work. Now you can't even use the mouse on your host operating system.

If you close your TS session and restart it, you get your mouse back, but this happens each time you try to control your guest.

Some of you are probably saying "Yes - that happens to me all the time, and it's annoying!" Others may think I'm making it up, since they've never had this problem.

So, here's what's going on. There are two modes of mouse operation when we're dealing with Virtual Machines: integrated and relative, as discussed by Ben Armstrong here.

When you TS into the host machine, your mouse is running in integrated mode. When you're using a VMConnect window to control a VM, the mouse runs in relative mode (with one important caveat, which I will come to later on). When you mix integrated and relative mode, you get badness.

So what is a humble system administrator or virtualization enthusiast to do?

There are a few work-arounds:

Run Windows Server 2008 as a guest. No, seriously. The Hyper-V Integration Components are built into Windows Server 2008, so it will simply work in this configuration out of the box.
Install the Integration Components for your guest operating system. This is the caveat I was talking about earlier, and is the primary reason why some of you have quite possibly never seen this. If you have the ICs installed and running, the mouse is running in integrated mode, and works flawlessly over TS.
TS directly into the guest operating system. If there are no ICs available for your chosen guest OS, you can use TS (or any other remote control application, really) to control the guest directly. This assumes, of course, that the VM is exposed to the same network as the machine you're controlling it from.
Use the actual, physical console of the host machine. If you take TS out of the picture, you won't have this problem.
Remote Administration tools for Hyper-V. These aren't available yet, but in our final release, we'll provide a way for you to install the Hyper-V Manager tools on Windows Vista, so you won't actually have to run them on a server.