Physical-to-virtual (P2V) conversions turn physical servers into virtual machines (VMs), but they can also play a part in the disaster recovery strategy for servers that remain in the physical realm.
Some physical servers don’t make good VM candidates, often because of the “oomph” they require to do their job. Most infrastructures tend to keep around a few physical servers that would use too many resources if virtualized.
So how do you recover those servers when disaster strikes? Recovering a VM is fairly simple, because its files are consolidated into a single virtual disk file, and it’s easy to replicate that file to a secondary location. Things get trickier with physical servers, but you can use P2V conversion to develop a virtualization disaster recovery strategy.
Virtualization disaster recovery with P2V conversions
P2V migration isn’t just for converting physical machines to virtual ones. You can run a P2V conversion on physical servers to strengthen a virtualization disaster recovery strategy. Instead of turning on the virtual copy once the P2V migration is complete, though, keep the physical instance running as usual. You then have a virtual copy of that physical computer with its files nicely consolidated into a virtual disk, which can be easily replicated to a DR site.
Should you experience a disaster at your primary site, you can simply power on the virtual copy. None of the usual “Start with the OS, layer data over the top” restore processes of yesteryear need apply.
Obviously, you didn’t virtualize this system in the first place because of performance or other concerns. But in a virtualization disaster recovery situation, you’re likely to have a much lower load in the data center until you return to full production. It’s fine for the physical server to function as a VM until then.
When operations return to normal, you can convert the virtual server back to a physical one. Virtual-to-physical products combine with third-party P2V conversion products to get the server back to its final physical resting place.
Anytime you virtualize a system that you didn’t intend to virtualize in the first place, you have to be careful. Never turn on both systems at once. And as you develop a virtualization disaster recovery strategy, plan for the additional resources that a virtual copy of the physical server will use at the DR site.
For your own administrative sanity, consider investing in a third-party P2V migration tool that automates the process and can update the virtual disk file with changes between P2V activities. (You won’t find those features in many of the first-party tools, such as
VMware Guided Consolidation or Microsoft System Center Virtual Machine Manager.) The good news is that most third-party P2V conversion tools aren’t terribly expensive, and they’ll save you time in daily backups.