Migrating a production Linux system from physical to virtual infrastructure without downtime requires careful planning. The key challenge lies in creating an exact replica of the running system while maintaining service availability. Traditional cloning methods like dd or rsync may cause inconsistencies when the source system is live.

Here are three proven methods for hot cloning Linux systems:

1. LVM Snapshots with Rsync

For systems using LVM, create a snapshot volume before syncing:

# Create snapshot (adjust size as needed)
lvcreate -L10G -s -n root_snapshot /dev/vg00/root

# Mount snapshot
mkdir /mnt/snapshot
mount /dev/vg00/root_snapshot /mnt/snapshot

# Rsync to target (run multiple times for delta syncs)
rsync -aAXHv --delete \
      --exclude={"/dev/*","/proc/*","/sys/*","/tmp/*","/run/*","/mnt/*","/media/*","/lost+found"} \
      /mnt/snapshot/ user@newvm:/mnt/target/

2. DRBD for Continuous Replication

DRBD (Distributed Replicated Block Device) provides real-time block-level replication:

# Install DRBD
apt-get install drbd8-utils

# Configure /etc/drbd.d/nvme0n1p2.res
resource nvme0n1p2 {
  protocol C;
  on physical-server {
    device /dev/drbd0;
    disk /dev/nvme0n1p2;
    address 192.168.1.100:7788;
    meta-disk internal;
  }
  on virtual-machine {
    device /dev/drbd0;
    disk /dev/sda1;
    address 192.168.1.101:7788;
    meta-disk internal;
  }
}

# Initialize and start replication
drbdadm create-md nvme0n1p2
drbdadm up nvme0n1p2
drbdadm primary --force nvme0n1p2

3. Btrfs/ZFS Send-Receive

For filesystems supporting snapshots and incremental transfers:

# On source system
btrfs subvolume snapshot -r / /mnt/root_snap
btrfs send /mnt/root_snap | ssh user@newvm "btrfs receive /mnt/target"

# For subsequent incremental transfers
btrfs subvolume snapshot -r / /mnt/root_snap_new
btrfs send -p /mnt/root_snap /mnt/root_snap_new | \
  ssh user@newvm "btrfs receive /mnt/target"

After transferring the system:

• Update /etc/fstab with new device UUIDs
• Reinstall bootloader (GRUB) if needed
• Check and modify network configuration
• Test all services before cutting over

For repeatable migrations, consider this bash script framework:

#!/bin/bash
# Variables
SOURCE_DIR="/"
TARGET_IP="192.168.1.101"
EXCLUDE_LIST=(
  "--exclude=/dev/*"
  "--exclude=/proc/*"
  "--exclude=/sys/*"
  "--exclude=/tmp/*"
)

# Initial sync
rsync -aAXHv "${EXCLUDE_LIST[@]}" --delete \
      $SOURCE_DIR/ root@$TARGET_IP:/mnt/target/

# Subsequent delta syncs can be scheduled
while true; do
  rsync -aAXHv "${EXCLUDE_LIST[@]}" \
        --delete --inplace $SOURCE_DIR/ root@$TARGET_IP:/mnt/target/
  sleep 300
done

Migrating a production Linux system from physical to virtual infrastructure presents unique challenges when downtime isn't an option. The primary concerns include maintaining data consistency, preserving system state, and ensuring service continuity throughout the migration process.

For systems using LVM (Logical Volume Manager), we can create consistent snapshots while the system remains operational:

# Create an LVM snapshot (requires free space in volume group)
lvcreate --size 10G --snapshot --name root_snapshot /dev/vg00/root

# Mount the snapshot for backup
mkdir /mnt/snapshot
mount /dev/vg00/root_snapshot /mnt/snapshot -o ro

For non-LVM systems, rsync with brief filesystem freezes offers a reliable solution:

# Initial sync (can run while system is live)
rsync -aAXv --delete / /mnt/backup --exclude={"/dev/*","/proc/*","/sys/*","/tmp/*","/run/*","/mnt/*","/media/*","/lost+found"}

# Final sync with brief freeze (minimal downtime)
sync
mount -o remount,ro /
rsync -aAXv --delete / /mnt/backup --exclude={"/dev/*","/proc/*","/sys/*","/tmp/*","/run/*","/mnt/*","/media/*","/lost+found"}
mount -o remount,rw /

After capturing the system state, convert it to a virtual machine format. For KVM/QEMU:

# Convert raw image to qcow2 format
qemu-img convert -f raw -O qcow2 /path/to/backup.img /path/to/vm.qcow2

# Create a basic VM definition
virt-install \
  --name production-vm \
  --memory 4096 \
  --vcpus 2 \
  --disk /path/to/vm.qcow2 \
  --import \
  --os-variant detect=on

Before switching over, verify the VM's functionality:

• Check service statuses
• Validate network connectivity
• Test critical application functionality
• Compare file integrity between source and destination

After successful migration:

# Update fstab with new device identifiers
sed -i 's/old_device_uuid/new_device_uuid/g' /etc/fstab

# Reconfigure networking if necessary
nmtui-edit