Clearly server virtualization at the remote site offers some tremendous benefits because you can use fewer resources at that remote site and you can likely make better use of replication technologies to move data over there. But at your primary site, there may be more sticky issues to deal with.
You need to think of I/O at your primary site and whether server virtualization is a good fit for every application you have in your environment. These days, you have powerful enough hardware and strong enough options around I/O that even heavy I/O apps in lots of environments can be virtualized like Exchange, SQL Server and some of the things folks have been hesitant to virtualize in the past. That will facilitate doing DR because once those machines are in a virtual image, it's easier to move them.
But if you've got a machine that you're absolutely against virtualizing, you're going to have to deal with a few sticky issues like converting them onto DR servers or else just dealing with a partially virtualized environment at your DR site.
So I see two approaches there. You're going to have full virtualization of your server environment and everything you need to recover at your primary site and your remote site. Or, you're going to have a partially physical environment at your primary site and a fully virtualized environment at your DR site. If so, you're going to have to deal with replicating or putting the physical servers into a virtualized environment at your DR site and there are some sticky issues there.
You need to look at some type of third-party solution that will allow you to grab that physical image and move it into a virtualization environment that's going to have some different drivers and you're going to have to be more stringent about your testing. If you can virtualize completely at both locations, your DR is going to be a lot easier to manage.
This was first published in September 2008