Troubleshooting VMware vSphere Replication stuck at queued state

When a VMware vSphere Replication job remains at Queued state, the appliance has accepted the request but has not advanced it into the transfer phase. The status does not identify the broken dependency; it may be a disconnected vCenter Server, unresolved hostname, failed certificate trust check, unavailable target datastore, appliance service fault, or virtual machine that cannot satisfy the selected replication method.

This guide follows a dependency-first path for practical troubleshooting. It also reflects Australian operational conditions, where replication may cross long links between Sydney, Melbourne, Brisbane or Perth rather than sit inside one compact data centre.

Separate the workflow state from the root cause

vSphere Replication separates configuration from transfer. A replication session describes the source and target, while a job records the attempt to copy a particular VM and its disks. Queued means that job is pending before useful transfer begins, although exact labels differ slightly between appliance releases and the vCenter interface. If the session uses a schedule, confirm the job is waiting for its configured window rather than stalled.

First establish whether the problem affects one VM, every VM in a session, or all sessions targeting the same remote vCenter. That scope separates a VM-specific problem from a broken replication pair. A broad failure points towards appliance health, vCenter connectivity, DNS, trust, routing or shared storage; a single failure points towards power state, snapshots, disk configuration or source host access.

Capture evidence before changing the appliance

Record the job ID, vCenter and appliance versions, source and target vCenter addresses, ESXi hosts, source and target datastores, VM power state, and exact timestamps. Compare vCenter Tasks and Events with the replication appliance error logs and relevant ESXi host logs. Capture screenshots before restarting services because a restart can erase the timing needed to explain the stall.

Keep timestamps in UTC while noting Australian Eastern and Central time zones, including daylight-saving changes; teams that hand work across the states need a shared clock to compare vCenter tasks with WAN events. Archive a support bundle according to your change process. Architecture notes such as the VMware replication background can distinguish an expected appliance workflow state from an upstream failure, but they should not replace version-specific diagnostics.

Validate naming, trust and network paths

Use the same fully qualified names for the source vCenter Server, target vCenter Server, vSphere Replication appliances, and ESXi hosts wherever those systems communicate. Test forward and reverse DNS from the relevant source and destination networks. Check that appliance and vCenter certificates have not expired, that their trust chains are intact, and that clock synchronisation through NTP is working; name or certificate errors often appear as a pending job rather than a clear network error.

Validate routing, proxies, firewalls and the HTTPS path on TCP 443 required by the installed vSphere Replication release, along with any source or target storage protocols such as NFS or iSCSI. Test from a network context permitted by security policy rather than opening unrestricted access. Use Test-NetConnection on Windows or nc -vz on a Linux host when useful, but remember that appliance-specific policy, NAT and asymmetric routing can still differ.

Across the Australian market, hybrid estates often combine VMware sites with hyperscale regions, and a managed-service provider may control only part of the path. Confirm ownership of each firewall, DNS zone and certificate before changing it. Long-haul Australian WAN links may also expose MTU, packet-loss and bandwidth-cap problems that local testing misses.

Check storage and virtual machine readiness

Confirm that the target datastore is visible to the target vCenter and its ESXi hosts, is writable, and has enough free space for the VM disks plus replication overhead. Verify source datastore accessibility, thin or eager-zero allocation assumptions, and whether source disks are healthy. Also check that a host migration, storage migration, backup operation or snapshot task has not left the VM or its disks temporarily unavailable.

For the selected cold or online workflow, validate guest and hardware compatibility. Online copies can depend on VMware Tools quiescence, while active snapshot chains or a concurrent backup can hold resources needed to create the replication point. Review unsupported combinations such as raw-device mappings, independent disks, encrypted virtual disks or unusual controllers against the release interoperability matrix. If only one VM is stuck, a controlled comparison with a small test VM often reveals whether the issue belongs to the workload or the replication pair.

Recover safely and establish operating guardrails

Correct one failed dependency at a time: restore DNS, replace an expired certificate, re-establish vCenter connectivity, free datastore capacity, or clear the conflicting VM operation. Then cancel and retry the affected job using the appliance workflow. Do not repeatedly delete replication sessions or rebuild the appliance database before collecting evidence and confirming the service itself is unhealthy. If the appliance remains unhealthy, use the restart and recovery sequence documented for that exact release, then escalate with the support bundle and job IDs.

• Rehearse failover and queued-job recovery with a disposable test VM in each replication session.
• Automate DNS, NTP, certificate-expiry and vCenter-connectivity checks across both sites.
• Alert on datastore free space, snapshot age, appliance health and time spent in queued states.
• Document bandwidth limits, replication windows, backup exclusions and approved restart procedures.

If a workload contains personal information, changing a replication destination can create a new disclosure path and must be checked against the Privacy Act 1988 and Australian Privacy Principles before rerouting. Government and critical-infrastructure operators may also need evidence handling aligned with ASD Essential Eight and the Protective Security Policy Framework. Keeping recovery reversible and fully logged supports operational continuity and defensible governance.