Migrating Physical to Virtual: A Checklist

Context for today. VMware just pushed out vSphere and made thin disks and VMXNET3 feel normal. Microsoft is lining up Hyper V with live migration in the next wave. Citrix turned XenServer free. Your racks are still full of 2U boxes, support contracts are not cheap, and power draw is not cute. Time to move servers to VMs without drama.

Quick chat before we start

Admin: The file server is wheezing. Can we P2V it this week without taking down shares for half a day

Me: Yes, if the disk is not a spaghetti salad of drivers and agents. We will hot clone with VMware Converter or PlateSpin, quiesce with VSS, and switch over with a short DNS dance.

Admin: What about SQL and that old Windows Server 2003 box with a very picky vendor app

Me: SQL can move if we respect IO and VSS. The vendor app might care about MAC or disk ID. We check licensing ties first, then choose hot or cold clone. Worst case we schedule a small window and do a cold capture.

What the numbers and field stories say

Across real shops, a careful physical to virtual migration delivers six to ten to one consolidation for general servers. Power plus cooling drops around thirty to fifty percent per host moved. On vSphere, thin provisioned disks often save another thirty to forty percent of space on day one. A normal hot clone of a mid size Windows server takes about one to three hours, most of that is copying bits over a decent network.

Storage is the lever. If your shared storage is SAN or iSCSI with decent spindles and cache, server consolidation will feel smooth. If your array is already at the edge, moving busy SQL or Exchange to VMs will only shift the bottleneck. Measure before you promise.

The tools are mature. VMware vCenter Converter Standalone works well for hot clone with VSS. PlateSpin handles trickier cases and cold clones. Hyper V guests move fine with SCVMM if you prefer that camp. Linux boxes usually behave, but watch LVM and persistent NIC names.

How I run a P2V step by step

Think of this as a short P2V migration checklist you can paste into your runbook.

Inventory and owners. Name, OS, role, IPs, disks, services, and the human who can say yes to a cutover. Note any app tied to a MAC or dongle or CPU ID.
Backup first. Verified backup from last night, plus a quick extra snapshot or image on the source if policy allows. For domain controllers, do a proper system state backup.
Performance baseline. One week of CPU, memory commit, disk queue, and network throughput. Use perfmon on Windows and sar or iostat on Linux. This tells you right size for vCPU and RAM and prevents guessing.
Pick the platform. ESX or Hyper V or XenServer. Check datastore space. Decide thin or thick virtual disks. With vSphere, thin is usually fine for general servers.
Choose clone method. Hot clone with VSS for most Windows. Cold clone ISO for stubborn boxes or when drivers look cursed. For Linux, prep fstab and boot loader if needed.
Clean the source. Remove vendor NIC teaming, HBA software, array agents, and old monitoring drivers. Disable services that poke hardware. This reduces blue screens on first boot as a VM.
Create the VM shell. Right size vCPU, RAM, and disk. Use VMXNET3 on ESX 4 where possible. Set the correct guest OS type. Place on the right datastore and network.
Partition alignment. Older Windows creates misaligned partitions that waste IO. If you are cloning an old server, plan to realign in a later maintenance window or accept the hit for now. Newer guests are fine.
Run the clone. Quiesce with VSS. Cap transfer rate if your LAN is busy. Keep the VM off after clone until the cutover window.
Cutover dance. Lower DNS TTL to five minutes the day before. Schedule a quiet window. Stop services on the physical box. Boot the VM. Install VMware Tools or Hyper V Integration Services. Assign the same IP and hostname. Test shares, web, and database connections. Then power off the physical box and pull the cable.
Post move hygiene. Check time sync with NTP or Tools. Verify backups now point to the VM. Enable monitoring. Remove stale hidden NICs and rebind protocols if needed. Document what changed.

Special cases worth a line of bold ink:

Domain controllers. Do not snapshot and revert. That risks USN rollback. Keep time tight. One DC per host if you can.
SQL and Exchange. Measure IO and give them good storage. Avoid thin snapshots that grow out of control. Use VSS aware backups.
Old Windows HAL. Windows Server 2003 might need a HAL nudge to ACPI multiprocessor. Converter usually fixes this but verify.

Risks and how to dodge them

Blue screen on first boot. Caused by storage or HAL drivers. Mitigation: remove hardware agents before cloning, prefer cold clone for quirky boxes, keep the physical server ready as a fallback.
Time drift. Kerberos fails if time is off. Mitigation: one time sync source per guest, not both host and guest plus domain at the same time.
Under sized IO. Guests pause and users grumble. Mitigation: baseline IO, avoid piling too many busy disks on the same datastore, consider Storage vMotion to spread load.
License breaks. App tied to MAC or disk signature refuses to run. Mitigation: preserve MAC if your stack allows it or plan vendor reactivation.
Snapshot bloat. Datastore fills overnight. Mitigation: keep snapshots short lived and monitor growth.
Unsupported by vendor. Some apps still say no to VMs. Mitigation: get a statement from the vendor or keep that one physical for now.
Network quirks. Offload features can bite. Mitigation: use VMXNET3 on vSphere and test checksum offload settings if you see odd drops.

A gentle way out

The point of P2V migration is not bragging rights. It is fewer moving parts, faster recovery, and the freedom to move workloads around when you need to. Start with low risk targets like file servers and web front ends. Learn your pattern on your hardware. Then bring in the heavier hitters with storage sized for their appetite.

Keep this short version handy:

Backup check
Baseline performance
Clean drivers and agents
Pick hot or cold clone
Lower DNS TTL
Cut over and test
Turn off the physical box
Post move monitoring and backup

Final thought. Virtualization just got stronger with the latest releases, but the timeless lessons still win the day. Measure first, keep a rollback nearby, and write the plan like someone else will read it at two in the morning.