Posts Tagged ‘Converter’

HOW TO: Synchronize Changes in a Linux P2V with VMware vCenter Converter Standalone 9.0 (Part 101)

Thursday, November 27th, 2025

If you’ve ever attempted a P2V migration using VMware vCenter Converter Standalone 9.0, you’ll know that the product can be as unpredictable as a British summer. One minute everything looks fine, the next minute you’re stuck at 91%, the Helper VM has thrown a wobbly, and the Estimated Time Remaining has declared itself fictional.

And yet… when it works, it really works.

This post is the follow-up to Part 100: HOW TO: P2V a Linux Ubuntu PC, where I walked through the seed conversion. In Part 101, I push things further and demonstrate how to synchronize changes — a feature newly introduced for Linux sources in Converter 9.0.

I won’t sugar-coat it: recording this episode took over 60 hours, spread across five days, with 22 hours of raw footage just to create a 32-minute usable video. Multiple conversion attempts failed, sequences broke, the change tracker stalled, and several recordings had to be completely redone. But I was determined to prove that the feature does work — and with enough perseverance, patience, and the power of video editing, the final demonstration shows a successful, validated P2V Sync Changes workflow.


Why Sync Changes Matters

Traditionally, a P2V conversion requires a maintenance window or downtime. After the initial seed conversion, any new data written to the source must be copied over manually, or the source must be frozen until cutover.

Converter 9.0 introduces a long-requested feature for Linux environments:

Synchronize Changes

This allows you to:

  • Perform an initial seed P2V conversion

  • Keep the source machine running

  • Replicate only the delta changes

  • Validate the final migration before cutover

It’s not quite Continuous Replication, but it’s closer than we’ve ever had from VMware’s free tooling.


Behind the Scenes: The Reality of Converter 9.0

Converter 9.0 is still fairly new, and “quirky” is an understatement.

Some observations from extensive hands-on testing:

  • The Helper VM can misbehave, especially around networking

  • At 91%, the Linux change tracker often stalls

  • The job status can report errors even though the sync completes

  • Estimated Time Remaining is not to be trusted

  • Each sync job creates a snapshot on the destination VM

  • Converter uses rsync under the hood for Linux sync

Despite all this, syncing does work — it’s just not a single-click process.


Step-by-Step Overview

Here’s the condensed version of the procedure shown in the video:

  1. Start a seed conversion (see Part 100).

  2. Once complete, use SSH on the source to prepare a 10GB test file for replication testing.

  3. Run an MD5 checksum on the source file.

  4. Select Synchronize Changes in Converter.

  5. Let the sync job run — and don’t panic at the 91% pause.

  6. Review any warnings or errors.

  7. Perform a final synchronization before cutover.

  8. Power off the source, power on the destination VM.

  9. Verify the replicated file using MD5 checksum on the destination.

  10. Celebrate when the checksums match — Q.E.D!


Proof of Success

In the final verification during filming:

  • A 10GB file was replicated

  • Both source and destination MD5 checksums matched

  • The Linux VM booted cleanly

  • Snapshot consolidation completed properly

Despite five days of interruptions, failed jobs, and recording challenges, the outcome was a successful, consistent P2V migration using Sync Changes.


Watch the Full Video (Part 101)

If you want to see the whole process — the setup, the problems, the explanations, the rsync behaviour, and the final success — the full video is now live on my YouTube channel:

Part 101: HOW TO: Synchronize Changes using VMware vCenter Converter Standalone 9.0

If you missed the previous part, you can catch up here:
Part 100: HOW TO: P2V a Linux Ubuntu PC Using VMware vCenter Converter Standalone 9.0


Final Thoughts

This video was one of the most challenging pieces of content I’ve created. But the end result is something I’m genuinely proud of — a real-world demonstration of a feature that many administrators will rely on during migrations, especially in environments where downtime is limited.

Converter 9.0 may still have rough edges, but with patience, persistence, and a bit of luck, it delivers.

Thanks for reading — and as always, thank you for supporting Andysworld!
Don’t forget to like, share, or comment if you found this useful.

HOW TO: Improve the transfer rate of a Physical to Virtual (P2V), Virtual to Virtual Conversion (V2V) using VMware vCenter Converter Standalone 5.0

Sunday, January 8th, 2012

VMware vCenter Converter Standalone 5.0 is a FREE tool available from VMware upon registration, the purpose of this software tool is to easily convert physical or virtual computers, images of computers to VMware virtual machines. Server and Workstation operating systems are supported in the conversion.

Download VMware vCenter Converter Standalone 5.0 here
VMware vCenter Converter Standalone 5.0 Documentation
VMware vCenter Converter Standalone 5.0 User Guide

In September 2011, VMware released version 5.0 of VMware vCenter Converter Standalone 5.0, with many new features including partition alignment important for aligning partitions correctly on storage array networks (SAN).

BUT, we’ve noticed that completing conversions using VMware vCenter Converter Standalone 5.0 compared to using VMware vCenter Converter Standalone 4.3, were taking much longer, and the transfer rate of a conversion had become degraded when using version 5.0.

The following modification will improve the transfer rate when using VMware vCenter Converter Standalone 5.0, to similar transfer rates obtained when using VMware vCenter Converter Standalone 4.3 to perform conversions.

It would appear that VMware uses a proprietary VMware protocol called NFC, to image to destination, also by encrypting (SSL) the data payload transfers in version 5.0, this additional overhead causes transfer performance degradation. The result of which is a longer than expected conversion time, when compared to version 4.3.

Turning OFF SSL Encryption in VMware vCenter Converter Standalone 5.0 can improves transfer rates.

(if appropriate for your environment)

To turn OFF SSL Encryption in VMware vCenter Converter Standalone 5.0, please follow the following steps:-

  • Find and Edit converter-worker.xml

this file is location in the following locations

Windows Vista, Windows 7, Windows 2008
%ALLUSERSPROFILE%VMwareVMware vCenter Converter Standalone

Windows XP, Windows 2003, Windows 2000
%ALLUSERSPROFILE%Application DataVMwareVMware vCenter Converter Standalone

  • Change the SSL Key <useSsl> true </useSsl> to false

You may find it easier to edit the file using Microsoft XML Notepad 2007 to edit the XML file. But Notepad or Wordpad can edit the file, just ensure, you make a copy of the original file for backup before making any alterations. Using Microsoft XMP Notepad 2007, you do not have to scroll the contents of the file, and the <useSsl> section is quicker to find and alter, but whatever tool you find most comfortable to use to edit the file, is okay.

Change

<useSsl> true </useSsl>

to

<useSsl> false </useSsl>

save the XML file.

Using Microsoft XML Notepad 2007

Using Microsoft XML Notepad 2007

Using Microsoft XML Notepad 2007 to change to false

Using Microsoft XML Notepad 2007 to change to false

  • Restart Service

For changes to take effect – Restart “VMware vCenter Converter Standalone Worker” service.

  • Results

We have seen performance increases from at least 2x to 6x. So if you want to half the conversion time at least, then alter the encryption setting. If appropriate for your environment.

In the following example, a Windows 2003 Server was converted from Virtual Machine to Virtual Machine (V2V) using VMware vCenter Converter Standalone 5.0 installed on the server to be converted. In the first conversion (TaskId10) the SSL Key was left as the default TRUE, and encryption was used. In the second conversion (TaskId11), the SSL Key was set to false.

As can be seen from the following screenshots Average Transfer rate has increased from 2 MB/s to 6 MB/s and the conversion time has reduced from 1hr 38mins to 33mins.
.

Default encryption value of true 2MB/s transfer rate

Default encryption value of true 2MB/s transfer rate

Default encryption value of false 6MB/s transfer rate

Default encryption value of false 6MB/s transfer rate

A performance increase of 60%! just by chaning a value from true to false.