August 2005 - Posts
Microsoft renamed Virtual Server 2005 SP1 to R2 somewhere this week, which at first may sound like a technicality, but one that could end up costing you some money. According to the FAQ:
Customers with active Software Assurance (SA) when Virtual Server 2005 R2 becomes available will be eligible to upgrade to Virtual Server 2005 R2.
This appears to mean that if you apparantly were stupid enough to go out last week and buy a $999,- license of Virtual Server 2005 Enterprise Edition, that you'll have to shell out additional money near the end of the year just to keep it from slowing your Server 2003 SP1 VMs down to an unacceptable crawl. Sure, you knew SP1 wasn't supported on Virtual Server 2005, but before you decided to buy it, you did the responsible thing and tested the Virtual Server 2005 SP1 beta, which includes VM Additions for Server 2003 SP1. So after considerable testing, you decided to buy it because even though the current product was clearly not up to the task of virtualizing and consolidating a bunch of current Server 2003 machines, it would surely after SP1 is out. But apparantly, SP1 won't be out, but you can buy something better in a couple of months.
One of the main reasons to get Virtual Server 2005 is that it's quite a bit cheaper than VMWare's offerings. At least, it used to be. If we have to start paying for the support for every new Windows Server Service Pack (since apparantly, Virtual Server 2006, or should I say R3, is already in the works) then that advantage will diminish rapidly.
Until today I still wasn't able to install the July CTP of VS.NET 2005 on a VM hosted by Virtual Server 2005 until someone in microsoft.public.virtualserver found the following KB article: Slow performance when you try to access resources on your Virtual Server 2005 host computer from a guest virtual machine, which is exactly my (and many others') problem. This sure is a relief, as not being able to move large files to/from a VM would have made it completely useless for development/testing.
A quick summary of the article: the virtual NIC implemented in the VM doesn't support TCP segmentation offloading, so if the underlying physical NIC is configured to use it, a lot of translation is taking place. This slows things down immensely, up to the point where copying large files fails completely (my guess is timeouts). Fortunately, this can be fixed by simply disabling it in the Device Manager (Network adapters -> Your physical adapter -> Properties -> Advanced) on the host machine. I've done this today and it's working like it should, finally!
As I mentioned in my previous post on Virtual Server 2005, it's very easy to create a base virtual machine that contains (for instance) a fully patched version of Windows XP Pro and copy it around to work with multiple instances since all a VM really is is just a .vmc (Virtual Machine Configuration) and .vhd (Virtual Hard Drive) file. Making a copy of a VM is just a matter of creating a new machine in the Virtual Server web interface and copying the .vmc and .vhd files over the ones created. The only changes required are two values in the .vmc xml file: one pointing to the absolute path of the .vhd file to use and another that points to the relative path of the same file (in my experience if you change only one of these it will use the absolute path, don't ask how I discovered that, it wasn't very funny, especially the part where throwaway.vmc's VM wrote to donttouchthisbaseimage.vhd). After that you can start up the just created VM and it'll be a copy of the base image.
One problem remains however: machine name. This didn't seem like much of an issue, but having multiple instances running will mess with file sharing, besides producing annoying error messages. Fortunately, there's a solution to this, one that's probably known to system administrators but not to a developer like me. What you need is deploy.cab in /support/tools on the Windows XP or Windows 2003 installation disk. Install the files from this archive on the base image and first run setupmgr.exe. This tool will help you create a sysprep.inf file. First you choose to do a fully automated install, next select the options you want to automatically configure on a copied image, like generating a machine name. When you're done the tool will have automatically created a sysprep-directory with the sysprep.inf file in it (it will ask you to save the sysprep.inf file but regardless of where you save it, it will also place it in the correct directory).
Next you can run the sysprep.exe tool. Here you choose to do a mini-setup and click "Reseal". This will freeze the VM shortly and then shut down. Now you can create a copy of the virtual machine. When you boot into that copy for the first time, you'll see an automated configuration taking place and a reboot, after which the virtual machine is done: fully customized with a unique machine name! This is especially useful if you plan to do automated resets of a virtual machine using a script or a custom application: just copy the .vmc/.vhd files and change the path in the .vmc file. After that you're set to start over again from scratch. This might seem like a far-fetched solution, but being able to select what to automatically set during configuration and what to ask the user is very useful: for instance setting the localization during setup can be used to test localized versions of your application without having to maintain a bunch of localized base images.
A note on licensing though: I've called Microsoft to ask about licensing in such a scenario and they've told me that my MSDN Universal subscription is enough for doing it like this when I'm the only user of the virtual machines. I'm not a lawyer so I can't say anything about what you're allowed to do in other situations/with other licensing schemes.
More Posts