vCenter Converter Considerations

vCenter Converter Considerations

So there are still people out there looking to virtualise their existing server hardware as we don’t live in a complete virtualised world yet.

With VMware vCenter Converter 6.2, you can migrate your workloads over to a vSphere environment, whether from a supported physical Linux or Windows server or even from VMware Workstation.

There are several other advantages to using the vCenter Converter, such as resizing the volumes to fit on the new infrastructure as well as customising the virtual hardware before booting up as a virtual machine. The biggest bonus of using vCenter Converter is that it is free to use. There are other useful migration tools out there which are possibly better, albeit at an additional cost and more suited for scheduling large quantities of workloads, i.e. PlateSpin Migrate that requires less manual intervention. (there will be another post here detailing a comparison of these two products).  My favourite for scheduling workload migrations is using the Veeam Backup and Replication 9.5 and replicating virtual or physical workloads across. There is a feature in here to remap the networking to the new destination.

Meanwhile, as this post is focusing on VMware vCenter Converter utility, I will discuss this in a little more detail.

Whether migrating away from legacy old equipment or that standalone Oracle server box, the converter will keep the servers in sync before final cut over. This is a really cool feature in a free product from VMware that is simple to use and offers guest customisation of the virtual machines during migration. However, this tool will migrate machines and offers no error checking against OS or application stability.

Key features

Performance and Reliability

  • Multiple simultaneous conversions enable large-scale virtualisation implementations.
  • Quiescing and snapshotting of the guest operating system on the source machine before migrating the data ensures conversion reliability.
  • Hot cloning makes conversions non-disruptive, with no source server downtime or reboot.
  • Sector-based copying enhances cloning and conversion speed.


vCenter Converter supports many source physical machines, including Windows and Linux desktop and server editions. It also supports refactoring conversion of third-party virtual machines like Hyper-V and KVM


  • Centralised management console allows users to queue up and monitor multiple simultaneous remote, as well as local, conversions.
  • Easy-to-use wizards minimise the number of steps to conversion.
  • Support for both local and remote cloning enables conversions in remote locations such as branch offices.


Hardware Changes After Virtual Machine Migration

CPU model and serial numbers
Might change after migration. They correspond to the physical computer hosting the VMware virtual machine.
Ethernet adapters
Might change for AMD PCNet or VMXnet and get different MAC addresses. The IP address of each interface must be individually reconfigured.
USB adapters
Might be updated during the cloning process.
Graphics cards
Might change after migration (VMware SVGA card).
Disks and partitions
The number of disks and partitions might change during the cloning process. Each disk device might have a different model and different manufacturer strings.
Primary disk controllers
Might differ from the source machine.


Running concurrent tasks is set to max of 12
  • Verify permissions
  • Ensure DNS is resolvable and use IP addresses (instead of FQDNs) where possible
  • Avoid using vendor recovery partition
  • Adjust disk sizes if exact size does not work, this forces converter to use a final level copying
  • Ensure 500MB of free space is available on source system
  • Run a check disk on source
  • Do not customise prior to conversion
  • Ensure that workstation, server, TCP/IP net bias and volume shadow copy services are running, windows only
  • Ensure firewall is configured correctly
  • unplug any devices attached to source
  • ensure that the convert agent is installed on the source machine


Supported Sources

Powered on machines 

  • Remote Windows physical machines
  • Remote Linux physical machines
  • Local Windows physical machines
  • Powered on VMware virtual machines
  • Powered on Hyper-V Server virtual machines
  • Powered on virtual machines running under Red Hat KVM or RHEL XEN

Hyper-V Server virtual machines 

For Hyper-V Server versions distributed with Windows Server 2008 R2, Windows Server 2012, Windows Server 2012 R2, Windows 10 and Windows Server 2016, powered off virtual machines with the following guest operating systems:

  • Windows Vista SP2 (32-bit and 64-bit) (except Home editions)
  • Windows Server 2008 SP2 (32-bit and 64-bit) (except Home editions) n Windows 7 (32-bit and 64-bit) (except Home editions)
  • Windows Server 2008 R2 (64-bit) (except Home editions)
  • Windows 8 (32-bit and 64-bit)
  • Windows Server 2012 (64-bit)
  • Windows 8.1 (32-bit and 64-bit)
  • Windows Server 2012 R2 (64-bit)
  • Windows 10 (32-bit and 64-bit) (except Home editions)
  • Windows Server 2016 (64-bit)

For other Hyper-V Server sources, perform the procedure for powered on source machines.

For an extensive list, please review the links in additional resources and lookup in the production documentation.

Ports Used When Converting a Powered on Machine

Ports Required During Windows P2V


Ports Required During Linux P2V


Ports Required During a V2V


  • Networking
    • Ping (ICMP echo request) support for discovery.
    • Firewall exclusions in place for migration.
    • Relevant ports open for discovery and migration process.
    • Transfer speeds depend on the network latency.
    • Network mapped drives may need to be reapplied after migration.
  • Migration
    • Device drivers may be required for successful migration.
    • The amount of data will have an impact on migration times.
    • Third-party management tools for hardware should be removed prior to migration.
    • Unwanted files are removed from the server to save space and time.
    • Special considerations for Domain Controllers, preferably new virtual DC are recommended.
  • Linux Migrations
    • Migration of encrypted volumes are not supported.
    • Workloads imaging is not supported in Linux workloads.
    • Migration of UEFI-based Linux workloads to Hyper-V target container is not supported.
    • Conversion between UEFI and BIOS based Linux systems is not supported.
    • Migrate supports EXT2, EXT3, EXT4, REISERFS, and XFS Linux file systems.
    • Migrate supports Linux workloads with /boot on the first disk (sda).
    • Linux-based source workloads must be running a Secure Shell (SSH) server.
    • Complex migrations due to special workloads that use multiple tiered applications, span multiple sites or servers may require special consideration or downtime.
  • Licensing
    • OEM licensing cannot be migrated and new licenses will be required.
    • Applications licensed per processor will need to be identified and possibly relicensed.

What should I do after I successfully convert my virtual machine?

Of course once you have successfully migrated a machine in to the new environment, there are a few additional steps to take to ensure a clean server without the legacy old drivers that would have also migrated across.
If you change from a multi-processor system to a uni-processor system you need to manually change the HAL on the Windows server after the conversion. To do this go into Device Manager after the machine first boots and discovers it’s new hardware and then click on Computer then right-click on the processor and select Update Driver. Then select Install from specific location and then Don’t search I will choose the driver to install. Then select show All compatible hardware and select the appropriate processor. For example, if you went from a dual cpu to a single cpu then select ACPI uni-processor PC instead of ACPI multi-processor PC. You will need to reboot once you change this. To verify what HAL you are using you right-click your hal.dll in c:\windows\system32 and select the Version tab and select Internal Name and it should say halmacpi.dll for multi-processor acpi and halacpi.dll for uni-processor acpi.
Next clean up all the non-present hardware after the P2V conversion. To do this go to a CMD prompt and type SET DEVMGR_SHOW_NONPRESENT_DEVICES=1 and then DEVMGMT.MSC and then select Show Hidden Devices. Delete any old grayed out hardware.
Next remove any vendor specific applications/drivers. For example on a HP server you should go to Add/Remove programs and remove any HP management agents, survey utility, array config utility, version control agent, etc. Also check your NIC and make sure there are no vendor specific drivers there (ie. teaming). Check the Services to see if all there is anything vendor specific related there and disable any services that are.
Open up command prompt on the new VM.
c:\> set devmgr_show_nonpresent_devices=1
then type :
c:\> devmgmt.msc
Additional Resources 

vCenter Converter Release Notes

Troubleshooting KB1016330 and KB1014588