Prior to using Hyper-V as part of my daily development and test efforts I wasted man weeks every year.  I lost days at a time configuring machines and recovering from updated NDP builds.  I wasted hours every week repeating the same steps over and over.

I will be bold enough to say that Hyper-V allows me to get at least 15% more work done each week on less than a third of the hardware I had before and I never have long downtimes due to my machine being down.  Even a total machine failure is not going to put me offline for longer than it takes to reinstall Windows and Office.

So how did I setup my environment?

Hardware

  • Dell OptiPlex 755
    • Intel Core 2 Quad (Q6600) @ 2.4 Ghz
    • 8 GB RAM
    • 250 GB HD (Primary)
      • C: – 25GB (boot drive)
      • F: – 225GB (data drive)
    • 500 GB HD (Secondary)
      • E: (data drive)
    • 150 GB HD
      • Marked Offline in Windows (you can do this through disk management – it must be a real drive, not just a logical partition)
  • 500 GB Western Digital MyBook HD (external USB drive)
  • Monitors
    • Samsung SyncMaster 206BW (20” LCD)
    • Philips 170B (17” LCD)
  • MidiLand Speakers (el-cheapo junk speakers I found in a box somewhere)

The overall hardware investment is about $1300 (and that’s retail pricing that anyone can get).

To create my development environment I do the following (applying the latest patches at every step and CA eTrust is installed on every machine [physical and virtual])

Configure Primary Box

  1. Install Windows 2008 (64bit) on the C: drive
  2. Install Office 2007 on the C: drive
  3. Install the Hyper-V services (RTM)
  4. Create the folder F:\VM
  5. Plug my Zune directly into the speakers – I don’t want to give up CPU/RAM for music to play.
  6. Configure Windows Backup to backup my C: and F: drive to the external hard-drive (that’s why it does not have a drive letter – Windows takes over the drive).  I do nightly backups of my VMs.

Configure Development Box

My goal with the dev box is to optimize for quick resets when we take new builds of Visual Studio or the CLR.  Since I work on the VS team I take new builds every few weeks.  To do this I pre-install a lot of stuff, create some baseline snapshots and then mount the physical disk for my source enlistment.  Mounting physical disk is REALLY IMPORTANT.  You do NOT want your source code on a virtual drive because when you revert to an older snapshot you will lose it’s contents and that will both screw up your workspace contents (requiring a force sync) and may result in losing data (files that were added/edited but not checked in).  Also the physical drive means build performance is not impacted by a virtualized drive.  The virtual drives in Hyper-V (even the expandable ones) have great performance – but moving the build to a physical drive really helps keep things rolling.

One caveat – you cannot take snapshots with a physical drive mounted so you do not get live snapshots and you must unmount whenever you apply a previous snapshot (this is trivial, but for some reason the Apply operation won’t do it for you behind the scenes).

I can recover from an VS/NDP update in about 2 hours with this model.  On physical hardware it would mean formatting and starting over – costing about a day.

  1. Create a new (127GB - Expandable) virtual disk at F:\VM\Disks
  2. Create a new virtual machine (at F:\VM\Machines) called “HORVICKVM-DEV” with
    1. Four Virtual Processors
    2. 2 GB of RAM
    3. Legacy Network Adaptor (So I can use RIS for network installs)Boot to RIS network boot
    4. The drive you created in step #1
  3. Install Windows 2003 (32 bit) [Choose whatever OS you want]
  4. When it is finished installing shut the machine down and take a snapshot called “OS Installation Complete (OFF)”
    1. I always put “OFF” or “LIVE” in my snapshot names so it’s clear to me what the running state of the snapshot is without having to look at the details or preview window.
  5. In the VM configuration settings for the dev box
    1. Change the network adaptor from Legacy Network Adaptor to “Network Adaptor”
  6. Boot the Development VM
  7. Install NDP 2.0, and 3.5 + SP1
  8. Install Source Insight
    1. I always want to have an editor on the box in the event I run into a VS bug I can’t work around.
  9. Install WinDbg and configure it for use with our symbol and source server plus my favorite configuration tweaks.
    1. I always want to have a debugger installed in case I need to debug the VS install (and frankly WinDbg + SoS is pretty damn powerful).
  10. Shut Down the VM
  11. Snapshot named “Editor and NDP 3.5+ Patched (OFF)”
    1. Now – Once I’m here I never need to do any of the above steps again.  Ever.  This is my persistent baseline snapshot that I will love forever.  In the future I will come back to this snapshot, apply patches and make a new baseline (deleting this snapshot and renaming the new one to this name)
  12. Boot the VM
  13. Install the build of Visual Studio we are using at the moment (this includes NDP4, etc)
  14. Start VS and setup my configuration settings (C# environment, debugger and symbol options, editor options, etc)
  15. Shut down the VM
  16. Snapshot the VM as “Installed VSTS and NDP4 build XXXXX (OFF)”
    1. When we take a new version of VS I will need to abandon this snapshot tree so it was important that I did all the OS and non-CLR/VS related changes prior to this snapshot.
  17. In the Hyper-V MMC bring up the settings window for this VM
    1. Select “IDE Controller 1”
    2. Select “Hard Drive” and click the Add button
    3. Choose the “Physical hard disk” radio button and select the drive marked offline in the drop down list (it should be your only option since only offline drives will show up here).
    4. Click OK to save the drive in the settings.
  18. Boot the VM
  19. On the new drive I create a folder named “HORVICKVM-DEV” (the machine name) and under it enlist in the source code for my branch.
    1. I create the folder with the machine name because I sometimes mount the same drive under multiple VMs (not at the same time) and this helps me isolate changes.
  20. Build, Test – Ready!

When I take a new VS I will revert to step 12 and start over (I do export my configuration settings to make configuring VS easier).

Configure Test Box 1 (2 and 3)

My goal with the test boxes is, like the dev box, to be able to quickly recover from NDP updates but also to have a stable SQL and IIS environment to start from.  I will create multiple identical test boxes that differ only in OS (2003 or 2008) and data width (32 or 64).

I can recover from an NDP update in about 30 minutes with this model.  On physical hardware this would also be about a day.

  1. Create a new (127GB - Expandable) virtual disk at F:\VM\Disks
  2. Create a new virtual machine (at F:\VM\Machines) called “HORVICKVM-TEST1” with
    1. Two Virtual Processors
    2. 1 GB of RAM
    3. Legacy Network Adaptor (So I can use RIS for network installs)Boot to RIS network boot
    4. The drive you created in step #1
  3. Install Windows 2003 (32 bit), Windows 2008 (32bit) or Windows 2008 (64 bit)
    1. Since I work on the server component I don’t install a client OS on my test boxes
    2. When it is finished installing shut the machine down and take a snapshot called “OS Installation Complete (OFF)”
  4. In the VM configuration settings for test box 1
    1. Change the network adaptor from Legacy Network Adaptor to “Network Adaptor”
  5. Boot the Test VM
    1. Install NDP 2.0, and 3.5 + SP1
    2. Install WinDbg and configure it for use with our symbol and source server plus my favorite configuration tweaks.
  6. Shut Down the VM
  7. Snapshot named “NDP 3.5+ Patched (OFF)”
  8. Boot the VM
  9. Install SQL server 2008
  10. Install IIS 6 or 7 (depending on OS)
  11. Copy my test scripts from my persistent network share to a well known location on the virtual drive (I always want these in the baseline – they will update themselves if newer versions exist after a snapshot revert)
  12. Shut down the VM
  13. Snapshot named “SQL 2008 + IIS (OFF)”
    1. Now – Once I’m here I never need to do any of the above steps again.  Ever.  This is my persistent baseline snapshot that I will love forever.  In the future I will come back to this snapshot, apply patches and make a new baseline (deleting this snapshot and renaming the new one to this name)
  14. Boot the VM
  15. Snapshot the VM as “Before NDP4 (LIVE)”
    1. In case the NDP4 install has problems I want a live clean snapshot I can quickly get back to
  16. Install the version of the NDP4 that matches the version installed on my dev box
  17. Snapshot the VM as “NDP4 XXXXX installed (LIVE)”
  18. Done!

The machine is now ready for testing.  Did you notice that WSS was not installed?  If I ever want it to be persistently installed I will create a new branch off the snapshot “NDP4 XXXXX installed (LIVE)” with WSS installed.  Typically I will either install TFS choosing to let it install WSS or I will have it not configure WSS.

Fun Things I Can Do Now …

  • After test runs complete I can revert back to the snapshot “NDP4 XXXXX installed (LIVE)” and start over (or just re-run them if they are non-destructive).  When I take patches I start with the “NDP4 XXXXX installed (LIVE)” snapshot, apply them there and then make that the new baseline.
  • Say I want to test the MSI out with four or five different configurations.  Say it takes 8 minutes to get the MSI to the point where I want to test.  I can save over 30 minutes by doing a live snapshot of the test machine at the point where I want to branch the testing and then after each attempt re-apply that live snapshot.  As long as I don’t muck with network resources (e.g. external SQL or WSS servers) this works great.
  • Hardware/OS configurations.  On a single box I can test several OS and data width options.  This saves the company thousands of dollars and me hours of time.  Better still my code is better tested and that saves our customers countless hours of frustration and pain.
  • Limited memory testing.  I can test deploying TFS on a single tier (SQL + WSS + RS + TFS) with, say, 512 MB of RAM (or less).  I don’t need to pull sticks or disable things in the BIOS.  This saves me hours and lets me cover scenarios I wouldn’t otherwise.
  • Single/Multi-Proc configurations.  I have a quad core machine but say I want to test a bug that only repros on single core machines – well – I can!  Or 2.  Or 4.  It’s a nice balance.
  • Using 1GB footprints I can run several test VMs at once to test multi-tier configurations (SQL on one box, RS on another, WSS on another, TFS on another) that before would have been too difficult to coordinate easily and nearly impossible to repeat numerous times per hour (at my desk – our test team has tools that can help them do this in a lab environment).

Yeah – I know a lot of you are reading this going “Well … DUH!  I’ve been using VMWare/Xen/Whatever to do that for years …”  I’m not saying this is new.  What I’m saying is that for me, as someone who didn’t have the option to use those before, this is a game-changing way of development.

I will never go back to piles of boxes under my desk.

Credit is due to James Manning for pointing out several of the configuration choices I’ve described above.