Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.xloud.tech/llms.txt

Use this file to discover all available pages before exploring further.

​
Overview

After a cold migration completes or a warm migration cuts over, you should validate the migrated workload end-to-end before retiring the source VM. Post-migration validation covers boot, network, storage, guest services, and application-level smoke tests. Only after these checks pass should you decommission the source.
Prerequisites

​
Validation Checklist

Target instance reaches active power state

In the Xloud Dashboard, open Compute → Instances in the target project and confirm the migrated instance shows an active power state. A status of ERROR or BUILD stuck for more than a few minutes indicates a platform-level issue — see Troubleshooting.
Instance is active and the volume is attached.

Boot completed and console is reachable

Open the instance console from the Xloud Dashboard and confirm:
  • The guest reached a login prompt or desktop session
  • No unexpected disk-check prompts or recovery-mode banners
  • Boot loader messages match the expected OS (GRUB for Linux, Windows Boot Manager for Windows)
Guest reaches normal login prompt without dropping to recovery mode.

Network is reachable

Confirm the instance responds on its configured network:
  • Instance has the expected IP addresses assigned
  • Ping or SSH or RDP from an allowed source reaches the instance
  • Guest-level interface count matches the source (every source NIC was mapped)
  • DNS resolution works from inside the guest
You can reach the guest using the connection method used on the source.

Storage is intact

From inside the guest, verify:
  • Every disk from the source is present and mounted
  • Filesystems mount read-write as expected
  • Disk sizes match the source
  • No filesystem errors appear in dmesg or the Windows Event Viewer
All source disks are present, mounted, and report no filesystem errors.

Guest services are running

Log in to the guest and verify the services that run on the source are running on the target:
  • Linux: systemctl list-units --state=running matches the expected set
  • Windows: Services MMC shows the expected services in Running state
  • Application-specific daemons (databases, web servers, custom services) are up and responding
Every service that runs on the source is running on the target.

Application-level smoke test

Run the workload’s application-level health check:
  • Databases: connect and run a trivial query
  • Web apps: load the home page and a backend route
  • Custom services: run the test suite or health endpoint
Application smoke test returns the same result on the target as on the source.

​
Common Post-Migration Symptoms

SymptomLikely CauseFix
Guest boots to recovery mode (Linux)GRUB was pointing at old device namesBoot from recovery, regenerate GRUB config, update initramfs
Windows BSOD on boot (INACCESSIBLE_BOOT_DEVICE)VirtIO storage driver was not loaded at early bootAttach the target volume to a rescue instance and enable the viostor service at boot
Network interface missingGuest tied the interface to a specific MAC or driverRemove the stale interface record (for example, NetworkManager keyfile or udev persistent-net rule) and re-detect
Hostname resolves but services not reachableFirewall inside the guest blocks the new IP rangeUpdate the guest firewall rules to allow the target Xloud network range
High CPU usage at idleLeftover source-side tools (for example, VMware Tools) running in a loopUninstall source-side hypervisor tools from the guest
Clock driftGuest time source is still pointing at source NTPReconfigure the guest time source for the target network
Most post-migration issues are guest-side side effects, not migration failures. The migration writes the source disks faithfully — the guest just needs to re-learn its new environment.

​
Decommissioning the Source

Only after every checklist item passes and the workload owner has confirmed the migrated instance is authoritative should you retire the source VM.
Do not delete the source VM immediately. Keep it powered off for a rollback window (typically 7-30 days depending on your change management policy) before deleting it permanently. If a post-migration issue appears later, the source is still available as a reference.

Confirm validation passed

All checklist items above are green and the workload owner has signed off.

Keep source powered off

Leave the source VM in the VMware inventory, powered off. Do not delete it yet.

Wait out the rollback window

Wait the number of days your change management policy requires. During this window the source remains available as a reference or rollback target.

Delete the source VM

Once the rollback window has elapsed, delete the source VM through vSphere. XMS does not delete source VMs — this is always a manual step by the source environment owner.

​
Next Steps

Troubleshooting

Diagnose boot, network, and guest-level issues after migration

Xloud Compute

Manage the migrated instance lifecycle on Xloud

Infrastructure Monitoring

Add the migrated instance to monitoring and alerting