Tuesday, August 31, 2010

Waking up to a New Virtual Reality

My first experience with a virtualized developer environment was back in 2007. I was taking over a project that had been in prod for a a year or so. It wasn’t a very large project and I was just in to fix some bugs and add some features.

But anyone who has been added to a project ‘just’ to add some value knows it can be a tedious affair just to get the development environment up and running. This was a project based on EpiServer (a SharePoint’ish Content Management System) running on ASP.NET 2.0 on the frontend and Sql Server 2005 in the backend.

New VRI would probably have had to spend at least 2 or 3 days just to get my dev machine setup for this project. That would be; if I could get my dev environment set up.

I had never worked on EpiServer before and so just set this up would have been a long and windy road. The version we were running was a couple of versions old and the web contained little to none information on the version we were running. Even getting the correct installer would probably take a couple of days…

Lucky for me this project had been using VMware to virtualize both the developer, test and staging environments, and so getting my first dev build up was merely a matter of installing the VMware client, copy over the virtual image and start it up. Almost too easy!

The dev machine in this case was a Windows XP image with Visual Studio 2008 and Sql Server 2005. An environment quit fit for virtualization. My next project was onsite at a customer with an already setup up machine, and so I didn’t have the chance to virtualize anything there. But starting on a new project again in late 2008, a decided to give VMware a try again.

This time it was on a Vista box (with bitlocker) and a dev environment that also required Vista. Needless to say; Vista rendered, to my big disappointment, useless to both be virtualized and to be the virtualization host. At least for a developer environment.

Then came Windows 7 around and I saw some blog posts on how you could boot directly off a Virtualized Hard Drive (VHD). Meaning you would only suffer about 3-5% performance loss due to virtualization. The only hardware that is actually virtual is the hard drive. Everything else, CPU, memory, graphic card, network, usb, are all non-virtualized. You’re running directly off the hardware.

I didn’t take the time to test out VHD boot as long as I had my dev environment already set up and everything was running fine. But about a month ago I got a brand new Lenovo W510, and so I finally got the ‘excuse’ I needed to give virtualization a new chance. Gold

And I can tell you; so far it’s been pure gold!

From what I’ve experienced so far, here are the pros and cons of VHD native boot on Windows 7:


- Easy to set up new dev environment for testing out new tools, framework, languages or what-have-you. You just need to keep a copy of your ‘base images’ so that you can start fresh from there.

- Easy to get new members of a team up and running. A little disclaimer here as I haven’t actually tried this, but it should only be a matter of running sysprep with the ‘generalize’ option on the virtual machine.

- Backup is just a file copy operation

- Getting up and running on a new physical machine is just a matter of installing Windows 7, edit the boot manager (bcdedit) and copy the VHD-file over to your new machine

- “Avoid” BitLocker; Now this might seem like a strange thing to do, but as a consultant I have two sets of security manuals to confirm to. One for my employer and one for the customer that hires me. Now the security regulation is seldom at level between these, and so I always have to be set up to meet whoever has the highest security bar. Most often that would be my employer.

And as every dev knows; the more layers of security you add to your machine, the longer does your compile take. For some reason I was not equipped with a lot of patience at birth – and I haven’t gotten any since – and so sluggish machines does not suit me well. BitLocker, enterprise anti-virus clients, and other well-intended enterprise security apps, can really suck the life out of any machine. If all you need to do your job is Outlook, Word, Excel and a browser, that would be fine. When you need to compile a 65-project-large solution 400 times a day, it isn’t. And so if I’m working for a client who doesn’t require disk encryption and sluggish anti-virus software, then I’m perfectly fine with that.


Source of performance numbers- A performance hit; I’ve seen 3-5%, but those numbers apparently came out of Scott Hanselman’s butt (his words, not mine) so take that for what it’s worth (I could make a pun and say that ain’t worth sh**, but I’ll refrain myself from adding that kind of toilet humor to this blog). What I can say, though, is that I can’t tell the difference between running on my virtual and my ‘real’ Windows 7 installation. In a blind-test I don’t think I’d be able to tell them apart.

- Hibernation is not supported on the virtualized machine

- Calculation of the Windows Experience Index (WEI) not supported

For me the pros outweigh the cons. The loss in performance is leveled out by not running BitLocker (which also gives you a 3-5% perf hit). Hibernation is nice, but I can live without it and I still have WEI on the host.


My next blog posts will cover how I created my VHDs and got my multi-boot set up.

No comments: