Wednesday, February 18, 2009

Do you know where your VM has been?

For a tester, creating a situation that causes a piece of software to fail gives you a warm fuzzy feeling inside. Some situations are easy. Some are difficult. Others are accidental, but totally realistic as to how they happened.

I have recently been busy testing virtual disk conversion tools. You might say: "how relatively boring is that.." And I will admit that it isn't the most glamorous thing to test. However, it has lead me to the reality that virtualization of a machine workload is NOT new.

Almost 6 years ago I first began working seriously with virtualization, moving a number of physical machines and their applications into virtual machines on ESX server. Back then, this was really cool stuff. Very few companies were doing it. Microsoft did not officially support running their operating systems within virtual machines, and you could never tell an application support person that you had virtualized the server their application was running on as they would immediately declare "there is your problem."

Well, we have grown and MSFT has gotten into the hypervisor market and all of a sudden this stuff is becoming main stream.

The most important part that I want to bring up is: People are migrating between hypervisor platforms, virtual disk formats, throwing away an old platform for a different one. Why? Because they can.

This is totally relevant to testing, evaluating, understanding performance, and a number of other things with your VMs. What was the life of that virtual machine? How did it get to where it is today? Does anyone in the enterprise even know?

I recently had the pleasure of breaking a piece of software and was told by a developer that "that was a really good bug, you found a great case." Now, as a tester, there is nothing better than a developer giving you a compliment because you found a good bug.

Now, I need to get back to my point.

I had access to a VM that was built on VMware workstation, moved to ESX server, to Virtual Server, to Hyper-V, and then I converted it back to a VMDK from VHD using WinImage.
This is at least five disk format modifications, three tools modifications, and this VM was running an application.

And, during most of those conversions a 3rd party, offline, conversion tool was probably involved. Some examples you may be familiar with: WinImage, Acronis, VMDK2VHD, PlateSpin, etc.

Needless to say there was a problem introduced to the virtual disk at some point in its life. Did any of the tools report this? No. Did the VM boot and run? Most definitely. Did we have any idea that there might be a problem? Definitely not.

It just goes to show you that in this day and age we need to keep track of these things. As who knows where an error can be introduced into an environment.

It is no different than the case of converting that old NT domain controller in the back corner into a VM because there is one legacy application that runs on it that is critical and the application has never been updated... And then you realize that you have migrated between platforms, formats, and who knows what tools.

So, always be mindful of your virtual machines. Their life and lifetime. Not just from a security standpoint, but from a stability standpoint.

Friday, February 6, 2009

Configuring Hyper-V remote management

Configuring remote management and delegating permissions to non-administrators has been one of the biggest stumbling items for many.

John Howard from Microsoft has been blogging about this extensively and until a short while back it was complex and complicated.

Kerberos tickets, domains, Authorization Manager, SP1 for Vista, etc.

To make it all easier - There is the Hyper-V Remote Management Configuration Utility.

John Howard talks about it here: