Virtual-to-physical conversions: Why and how

Almost everyone involved in virtualization has done, or at least knows about, the physical-to-virtual (P2V) conversion process to convert a physical server to a virtual machine. But what if you need to do a virtual-to-physical (V2P) conversion and go back to a physical server? The P2V process is fairly easy and straightforward and there are many free and paid robust tools that will do this. The V2P process, however, is not supported by many tools and is much more complicated than a P2V.

You might wonder why you would want to turn a virtual machine back into a physical server. In most cases the reason for this is due to application vendors not supporting their products when they are running on a virtual machine. Almost all vendors now support virtualization, but there is usually a caveat about that support which you'll see in their support statements.
If a vendor is troubleshooting a problem with its application running in a virtual environment, the vendor may require you to reproduce the problem on a physical server before they will help you. Why? Because the technicians want to make sure the virtualization layer isn't the cause or a contributing factor to the problem, and the only way to eliminate it as a suspect is by reproducing the problem on a physical server. Here are some typical support statements from some major vendors:

IBM/Lotus:
When a customer calls in with a standard usage or defect-related service request, and indicates that they are running on VMware ESX Server, IBM Technical Support will make best efforts to resolve the problem. We will assume that the problem is common to both native and VMware environments, and we will only require the customer (or the VMware SupportLine team) to recreate the problem if there is an indication that the problem may be unique to the VMware environment.
Microsoft:
For Microsoft customers with Premier-level support running non-Microsoft hardware virtualization software from vendors with which Microsoft does not have an established support relationship that covers virtualization solutions, Microsoft will investigate potential issues with Microsoft software running together with non-Microsoft hardware virtualization software. As part of the investigation, Microsoft may require the issue to be reproduced by the customer independently from the non-Microsoft hardware virtualization software. This may be done on Windows Server 2008 (with Hyper-V), the actual hardware platform with the Windows operating system installed directly upon it, or on both.
Cognos:
Cognos Support will work to resolve any reported IBM Cognos product issues. Should Cognos customers who use IBM Cognos products within virtualized environments experience issues; Cognos customers will not be required to recreate and troubleshoot every issue in a native operating environment. However, Cognos does reserve the right to request our customers to diagnose certain issues in a native certified operating system environment without the virtual image. Cognos will only make this request when there is reason to believe that the virtual environment is a contributing factor to the issue.
Computer Associates:
While CA does not insist that clients recreate each issue without VMware before contacting support, we reserve the right to request the client diagnose and troubleshoot specific issues without the VMware "variable". This will only be done where we have reason to believe the issue is directly related to VMware.

As you can see from these VMware support statements, the vendors all reserve the right to ask you to recreate the problem in a non-virtual environment. In most cases, however, this will not happen as most applications don't know the difference between virtual and physical hardware. Depending on the problem type, vendors should recognize that the virtualization layer has nothing to do with it. But there is one type of problem in particular where the virtualization layer might be at fault, and would be a candidate for a V2P request -- performance problems.
Many performance problems are caused by improperly configured or architected virtualization environments; this can include host hardware, storage, networking, host and virtual machine (VM) settings, over-commitment and much more.
Application vendors are usually only capable of troubleshooting application and operating system-related things that may be the cause of the problem. They often do not have the knowledge or expertise to look at the virtualization layer to see if it's at fault. Often times input/output (I/O) bottlenecks and resource contention on virtual hosts are not obvious, even to experienced virtualization administrators, and especially to application support people. It's easier for them to have you reproduce the problem on a physical server to eliminate the virtualization layer. So what do you do while dealing with the application vendor support if they make the request for you to go physical?
Converting a virtual machine back to a physical server (and later back to a VM) can be a royal pain in the butt. But there are some options that can help make this easier, and you might be able to avoid the situation completely.

• Investigate the virtualization layer on your own to see if it is indeed at fault. As I mentioned, I/O bottlenecks are often not obvious until you actually look for them. To find them you need to leverage virtualization-specific performance monitors that are either built-in to the virtualization management application or from third-party vendors. Third-party vendor tools are often more robust and can often times correlate a change in the environment to the start of performance problems.
  Here are a few common things that could cause performance problems in virtual environments:
  
  1. Memory or CPU limits on a VM
  2. Using memory over-commitment and exhausting physical host memory
  3. Too many vSMP VMs and not enough CPU cores to handle them
  4. VM or host configuration settings
  5. High disk/network I/O caused by operations such as backups
  6. Too many high disk I/O VM's on a single host or LUN
  7. Improper storage/network architecture
• Consider purchasing both virtualization software and application support from the same vendor. By doing this, the vendor is forced to support both the application and the virtualization layer. That way, instead of making you reproduce the problem on a physical server, the vendor can simply transfer the problem to the appropriate support group. Some vendors, such as IBM also provide hardware support, making them a complete one-stop support shop by supporting the hardware, virtualization software and application software.
• Consider using a raw device mapping (RDM) disk attached to a virtual machine for your application and data. You can install the guest OS of the VM on a regular virtual disk and the application and any data on a RDM disk. Next, keep a single physical server around with the same guest operating installed on it and access to your storage area network (SAN) fabric. Then you can simply shut down the VM, mask the RDM from the virtual host and present it to the physical server, which will then have access to the application and data. You can then run and troubleshoot the application on the physical server; once you are done you can do the reverse and present the RDM back to the VM.
• If you have no other recourse but to do a V2P conversion, there is a manual method for doing it that VMware has outlined in a tech note, but it is complicated and time-consuming.
• Many tools that support P2V conversions do not support V2P conversions, but there are a few that do support -- namely PlateSpin Migrate (formerly PowerConvert) and EMC HomeBase (Vizioncore's vConverter will support it in a future release). Using tools like this can definitely make the V2P process easier, and it's faster than trying to do this manually using third-party disk imaging tools.

Troubleshooting application problems can sometimes be challenging in virtual environments, especially when vendors make it difficult by blaming the virtualization layer. It's easy for vendors to blame things other than the vendor's application as the root cause to an issue, but sometimes virtualization is to blame for reasons I noted above. Knowing how to identify and resolve performance problems and resource bottlenecks in your virtual environment is important so you can eliminate that as a cause before you contact a vendor for application support. When you do contact a vendor, it's best to not try and hide the fact that the application is running inside a virtual machine. Make sure you know the vendor's support policy when it comes to virtualization so you can correct the representative if he or she claims the company doesn't support it.
Some may not understand virtualization and may be quick to point fingers, so make sure you explain to them why you feel that virtualization is not to blame. If you feel strongly that virtualization is not the cause make sure and escalate the case so you can explain it to someone higher up. If all else fails and you are forced to do a V2P, at least now you have some options available to hopefully make it easier for you.