When creating a Hyper-V virtual machine from scratch, beware of issues with Windows licenses and disk creation. Oh, and don't forget the administrator password!
I hit two pitfalls I wasn't previously aware of and made a mistake any self-respecting IT pro would be ashamed of. This article isn't so much a step-by-step how-to as a cautionary tale.
Activation failure
One of the VMs would be a database server, so I was reassured to read of other IT prosendorsing the use of SQL Server in a virtualised environment. What's more, my IBM host server runs Windows Server 2008 R2 Enterprise, which includes Windows licenses for up to four guest VMs, so I knew I wouldn't have to buy any operating system (OS) licenses. With the IBM server, we were given two Windows license keys: one for the host server and a "virtual key" for use with VMs.
In Hyper-V Manager, creating a VM from scratch is as simple as running the New Virtual Machine Wizard. After allocating the required memory, choosing to create the VM not connected to the network, and specifying a location for the virtual hard disk (.VHD) file, I chose to install an OS from a DVD (Figure A).
Figure A
OS installation options
Since my database application needed Windows Server 2008 R2, I retrieved the OS DVD for another server running that OS and installed from that. When it came to the request to Activate Windows, I entered the virtual license key, which was rejected. Research indicated this was because the virtual key only works if the guest VM runs Windows Server 2008 R2 Enterprise. Now that wasn't obvious.
With a sigh I swapped to the IBM Windows DVD and restarted the setup process, this time choosing the Enterprise option. Since there was already a copy of Windows installed (the one that wouldn't accept my license key), I accepted the option of moving the existing files to a folder called Windows.Old, planning to delete them later. Unfortunately, this "in-place" install failed with an error, and I had to start from scratch, choosing to format the disk partition. Finally, the install completed, and the virtual key was accepted by the activation process.
Password failure
Continuing the setup process, I logged in with my chosen administrator password and followed the steps to upgrade the Hyper-V Integration Services. This required a reboot, after which I attempted to log in as administrator again -- and couldn't get the password right. I looked in disbelief at the password I'd written down, tried it several more times, and then tried a few variations. I couldn't believe I'd made a mistake like this. I'd managed to get the password right a couple of times up to now, but clearly that wasn't the password I'd written down.
There is a non-drastic way out of this embarrassing hole -- a password reset disk. However, I hadn't created one. I never do. I'll never need one of those, or so I thought. That only left me with the drastic solution -- reinstall the OS again. When I did, I chose an admin password no less secure but far less prone to mis-typing.
I've still not created a password reset disk, because, of course, I'll never need one.
Another disk, please
My new VMs were created with a single .VHD acting as the C: drive. I needed extra drives on both of them. To do this, the VM must first be shut down. In the Settings dialog for the VM, selecting an IDE Controller provides the option of adding a new Hard Drive. Creating the drive is wizard-driven, including the choice of disk type, size, and location. I specifically wanted a fixed size disk, rather than dynamically expanding, to guarantee the best performance for SQL Server. On clicking Finish, the wizard creates the new .VHD file.
And then you wait a long time -- at least 20 minutes for a 250Gb drive. Not only that, I started receiving complaints that applications on a different virtual server weren't responding. The explanation, it seems, is that when creating a fixed size .VHD, Hyper-V explicitly zeroes out every part of the disk to be used by the new .VHD. This is done for security purposes. (Note:Today when trying this link to an MSDN blog I was presented with a signup/login page I hadn't seen before. To get to the link I first had to cancel that dialog and then try again.)
My guess was that this zeroing process required so much disk I/O that it was affecting the other VM (which was on the same host). Sure enough, when the disk creation finished, the applications sprang back into life.
I apologised to my users and wondered if I could avoid this slow, resource-hungry process for the other disks I wanted to add. The MSDN article linked to a follow-up post describing a Microsoft tool designed to circumvent the slow creation by overwriting the relevant area of the disk without wiping it first. Since my host machine's disk had very little data on, it would have been safe for me to use that tool. In the end, though, I decided to stick to the normal way, but this time give my colleagues some pre-warning of the knock-on effects.
I (and they) waited patiently while the disks were created, and finally my new VMs were ready.
Summary
In creating two new Hyper-V VMs I discovered that the "virtual license key" supplied with Windows Server 2008 R2 Enterprise only works if the guest VMs also run Windows Server 2008 R2 Enterprise. I also found that adding a fixed size hard disk to a VM can be a slow, resource-intensive process that potentially affects other VMs on the same host.
