VMware ESXi to Oracle Linux KVM (OLVM 4.4): Enterprise Production Migration Runbook

Executive Summary & Context

ith shifts in broad hypervisor licensing structures, enterprise IT organizations are accelerating migrations from VMware vSphere/ESXi to Oracle Linux Virtualization Manager (OLVM 4.4). OLVM provides an enterprise-grade KVM management engine natively integrated with Unbreakable Enterprise Kernel (UEK).

However, migrating production workloads—especially those supporting Oracle Database, PeopleSoft, or Ellucian Banner—demands strict sequence discipline. Failing to inject target hypervisor storage and network drivers prior to disk conversion results in unbootable virtual machines and extended maintenance windows.

---

Symptom & Diagnostic Traces

When a VMware virtual machine disk (.vmdk) is converted directly to .qcow2 and launched in OLVM without pre-migration driver modification, the guest fails during kernel initialization:

[   14.209124] dracut-initqueue[412]: Warning: dracut-initqueue timeout - starting timeout scripts
[   14.891002] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)
[   14.891150] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.4.17-2136.307.3.el8uek.x86_64 #2
[   14.891210] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.14.0-2.module+el8.6.0 04/01/2014
[   14.891265] Call Trace:
[   14.891310]  dump_stack+0x66/0x8b
[   14.891350]  panic+0x101/0x2db
[   14.891410]  mount_block_root+0x23f/0x2e8
[   14.891460]  mount_root+0x38/0x3a
[   14.891500]  prepare_namespace+0x13a/0x168

---

Root Cause Analysis

VMware ESXi guests communicate with storage using proprietary virtual storage controllers (pvscsi or mptspi) and network interfaces (vmxnet3).

OLVM (KVM) relies on paravirtualized virtio_blk, virtio_scsi, and virtio_net drivers. If these driver modules are not explicitly included in the guest’s initial RAM file system (initramfs), the kernel cannot initialize the target virtio block device (/dev/vda or /dev/sda) and fails to mount the root filesystem.

---

Environment & Requirements Matrix

Migration Phase	Parameter / Component	Recommended Configuration
Source Environment	VMware ESXi	Version 6.7, 7.0, or 8.0
Target Hypervisor	OLVM Engine & KVM Host	OLVM 4.4 on Oracle Linux 8.x (UEK R6/R7)
Staging Migration Host	Storage / Conversion Node	Dedicated RHEL/OL 8 host with virt-v2v and qemu-img
Guest OS Support	Enterprise Linux	Oracle Linux 7.x/8.x, RHEL 7.x/8.x, CentOS 7.x

---

Step-by-Step Production Migration Runbook

Step 1: Pre-Migration Guest Driver Injection

Before shutting down the guest VM on VMware, connect to the guest via SSH and inject the required VirtIO kernel modules into initramfs.

1. Create a dracut configuration snippet to enforce VirtIO module inclusion:

# Add virtio drivers to dracut configuration
cat << 'EOF' > /etc/dracut.conf.d/virtio.conf
add_drivers+=" virtio_blk virtio_net virtio_pci virtio_scsi "
EOF

2. Rebuild the initramfs image for all installed kernel versions:

# Rebuild initramfs for current kernel
dracut -f -v /boot/initramfs-$(uname -r).img $(uname -r)

# Verify VirtIO modules are compiled into initramfs
lsinitrd /boot/initramfs-$(uname -r).img | grep -E "virtio_blk|virtio_net|virtio_scsi"

Output Verification:

usr/lib/modules/5.4.17-2136.307.3.el8uek.x86_64/kernel/drivers/block/virtio_blk.ko.xz
usr/lib/modules/5.4.17-2136.307.3.el8uek.x86_64/kernel/drivers/net/virtio_net.ko.xz
usr/lib/modules/5.4.17-2136.307.3.el8uek.x86_64/kernel/drivers/scsi/virtio_scsi.ko.xz

3. Gracefully shut down the guest VM on VMware.

---

Step 2: Automated Conversion via virt-v2v or qemu-img

Option A: Direct ESXi Conversion using virt-v2v (Recommended for Large Fleets)

Run virt-v2v from a staging migration host with direct access to ESXi and the OLVM storage domain:

# Export from ESXi directly to OLVM Data Domain
virt-v2v -ic vpx://administrator%40vsphere.local@vcenter.corp.internal/Datacenter/Cluster?no_verify=1 \
  -o rhv-upload \
  -oc https://olvm-engine.corp.internal/ovirt-engine/api \
  -os olvm_data_domain \
  -op /etc/pki/ovirt-engine/ca.pem \
  -of qcow2 \
  -oo rhv-direct \
  -bridge bridge0 \
  vmware-guest-hostname

Option B: Manual VMDK to QCOW2 Conversion

If migrating offline disk images, copy the -flat.vmdk file to the staging host and execute qemu-img:

# Convert VMDK flat image to compressed QCOW2 format
qemu-img convert -p -f vmdk -O qcow2 -o preallocation=metadata \
  /migration/staging/vmware_guest-flat.vmdk \
  /migration/staging/olvm_guest_disk0.qcow2

# Validate disk integrity post-conversion
qemu-img info /migration/staging/olvm_guest_disk0.qcow2

---

Step 3: OLVM KVM Host Kernel & Memory Optimization

To ensure predictable performance for database and ERP workloads running under OLVM, tune the KVM host OS parameters:

1. Disable Transparent Huge Pages (THP) on OLVM hypervisor nodes:

# Add transparent_hugepage=never to GRUB boot parameter
grubby --update-kernel=ALL --args="transparent_hugepage=never"

2. Configure Kernel Swappiness to prevent premature host swapping:

# Add parameter to sysctl
echo 'vm.swappiness=10' >> /etc/sysctl.d/99-olvm-kvm.conf
sysctl -p /etc/sysctl.d/99-olvm-kvm.conf

---

Verification & Post-Migration Checklists

Post-Migration Boot Verification

1. Attach converted QCOW2 disk to new VM template in OLVM Web Admin interface.
2. Set Interface Type to VirtIO for network and VirtIO-SCSI for storage controller.
3. Power on VM and monitor serial console output:

# Verify kernel boots cleanly into UEK
uname -a
lsmod | grep virtio

Automated Post-Migration Verification Script

Save and run this diagnostic check inside the newly migrated VM to ensure complete hypervisor transition:

#!/bin/bash
# OLVM Migration Health Check

echo "[+] Checking Hypervisor Context..."
hypervisor=$(systemd-detect-virt)
echo "    Hypervisor: $hypervisor"

echo "[+] Checking Active VirtIO Drivers..."
for driver in virtio_blk virtio_net virtio_scsi virtio_pci; do
    if lsmod | grep -q "$driver"; then
        echo "    [PASS] $driver loaded."
    else
        echo "    [FAIL] $driver NOT loaded!"
    fi
done

echo "[+] Verifying Network Link State..."
ip link show | grep -E "eth|ens|enp"

---

Troubleshooting Edge Cases

Issue: Network Interface Rename (ens3 vs eth0)

• Symptom: VM boots cleanly but has no IP address. Network adapter name changed due to systemd predictible interface naming rules under KVM device paths.
• Fix: Update /etc/sysconfig/network-scripts/ifcfg-<interface> with the new MAC address and device name, or pass net.ifnames=0 biosdevname=0 in kernel parameters to retain legacy ethX naming.

---

📚 Official Documentation & Technical References

• Oracle Linux Virtualization Manager 4.4 Documentation — Official Oracle Documentation
• Oracle Linux: KVM User’s Guide — Official Oracle Documentation
• ORACLE-BASE: KVM on Oracle Linux — Tim Hall (ORACLE-BASE)

---

Next Steps & Advisory

Planning a enterprise virtualization migration from VMware to Oracle Linux KVM?

• Download our free Enterprise Infrastructure Migration Checklist.
• Learn more about our Async Health & Infrastructure Performance Audits to ensure seamless migration of your critical Oracle Database and ERP workloads.