Our upcoming ERP upgrade project
needed two new servers. We’d embarked on a virtualisation strategy and already had an IBM host machine, so the
clear choice was to build them as virtual machines (VMs). These would be
created from scratch rather than being physical-to-virtual (P2V) conversions.
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 pros endorsing 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.
During setup, I also managed to
forget the administrator password and had to repeat the OS installation.
Somebody please tell me I’m not the only one who should know better who’s
fallen into that trap.
