Virtualization

The three mistakes I made creating a Hyper-V virtual machine

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!

caution_thumb_092013.jpg
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

hyperv_vm_FigA_091813.png

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.

About

Mark Pimperton BSc PhD has worked for a small UK electronics manufacturer for over 20 years in areas as diverse as engineering, technical sales, publications, and marketing. He's been involved in IT since 1999, when he project-managed implementation ...

13 comments
robertpotter30
robertpotter30

Hi Mark! There is no need to reinstall your virtual machine when you forgot the password. Just mount the ISO image of PCUnlocker to the virtual DVD drive, boot from it and it allows you to remove the existing password immediately.

senerakyol
senerakyol

these are really windows server + microsoft licensing issues mostly in my opinion other than being hyper-v specific. licensing issues you had are somewhat OEM related as microsoft's product use rights document clearly states you do have the right to run 4 Windows Server 2008 R2 (Standard and/or Enterprise). When the licenses are tied to hardware (OEM) you really are in the mercy of OEM providing you with the proper installation media + keys and they are not always the best help.

Also, other than the C drive you don't have to use the virtual IDE controllers. For data drives you want to attach to your virtual machine you can use  virtual SCSI controllers. As long as the virtual SCSI Controller is attached to the VM, VHDs can be added to the while the VM is running. Lately with Windows Server 2012 R2 now you don't even have to have IDE controller for the boot drive anymore.

Password issues are very annoying I admit. Many of my installations went wrong for me as well- both virtual and physical. For the VMs though sometimes the numlock status of the vm don't match the host and things end up getting inverted. Virtual Desktop connection is not exactly RDP and time to time it throws issues with keystrokes. I find these issues are a lot less with the Server 2012 though and if I'm not mistaken Server 2012 R2 they have a complete new approach to virtual desktop connection.

Afsaneh Ferdowsi
Afsaneh Ferdowsi

in my opinion hyperv its better than any software virtualization

bthorpcurtmfg
bthorpcurtmfg

 As mentioned by others, there are various ways to bypass local user passwords including the admin account.

Also, Windows server keys are very specific to the version you have - a Standard key only allows standard, enterprise - enterprise installation, etc.

Very rarely you'll get a universal key, if they even still exist anymore.

Also, if you setup your VM ahead of time with a SCSI controller, you can then use that for adding additional disks hot.

Kit Hollywood
Kit Hollywood

My only mistake was i did not make any documentation during the setup process. Had a good time trying to guess the passwords for the Vm and os, plus forgot to note down the IPs so remoting in was somewhst hard.

Atul Deshmukh
Atul Deshmukh

may not be in terms of features but works great

BTRDAYZ
BTRDAYZ

Thanks for sharing this information. There are plenty of admins of varying skill level and experience. Techs that work for VARS, consulting/outsource firms may build many servers frequently each week. Admins like myself with a history of long term employment at a single employer, may build servers every 5 years, and refreshers are needed. I tend not to screw with servers until after hours anyway, so while I might have experienced the performance reduction of the SQL server zeroing out the HD, hopefully, it would have been during a time period where users didn't notice the hit.

mark1408
mark1408

@senerakyol You're absolutely right about the licensing. I do have another VM on there that doesn't use the "Virtual key" but for these two that's I wanted to achieve.

Interested in your comment re SCSI controllers. I had read that there was no advantage to them but being able to add disks while the VM is running sounds like one to me.

mark1408
mark1408

@jred Maybe, although there seem to be a lot of caveats on the site about what will and won't work. I'm actually slightly alarmed that there's a way to bypass a local admin password without knowing the original. Sounds like a backdoor for unauthorised people to gain access to files on the machine :-(

gechurch
gechurch

@mark1408 @jred It certainly is a back-door, but not for unauthorised people. In order to run password reset tools like ntpasswd you need access to it to ne able to put in the CD (or USB stick) and you need to be able to boot from that media. If someone has physical access to your machine you've already lost all security.

Editor's Picks