Migrating Enterprise Virtual Machines from Oracle VM (OVM 3.3.x/3.4.x) to Oracle Linux Virtualization Manager (OLVM 4.4 KVM)

Introduction: The Oracle VM End-of-Support Imperative

With Oracle VM (OVM 3.3.x and 3.4.x) reaching End of Premier Support, enterprise IT teams managing Oracle Database, PeopleSoft, and Ellucian Banner workloads must migrate virtual machines to Oracle Linux Virtualization Manager (OLVM 4.4 KVM).

Because OVM relies on the legacy Xen hypervisor architecture while OLVM utilizes KVM (Kernel-based Virtual Machine), migrating VMs requires disk format conversion and guest kernel driver updates.

5-Step Technical Migration Workflow

Step 1: Pre-Inject Virtio Drivers in the Guest OS (Before Shutdown)

If a Xen guest VM is migrated to KVM without virtio kernel drivers, the Linux kernel will fail to mount the root filesystem upon boot (Kernel Panic: Unable to mount root fs).

Run the following command inside the active OVM guest VM prior to migration:

# 1. Update initramfs to include virtio-scsi and virtio-net drivers
dracut --force --add-drivers "virtio virtio_pci virtio_blk virtio_scsi virtio_net" /boot/initramfs-$(uname -r).img $(uname -r)

# 2. Update /etc/fstab to use UUIDs instead of Xen device names (/dev/xvda1 -> UUID=...)
blkid
# Ensure all mounts in /etc/fstab use UUID=xxxx-xxxx notation

Step 2: Gracefully Shut Down OVM Guest & Locate Raw Storage

1. Shut down the virtual machine gracefully via OVM Manager or CLI (xm shutdown <VM_Name> or virsh shutdown <VM_Name>).
2. Locate the raw virtual disk file on your OVM Repository storage mount:

# Path to OVM Repository virtual disk
/OVS/Repositories/<Repository_UUID>/VirtualDisks/<Disk_UUID>.raw

Step 3: Convert Xen Disk Image to QCOW2 Format

Copy or stream the raw disk file from the OVM Dom0 host or storage array to an intermediate migration staging server, then convert it using qemu-img:

# Convert raw OVM Xen disk to compressed QCOW2 for OLVM 4.4
qemu-img convert -f raw -O qcow2 \
  /OVS/Repositories/0004fb0000030000/VirtualDisks/0004fb0000120000.raw \
  /u01/staging/peoplesoft_app01_disk1.qcow2 -p

# Validate converted disk image integrity
qemu-img check /u01/staging/peoplesoft_app01_disk1.qcow2

Step 4: Import Disk Volume into OLVM 4.4 Engine

Upload the converted .qcow2 volume into your target OLVM Storage Domain using ovirt-img-upload or the OLVM Web Console:

# Upload disk image into OLVM Storage Domain via CLI
ovirt-img upload \
  --engine-url=https://olvm-engine.internal.university.edu/ovirt-engine/api \
  --username=admin@internal \
  --sd-name="OLVM_PROD_FC_STORAGE" \
  --disk-format=qcow2 \
  --disk-name="peoplesoft_app01_disk1" \
  /u01/staging/peoplesoft_app01_disk1.qcow2

Step 5: Create VM in OLVM & Verify Boot Performance

1. In OLVM Web Console, create a new Virtual Machine matching the vCPU and RAM profile of the source OVM instance.
2. Attach the uploaded disk using the virtio-scsi disk interface.
3. Attach network interface using virtio vNIC profile.
4. Power on the VM and verify boot sequence:

# Verify active virtio storage driver in guest kernel
lsmod | grep virtio
# Output should display virtio_scsi, virtio_pci, and virtio_net

🔍 Check Your Environment Now (Diagnostic CTA)

Run this diagnostic shell script on your legacy OVM 3.3.x / 3.4.x Dom0 host right now to inventory all active Xen virtual machines, repository paths, and disk formats before planning your migration:

# Diagnostic Script: Inventory OVM 3.3.x Repository VMs & Disks
echo "=== Oracle VM (OVM) Virtual Machine Inventory ==="
for vm in $(ovs-agent-cli get_vms); do
  echo "VM Name: $vm"
  xenstore-ls /local/domain | grep -E "name|target"
done

echo ""
echo "=== OVM Repository Storage Mounts ==="
df -h | grep /OVS/Repositories

Next Steps:

Need expert assistance converting legacy Oracle VM 3.3.x environments to OLVM 4.4 KVM without downtime? Download our Migration Runbook & Automation Package or Schedule an Async Virtualization Audit.