Dan Griffin's Blog

I think disaster recovery preparation will prove to be the first killer app for both virtualization and cloud computing for certain types of customer.

I recently successfully imported a physical line-of-business (LOB) server into Hyper-V. In other words, replacing a physical server with a virtual machine. That migration is a procedure that lots of businesses, small and large, will be encountering for reasons similar to my own.

What are those reasons? Well, they’re the usual rationale that favor virtualization. First, the LOB file server in question was getting old (three years). And while my firm has standardized on Dell server gear, that one was a custom job from a local shop. Eliminating old and/or non-standard hardware helps to drive down support and maintenance cost.

Second, there’s the question of power consumption. While the server-class hardware from Dell has a pretty serious power footprint, virtualization allows that footprint to be split between multiple machines that would otherwise each require their own chassis.

Third is physical space. While our data center isn’t really hurting in this area, I frankly don’t like clutter, and this was an opportunity to eliminate some. This is minor point in our case.

However, the biggest reason – by far – is disaster recovery (DR). I read an article recently that drove this point home with a couple of interesting statistics. First, that the majority of businesses that are forced to close for at least a month never reopen. Second, that DR costs are typically estimated to be 2x the cost of the underlying infrastructure.

Both stats make sense intuitively if you consider that most businesses have all of their value at one physical location. To the extent that there are digital assets that could be replicated offsite, that’s probably not being done. So if that’s all lost, due to a fire for example, the 2x factor means that the DR costs exceed those of just starting a new business. Scary.

Of course, the DR picture can look better when proper data back-up and recovery procedures are in place. To this point, the article suggests that VM images can be more readily archived and restored than physical drive images. I counter that by observing that data back-up and DR is hard, and expensive, no matter what. But once the proper infrastructure and education is in place, I do agree that VMs are a compelling option for these reasons.

Indeed, I think DR preparation will prove to be the first killer app for both virtualization and cloud computing for certain types of customer. While scalability is what drives some data centers to use virtualization, and is what’s driving some web application companies to experiment with cloud computing, DR is a concern for every business that has at least one computer. The industry will soon be at the point where it’s feasible, and even actually cheaper, to locate computing resources such as file storage and key LOB apps offsite even for non-technical businesses.

Thus, for all of those reasons, I migrated a physical 64-bit Windows Server 2003 file server over to Hyper-V. I essentially followed the steps in this blog post, including the use of VMware Converter and Vmdk2Vhd.

A few additional notes about that procedure: first, while the VMware tool ran fine on 64-bit Windows Server 2008, Vmdk2Vhd did not. Instead, I ran the latter on a 32-bit Vista workstation and just converted the files via the network. I’m sure I paid a non-negligible performance penalty, but it worked.

Which brings me to what I believe to be the main hurdle in performing this procedure against production servers: it takes a long time, end-to-end. File servers in particular are likely to hold lots of data. Converter must take an image of the data, while the machine is running, and copy it across the network. Our file server had two 150 GB disks. Together they were half-full. That took approximately 24 hours. Once that was done, I ran the two images through Vmdk2Vhd in parallel; that took around eight hours.

Those are unattended operations, of course, so it’s not like all that time is wasted. And while there’s probably an additional load on the target server during that time, it remains online and accessible. The main challenge I see is in synchronizing the new disk images with the production server until you finally cut over from the latter to the former in production. So, from the time Converter completes until the DNS/IP change-over to the VM, changes made to the disks on the original server will be lost unless you copy them manually (or, better, avoid them entirely) to the VM once it’s up.

Naturally, you want to follow the above steps carefully, and test the new VM before connecting it to the network. I wasn’t too scared, though: the nice thing about this procedure is that the existing server stays online until the very end. So if anything goes wrong bringing up the VM, you’ll have time to debug and try again. I got through the entire process without a single hitch, even though it was my first time.