Moving Physical Workloads into VMware with vCenter Converter Standalone
Plenty of Australian IT shops still run a mix of physical and virtual infrastructure, often because old file servers or in-house apps were deployed before anyone had heard of hypervisors. Once a new ESXi host lands in the rack, those bare-metal boxes become the obvious consolidation targets. The free migration path most admins reach for is VMware vCenter Converter Standalone.
For sysadmins in Sydney, Melbourne, or Brisbane juggling remote sites on a stretched budget, the appeal is straightforward: no extra licence cost, a familiar Windows installer, and support for both powered-on and powered-off sources. The tool syncs changes and lets you schedule the final cutover during a quiet arvo maintenance window. There are limits around RAID controllers and UEFI quirks, but it covers most workloads found in regional offices.
This walkthrough covers staging the source through to a clean cutover, with notes on local realities like cross-state latency and the way Aussie support contracts usually work. Along the way I point to a few of the free tools on virtxpert for related jobs.
Preparing the Source Machine for Conversion
Before firing up Converter, spend ten minutes confirming the source is ready. Run a filesystem repair on volumes that look unhealthy and clear out temporary files for breathing room. Disable antivirus and backup agents that lock files at the driver level, then take a fresh full backup — Veeam, Backup Exec, or a USB drive if you are handling a customer in a regional town where cloud restore would be slow.
If the source is a domain controller, demote it before conversion or expect odd behaviour after the virtual clone boots. For physical Linux boxes, snapshot the bootloader and record the partition layout so you can verify the resulting VM later. Australian shops working under PSPF or with IRAP-aligned environments should also confirm the source meets the same hardening baseline the host will enforce once virtual.
Configuring the Conversion Job
Install Converter Standalone on a small Windows jump box that can reach both the source machine and the destination ESXi host. Choose Convert machine, then pick Powered-on for a live migration or Powered-off for a cold clone from a WinPE boot ISO. Point the target at your vCenter or standalone ESXi server and pick a datastore with enough free space — thin provisioning is tempting on a Spinning Rust shelf, but leave headroom for snapshots.
On the Options screen, set the virtual hardware version to match the rest of your fleet and decide whether to copy all disks or skip data partitions. Adjust CPU and RAM to sensible defaults. For servers behind a sluggish interstate link, say a Perth branch syncing to a Sydney datacentre, splitting large disks into smaller volumes and syncing them sequentially is more reliable than one monolithic job.
Running and Monitoring the Migration
Click Go and Converter spins up a temporary helper VM on the target host, attaches to the source, and starts streaming disk blocks. The first phase is the bulk copy — the slowest part — followed by synchronisation passes as production data changes. You can pause and resume without corrupting the destination, which helps when the arvo traffic spikes or someone schedules a video conference on the source.
Watch the job log for warnings about unsupported storage controllers or mismatched drivers. If the helper VM fails to register with vCenter because DNS or hostfile entries look wrong, Converter often surfaces that as a generic timeout. Plan for at least one restart of the target management agents; if ESXi is misbehaving, the home lab walkthrough on virtxpert has useful diagnostic commands you can run from the DCUI.
Cutover Steps After the Sync Completes
When the final sync is done, shut down the source — or at minimum stop the workloads on it — and trigger one last delta sync to capture those final transactions. Power on the cloned VM from vSphere, verify the network adapters picked up the right VLAN, and confirm the boot order matches expectations. For Australian environments, check time synchronisation against an NTP source such as the AARNet pool so logs align with the rest of the estate.
Rename the VM, move it into the correct resource pool, and update documentation before users return. If anything fails to start, boot the new VM from a rescue ISO and run a startup repair rather than rolling the source back; that eats the entire maintenance window.
When Conversions Stall and How to Recover
Some conversions refuse to finish. Common culprits include outdated Converter builds talking to new ESXi releases, volume shadow copy errors on Windows sources, and UEFI partitions that do not survive a resize. Updating Converter to the latest release sorts the first two; UEFI problems often need a manual bootloader fix on the target.
For connection-style errors where the helper VM cannot reach vCenter, work through the fixing ESXi host connection errors playbook — most cases come down to DNS, time skew, or hostd being stuck. If you are on a Telstra or Optus business link and the helper image passes over a flaky VPN, copy installer files locally first to reduce the chance of mid-flight corruption.
| Conversion Mode | Best Use Case | Requires Downtime | Storage Impact |
|---|---|---|---|
| Powered-on (hot clone) | Production servers that cannot be stopped | Minimal, final sync only | Needs steady target I/O |
| Powered-off (cold clone) | Decommissioned hardware, slow links | Full outage during copy | Less I/O contention |
| Volume-based sync | Servers with simple disk layouts | Only at final switch | Best thin/thick control |
| Disk-based clone | Complex partition schemes or UEFI | Full outage during copy | Slower but most faithful |
Conversion checklist essentials
Before scheduling the job:
- ESXi host is on a supported build and reachable by name
- Source backup is verified and restorable
- Datastore has at least 25% free space for snapshots
- Application owners know the final cutover time
After the VM first powers on:
- Re-arm licensing on Windows guests where MAC addresses changed
- Update VMware Tools and confirm network throughput
- Re-add the host to monitoring and backup policies
- Remove the retired machine from Active Directory DNS
When you are ready to take the next step, run a dry-run conversion against an old desktop or retired workstation to feel out the workflow before touching anything production. The free migration path here works for most Windows and Linux workloads found in Australian mid-market estates, and the rest of virtxpert has deeper guides on lab builds and stubborn connection errors. Pull the PowerCLI snippets into your toolkit, put the kettle on, and let the converter do the heavy lifting while you enjoy a proper flat white.