Posted by: Rick Vanover
P2V migrations, Rick Vanover, VMware Converter
In the course of performing many physical-to-virtual (P2V) conversions, I still come across situations where a small configuration can make or break the task. Recently, I performed a P2V conversion of a system that was successful in all measurable elements from the VMware Converter and ESX-based virtual machine standpoint, yet the application was not functioning as expected. One important part of this conversion is that the virtual machine changed networks during the conversion. Everything checked out locally on the virtual machine, including DNS configuration, subnet mask and the IP default gateway. Yet the application still had issues working correctly.
Later on, I had discovered that there was a DNS record for the same IP address of the converted system. In this scenario, the workload had a separate DNS name that was in use by the application and not exclusively using the host name. Further, I believe that the record was a previous computer name of the converted system, and the application had some calls that still used the old name. Before I noticed this entry in DNS, I had checked the local host file on the Windows virtual machine to ensure that there were no entries pointing to an IP address other than 127.0.0.1 for any local references.
So what can be done to make sure that this bizarre information does not happen again? In the pre-conversion steps, take a look through the DNS zones and see if the IP address or the hostname are pointing to anything that references a specific IP address. While applications may have configuration beyond the scope of a P2V conversion, identifying any DNS or host file configuration before the conversion can save some frustrating and possibly unexplained application failures.