Migrating a system from a physical machine to a virtual machine P2V (multi-image) using VMware Vconverter

zhuan:1190000002697929

This article is a complete record of how to keep all the environment configuration information from the physical server, motionless migration to the virtual machine, commonly known as P2V. The tools used are VMware, whichVMware vcenter vconverter standalonesupports the use of Windows and Linux operating systems as a source and can perform several transformation tasks:

• Import running remote physical machines and virtual machines as virtual machines into a standalone esx/esxi or Esx/esxi host managed by Vcenter Server
• Import virtual machines hosted by VMware Workstation or Microsoft Hyper-V server to a Esx/esxi host managed by Vcenter Server
• Import a third-party backup or disk image into a vcenterserver managed Esx/esxi host
• Migrating legacy servers to new hardware without reinstalling the operating system or application software
• See the Converter Standalone User Guide for full functionality

Converter Standalone components that can only be installed on the Windows operating system:

• Converter Standalone server--Enabling and performing import and export of virtual machines
• Converter Standalone agent--converter Standalone Server installs the agent on the Windows physical machine to import these physical machines as virtual machines and, when completed, can choose to automatically delete
• Converter Standalone client--is used in conjunction with the Converter server, including the user interface seen, creating and managing conversion tasks, and more
• Vmware vCenter Converter Boot CD: A separate component that can be used to perform cold cloning on a physical machine

Cold clones can create exact copies of a consistent source computer, and we are more likely to perform hot clones, which means that the source server will continue to work during the migration process, which may cause some file inconsistencies, but converter standalone will synchronize the target VM with the host after a hot clone. The synchronous execution process is the copy of the block changed during the initial clone from the source to the destination.

The process documented in this document is that the source host is a SUSE 11.x physical machine that runs  smart call center application, so the Oracle database is installed, and the consistency and security of the data files and control files is high, so it is recommended that the Oracle database be shut down before operation; the target virtual server is ESXi 5.1, but I use the converter is 5.5-en, the operation process is similar. The following officially begins

SOURCE Host: 172.30.31.0/24
ESXI:172.29.88.0/24, unable to communicate with the source host IP segment
Helper vm:172.29.41.0/24, with all two IP segments above

1. Set source and destination host addresses

• Source System
  Select the source system you want to convert, the physical machine for powered-on machines, fill in other login information:
  

• Destination System
  Fill in the host on which to create the virtual machine, that is, the ESXi server address:
  

These two processes have a brief process of pulling away the host information.

2. Select the target virtual machine and storage location

• Destination Virtual Machine
  The target virtual machine name is the source hostname by default, without selecting folder:
  

• Destination Location
  Select which datastore on ESXi the new virtual machines are placed on, make sure you have enough disk space, and cannot be less than the actual size that the source system is using:
  

3. Set other options for the conversion task

This step is particularly critical, directly related to the success or failure of subsequent conversions.

• Data to copy
  Set the disk and partition of the target virtual machine, we can see the source partition information obtained automatically, I here because the hard disk resource is limited, do not follow the default maintain size, but larger than minmun size (the used size that is seen under the source SuSEdf -h).
  
  The number of CPUs and the memory size default is also consistent with the source host.

• Network
  Network Settings This piece is more tangled. Supposedly, the source host does not need to communicate with the destination host network card, only the helper VM can be interoperable, but I have been stuck in this walk. The source host has 2 network card in use, finally in this step only set up a can ping the same host network card, after the migration is completed and then manually additive a network card. The following is the note from the official VMware Knowledge Base:

The Conversion Wizard, ensure to select the virtual machine portgroup when configuring the network card. This virtual machine PortGroup must was connected to the physical network, which is routable via port (SSH) in both direct Ions from the source Linux server ' s configured network IP address.
The IP address entered must is routable to the IP address of the physical Linux source machine. Helper virtual machine IP address should able to ping the physical machine.

As seen in the figure, VM Local is a newly created port group (portgroup) on the vsphere server, and the virtual Switch vswitch does not have any physical network cards associated with it:

• Helper VM Network
  The Helper VM is a temporary operating system for conversion, running on the destination host and copying data from the source host. If the conversion of Windows, there is no VM, instead of running an agent on the source host, so the conversion Windows requires ESXi and the source host can be interoperable, and the conversion of Linux only need to set the helper VM Network can be connected to the source host 22 port.
  

4. Start conversion

You can see a summary of the conversion information, and finish begins the migration process.

The test can be seen on ESXi to automatically create a virtual machine and start it. Wait for the conversion to complete.

5. Questions

Conversion several times failed because of improper network settings, converted to 1% times error:

Error:event.ObtainHelperVmIpFailedEvent.summary

The workaround is to manually set the IP of the HELPERVM and ensure that it communicates with the source host. If you continue to error, modify the destination Address card settings, such as the removal of only one network card (subsequent additions), also set to HELPVM network segment. Refer to Convert:converter.fault.HelperVmFailedToObtainIpFault.

When you convert Windows Server 2003, you may also receive

Unable tp locate the required Sysprep files. Please upload them under c:\documents and settings\all users\application data\vmware\vmware vcenter converter standalone\sysprep\svr2003 on the converter server machine

The workaround is to download Windowsserver2003-kb926028-v2-x86-chs.exe, execute windowsserver2003-kb926028-v2-x86-chs–x under cmd (WinRAR not available) , unzip out 2 directories plus a bunch of files, found in the SP2QFE directory Deploy.cab, and then the Deploy.cab decompression (winrar), get 10 files, copied to the svr2003 directory prompted. Refer to the Sysprep file location and version (2040984).

6. On Windows

Join the migration is the Windows host, the above operation is slightly different, the main difference is that there is no HELPERVM, but in the need to convert the source host on the installation agent. This requires that ESXi and the source host must be able to communicate directly before they can be migrated.

Migrating a system from a physical machine to a virtual machine P2V (multi-image) using VMware Vconverter