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.
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.
Might change for AMD PCNet or VMXnet and get different MAC addresses. The IP address of each interface must be individually reconfigured.
Might be updated during the cloning process.
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.
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
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 Linux P2V
Ports Required During a V2V
- 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.
- 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.
- 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?
c:\> set devmgr_show_nonpresent_devices=1