Convert a system with VMware Converter

原文：Convert a system with VMware Converter — theDXT (Daniel Keer)

There are a few ways to convert a system either P2V (Physical to Virtual) or V2V (Hyper V to VMware). This will show you how to convert a system using VMware vCenter Converter Standalone Client.

Before you start you should check a few things to make the whole process streamlined.

Before You Start

1. Check that the system is fully up to date (you might get stuck in an update trap if you don’t)
2. Check that you have remote access to the system (so that if needed you can at least get back into the system easily)
3. Make a note of the IP configurations (you will likely need to re add them)

4. If the system a domain member make sure that you know the local admin username and password (this is so that if it fails to talk to the domain you at least have a way back into the system)

Each of these points exists because of a failure someone has already had. A machine that is halfway through a Windows update when the conversion runs can end up with a snapshot of a broken update state, and the resulting VM will try to finish the update on first boot with different hardware behind it — the "update trap" the note warns about. Remote access matters because the source machine stays powered on through the first pass and you will want to check it after the final cutover. Writing down the IP configuration matters because the converted VM comes up with the network adapter it inherited, and on a physical-to-virtual move the MAC address changes, so any static assignment, VLAN or DHCP reservation keyed to the old NIC has to be redone by hand.

A local administrator credential is the safety net for a domain-joined server: after conversion the VM may not reach a domain controller before it finishes booting, and a cached domain login is not always available for a freshly imaged guest. The local account is what gets you to a console either way.

Two more checks are worth adding to the list. Confirm you have free space on the destination datastore at least as large as the used space on the source disk, and confirm the ESXi host you are targeting has the CPU features the source operating system expects — a very old physical server can carry quirks that a modern virtual CPU does not reproduce.

Installing and Launching the Converter

5. Install VMware vCenter Converter Standalone Client on the system you will be converting.

6. Run VMware vCenter Converter Standalone Client as Admin

7. Click on Convert machine

Installing the client on the source machine is the simplest layout for a local P2V, because the agent that reads the disks runs in the same operating system it is imaging. Running it as Administrator is not optional: without elevation the agent cannot read the volume shadow copy service and the conversion fails partway with an access error. If you are converting a remote machine instead, install the client on a management workstation and point it at the source, but bear in mind that the remote path needs the same credentials and firewall openings as a local run.

Selecting the Source

* Change the setting to Powered on and select This local machine

Choosing Powered on tells the converter to take a live snapshot of the running system rather than asking you to boot from a disc. This is what makes the whole exercise practical: the source keeps serving users while the first copy is made, and the outage is reduced to the final synchronisation window. This local machine tells the client it is already sitting inside the system it needs to read.

Connecting to the Destination

* Feed it your VCSA or ESXi info

Enter the vCenter Server Appliance or the standalone ESXi host that will receive the VM, together with credentials that have permission to create virtual machines and write to the target datastore. Converting directly to an ESXi host is faster to set up, but converting through vCenter is the better habit because the resulting VM is registered in the inventory you actually manage.

If you get an SSL warning click do not display and click Ignore

The warning appears because the default certificate on the ESXi host or appliance is self-signed. Ignoring it is normal in a lab and acceptable inside a trusted management network; in a production environment the right long-term fix is to trust the certificate chain rather than click past a warning every time.

Choosing the Destination and Name

* Select the location where you want to put the VM and give it a name.

Pick the datacenter, folder and cluster that represent where this workload belongs, and give the VM a name you will recognise in six months. A common convention is to suffix the source hostname or append a date, so the converted VM is obviously a cutover artefact rather than a second live server someone forgot about.

* Select the specific host and the datastore for the VM

Now choose the ESXi host and the datastore that will hold the virtual disks. This is the point to think about storage performance, because the converted disks inherit their layout from the source; a thin-provisioned datastore that is nearly full is a bad target no matter how small the source disk looks.

Adjusting the Virtual Hardware

Here you can change some of the VM settings if needed

This is where you right-size the guest instead of copying the physical server's specification verbatim. A file server that had 32 GB of RAM because a slot cost nothing does not need 32 GB as a VM, and a VM with eight virtual CPUs on a host with eight physical cores will be scheduled worse than one with four. Adjust memory, CPU count, disk controller type and network adapter here; the defaults are usually a reasonable starting point for a first conversion, but the network adapter is worth setting deliberately, since the choice affects how the guest driver is installed later.

For this we will be seeding the system to the VMware server. Doing this will allow you to have a shorter outage and will let you do the final cutover at a later time.

Seeding with Synchronize Changes

• Click on Edit beside Advanced options

* Click on Synchronize changes and uncheck final synchronization then click on Next.

Unchecking the final synchronisation is what turns a one-shot copy into a seed. The converter copies the whole disk now, and leaves the job open so it can come back and send only the blocks that changed since. This is the mechanism that shrinks the cutover window from hours to minutes: the expensive part happens while everyone is still working.

* Review the settings and make sure everything looks right.

You will now see that it has created a task in VMware vCenter Converter Standalone

Right now VMware vCenter Converter Standalone is sending the system to your VMware server.

After it finishes the first task it will make another one to sync up any changes since the first task.

Watch the task list rather than the progress bar. A conversion that stalls at a high percentage is usually waiting on VSS to release a volume rather than actually transferring data, and the task log will say so.

The Final Sync and Cutover

Now that we have the system seeded it’s time to do the final sync and cutover

• Click on Job > Synchronize

* Click on Edit beside Advanced options

* Select Preform final synchronization

* Review everything if it looks correct click Finish

Right now VMware vCenter Converter Standalone is doing all the final tweaks needed to make the system work on your VMware server and sending over any information that has changed from the time of the first sync.

• Once it is finished turn off the system that you were converting.

This is the window to keep short. The final synchronisation has to bring the target up to date with everything that changed since the seed, so the longer you wait, the longer this pass takes — and the longer both copies of the system think they are authoritative. Stop the source, run the final sync, and then power on the target; do not leave the source running while you test the VM, because two machines with the same hostname and the same IP on one network cause exactly the name-collision and ARP problems you were trying to avoid.

* Turn on your converted system and set the IP and install VMware tools

The first boot is where the conversion is really validated: the guest should detect the virtual hardware, install or bind drivers, and come up with its disks intact. Set the IP address to what you recorded earlier, and install VMware Tools so that time synchronisation, the paravirtual drivers and a clean shutdown all behave properly.

Post-Conversion Cleanup

• Uninstall VMware vCenter Converter Standalone Client

• It’s probably a good idea to defrag the system as a lot has changed.

Removing the converter client is housekeeping, but it also removes the agent service that was reading the disks, which you no longer want running on a production guest. Defragmenting mattered much more on rotating media than it does on flash-backed datastores; on modern storage the higher-value cleanup is checking that the disk partition alignment is correct and that the guest sees the expected free space.

Then finish the job properly: confirm the services that should start automatically do start, check the event log for driver warnings from the first boot, re-verify any application licence that is tied to hardware, and only then retire the physical machine. Leave the original powered off but intact for a week before you wipe it — a conversion that looks clean on day one sometimes reveals a missing dongle, a hardware key or a fixed IP dependency in the day-two checks.

That’s it you are done.

When the Conversion Fails

• Hangs at a high percentage. Usually VSS — check free space, check that no backup is running against the source at the same time, and retry.
• Cannot read a volume. BitLocker, a dynamic disk or an unsupported filesystem on the source; decrypt or exclude that volume.
• Login fails on the source. Use the fully qualified local administrator account and confirm the account is not locked out by a policy.
• Target will not boot. Often a storage controller mismatch; check the controller type you selected against what the source operating system ships drivers for.
• Network missing after boot. Set the adapter type you prepared for and let the guest install its NIC driver, then set the IP again.

For more VMware housekeeping and guest management, see ESXi vSwitch, port groups and VLAN teaming, setting a static IP on ESXi and installing VMware Tools on Windows Server Core. If the converted guest is going to sit on 3PAR or Primera storage, troubleshooting 3PAR with VMware covers the storage side.