As I’ve written in the past, I’ve been using VMware (both Workstation 6.5 and Server 1.04) for what seems like ages. They’ve served me well but I wanted to be prepared for two changes coming up this year. The first is Server 2008 R2, which is 64-bit only and secondly Visual Studio Team Foundation System 2010, which I’m guessing will be distributed in a Hyper-V ready image. While I was perfectly happy with VMware Server, my old partner in crime from my NuMega days, Matt Pietrek, is on the Hyper-V team so was giving me heck for not supporting him. How could I resist that pressure?
The transition was generally painless but I thought I’d share a few of the notes I took as I got everything working in the hopes that someone will find them useful. My domain is nothing too fancy just four virtual machines: a domain controller, a TFS 2008 server, a file server, and a build machine. On the user side there’s me and “She who must be obeyed” (AKA my wife). My server is a wonderful Mac Pro with 9GB RAM with 1.6 TB of drives. When running VMware Server, the host machine was running Server 2003 R2 x64 and all the virtual machines were 32-bit Server 2003 instances. My plan was to move the 32-bit TFS server over from VMware directly and replace all the other servers with the x64 versions of Server 2008 so when Server 2008 R2 ships later this year, I’m all ready for it.
As I have VMware Workstation on my main development machine (another Mac Pro), I moved the .VMDK and .VMX files for both my domain controller and file server to run them on my desktop while working on this transition. One key point if you do the same: remember to set your power plan on the desktop to keep the machine awake and not go to sleep. Having your most important client yelling at you because the mail and web are down is quite confusing when you’re in the middle of watching the Server 2008 installation copy files and you know you haven’t touched anything yet.
Right at the beginning, I ran into a Mac Pro specific obstacle, as I couldn’t boot in the Windows 2008 install. The boot would initiate on the CD and the following came up on the monitor:
| 1. 2. Select CD-ROM Boot Type: |
No amount of pressing 1 or 2 on the keyboard would work. Fortunately, others had already blazed this trail and following Jowie’s steps got the installation working for me.
Once I got Hyper-V installed, I did some experiments with dynamic and fixed .VHD disks. As I had done with VMware, I wanted to have an emergency XCOPY backup of the files for the data files. While not officially supported by Microsoft, being able to restore a machine with a copy command can be a lifesaver. I did both a dynamic and fixed disk test with the excellent DISKSHADOW program from Server 2008 to invoke the Hyper-V VSS writer without shutting down the running VM. As I suspected restoring the dynamic disk copy caused the incomplete shutdown text screen to show up when restarted. The fixed disk restore worked cleanly so that made up my mind that I was going with fixed disks for everything. The trade off is that a fixed disk of 40GB means you get a file of 40GB, but disk space is nearly free these days.
In reading about the supported backup methods for Hyper-V servers, I was disappointed that it’s all or nothing. That’s primarily because the backup program in Server 2008 takes a snapshot of the whole volume so if you want to restore a single VM on that disk volume you can’t because it’s an all or nothing affair. What I decided to do was partition up my disks and only run one VM on each partition so I could get the supported backup scenario and only have to restore the one VM that needs restoring.
I have an excellent HP Home Server doing my client backups and it’s truly a “set and forget” backup system. While some have reported that WHS can backup Server 2008, I haven’t seen where anyone explains the exact step for a valid restore. Maybe I can become an internet hero if I take the plunge and figure out all the steps. I’ll put it on my “to-do” list.
Implementing the new domain controller was a piece of cake with Server 2008. I’m glad I did it now, as there is still a 32-bit version of Server 2008 because running ADPREP before introducing the new domain controller makes life much easier. Not being much of an Active Directory person I’m always terrified when messing around with domain controllers because reading TechNet makes it sound like AD is the most fragile thing in the world. I guess that’s my inexperience talking but I don’t think I’m alone. One major trick I do know is that before you demote a domain controller, always run the following command:
netdom query fsmo
That way you make sure you don’t accidentally leave those all-important FSMO roles floating out there. I don’t know if DCPROMO will catch that error, but I wouldn’t want to find out because then you’ll have to seize them, which sound quite unpleasant. For you AD novices like me that are looking for AD resources for normal people Sander Berkouwer’s excellent blog is a treasure.
Installing MS-DOS 2008, oh, I mean Server Core 2008, for my file server was easy. The problem started when I couldn’t log in the first time. Who knew a blank password for Administrator was the way to log on? Another bit of feedback I have for the team is it would be a great idea to have a text file with all the configuration commands in it, like Greg Shield’s article, as part of the install so you could open it in NOTEPAD for easy cut and paste to the command window
With the three x64 servers running great I turned to converting my 32-bit Team System .VMDK, which is easy with the free VMDK to VHD Converter from the fine folks at vmToolkit. A little poking around the web got me to a blog entry from Ken Schaefer where he discussed his experiences moving from VMware to Hyper-V. He reported there were troubles starting a converted VMware system on Hyper-V RC0 because VMware is using SCSI disks and Hyper-V needs an IDE disk in order to boot. The work around was simply adding an uninitialized IDE disk to the VMware instance before shutting it down. Not finding any other information anywhere, I figured it couldn’t hurt to add the IDE drive because I didn’t want to go through a repair installation to get things working again. Before I did the conversion, I also removed the VMware tools from my TFS machine. After I did the conversion from VMware to Hyper-V, which was to a dynamic disk, I made the new .VHD a fixed disk with Hyper-V.
The first boot of the converted .VHD went well but had a message box that a service had failed to start. The Event Viewer showed it to be VMMEMCTL. As that’s a VMware service that looks like it didn’t properly uninstall I manually deleted all the references with REGEDIT, and the machine was fine. After installing the Hyper-V VM Guest services, which gave me the network connection, I had to authenticate the computer, which I expected since all the hardware changed on the machine.
After the TFS server was up and running, I noticed it was running very slowly. In VMware, I had only allocated 1 GB RAM to the machine, which was sufficient. Logging into the machine showed the memory usage was nearly maxed out and it was swapping like crazy. I shut it down and reconfigured Hyper-V to give it 2 GB RAM to see if that would help out, which it did. What’s different is that SQL Server 2005 is now using 700MB of memory for its working set. I’m not sure what’s causing the difference as everything’s running great and there’s no SQL messages in the event log. In all, it was cool that the conversion was that easy.
With everything running great on Hyper-V, it was time to tackle my XCOPY backups and that’s where I ran into a big problem. I created a DISKSHADOW script for one of my VMs and ran it. Here’s the output I got:
DISKSHADOW> delete shadows all
No shadow copies found in system.
DISKSHADOW> set context persistent
DISKSHADOW> Writer Verify {66841cd4-6ded-4f4b-8f17-fd23f8ddc3de}
DISKSHADOW> add volume c: alias myshadow create
The component “Microsoft Hyper-V VSS Writer” was not found in the writer components list. Aborting backup …
Check the syntax of the component name.
That was odd that the Hyper-V VSS writer was no longer there. Running the DISKSHADOW list writers command showed the Hyper-V VSS writer active. Running VSSADMIN with the list writers command, which shows you the state of the VSS writers showed life was peachy:
vssadmin 1.1 – Volume Shadow Copy Service administrative command-line tool
(C) Copyright 2001-2005 Microsoft Corp.
Writer name: ‘Microsoft Hyper-V VSS Writer’
Writer Id: {66841cd4-6ded-4f4b-8f17-fd23f8ddc3de}
Writer Instance Id: {a61296b9-d85f-4400-9bfb-ea58b2b78294}
State: [1] Stable
Last error: No error
The event log showed an odd VSS error 1009 with no information:
The description for Event ID 10009 from source VSS cannot be found. Either the component that raises this event is not installed on your local computer or the installation is corrupted. You can install or repair the component on the local computer.
If the event originated on another computer, the display information had to be saved with the event.
The following information was included with the event:
the message resource is present but the message is not found in the string/message table
Using the Server 2008 backup system from the command line, I was able to back up the entire machine with no problems. Here’s where I was perplexed because it sure looked like no matter what I tried, DISKSHADOW would not back up my VMs! I really want that XCOPY save your butt backup!
In panic, I wrote a friend at Microsoft and after a little back and forth, we figured out the problem. Part of it was between the keyboard and chair in my office and part of it was a completely bogus error message. Where I was thinking DISKSHADOW worked on an individual disk, it really needs to be named MACHINESHADOW. It will only work if you include all the component volumes listed under the Hyper-V VSS Writer when you do the list writers command. As I have four drives with running VHDs on them, I need to ensure the following as in the DISKSHADOW script I use:
Add Volume E: Alias DomainControllerShadow
Add Volume D: Alias FileServerShadow
Add Volume I: Alias TeamSystemShadow
Add Volume J: Alias BuildMachine
Add Volume C: Alias Ignored
Even though I don’t have any VMs running on my C: drive if it’s in the component list, it has to be included. Given the bizarre error messages in the output and the event log, I hope this helps someone else if they run into the same problem.
After hurtling my small bump with DISKSHADOW, it was neat to see VMs backed up without shutting them down. I’m including my domain controller as part of that backup. The whole snapshot and ROBOCOPY process for all four VMs takes about 40-45 minutes total as I first save everything on the HYPER-V machine. The ROBOCOPY of those saved images to my WHS machine is about 30 minutes.
My small environment doesn’t have any replication nor am I replying on snapshots so it works for me (YMMV). Of course, I’m still doing normal backups in addition. If your network is more complicated than mine is you must read the great whitepaper Running Domain Controllers in Hyper-V so you don’t cause yourself any problems.
If anyone has any questions about what I’ve done please ask away.