Automated Migration of Oracle VM 3.4 Storage Repositories to OLVM Fiber Channel LUNs

1. Executive Summary

Oracle VM 3.4 reached end-of-life in 2021, and Oracle Linux Virtualization Manager (OLVM) is the designated enterprise successor. The storage architectures of these two platforms are fundamentally incompatible at the filesystem and management layers. Oracle VM 3.4 Storage Repositories (SRs) on Fiber Channel (FC) LUNs are formatted with OCFS2 — a clustered filesystem managed by the OVM Manager and OCFS2 tools. OLVM, built on the oVirt/RHEV 4.x codebase, uses VDSM-managed storage domains where FC LUNs are wrapped in LVM volume groups and formatted with ext4 or XFS.

Attempting an in-place upgrade or a naive file-level copy will fail because:

• OCFS2 metadata and locking semantics are not understood by OLVM’s VDSM.
• OLVM storage domains require a specific directory structure (/rhev/data-center/<sd-uuid>/...) with VDSM-managed metadata.
• VM disk images in OVM 3.4 are raw .img files; OLVM expects logical volumes (thick or thin) managed by VDSM.

This guide provides a production-tested, automated migration methodology that moves VM disk data from OVM 3.4 OCFS2 SRs to OLVM FC storage domains with zero data loss and minimal downtime. The approach uses a phased replication strategy with LVM snapshot consistency, rsync-based data transfer, and rigorous post-migration validation.

2. Migration Process Flow

---

3. Diagnostic Checklist

Run the following commands before beginning any migration activity. Capture all output for the migration record.

3.1 Source OVM 3.4 — SR and VM Inventory

# List all storage repositories
ovmcli list storageRepositories

# Show detailed SR information (filesystem type, LUN mapping, health)
ovmcli show storageRepository id=<sr_id>

# List all VMs and their associated SRs
ovmcli list vms

# Show VM disk configuration
ovmcli show vm id=<vm_id> | grep -E "disk|storage|virtual"

# Check OCFS2 mount status and usage
mount | grep ocfs2
df -h /OVS/<sr_mount_point>

# Verify OCFS2 filesystem health
fsck.ocfs2 -n /dev/mapper/<multipath_device>

# Check multipath configuration
multipath -ll

# Verify FC HBA connectivity
lsscsi | grep -i fibre
cat /sys/class/fc_host/host*/port_name

3.2 FC SAN — LUN Zoning and Visibility

# On each OLVM host, verify FC HBA presence
lspci | grep -i fibre

# Rescan FC buses to discover newly zoned LUNs
for host in /sys/class/fc_host/host*; do
  echo 1 > "$host/issue_lip"
done
sleep 5
rescan-scsi-bus.sh --all

# Verify new LUNs are visible
lsscsi --scsi | grep -i "disk"

# Check multipath aggregation
multipath -ll | grep -A 4 "mpath"

# Verify LUN size matches expected
fdisk -l /dev/mapper/<mpath_device>

3.3 Target OLVM — Storage Domain Readiness

# Check VDSM service status on all OLVM hosts
systemctl status vdsmd

# List existing storage domains
vdsm-client StorageDomain getInfo

# Verify FC LUNs are visible to VDSM
vdsm-client Host getStorageDomains

# Check storage domain health
vdsm-client StorageDomain getInfo --storageDomainID=<sd_id>

# Verify multipath on OLVM hosts
multipath -ll

# Check LVM configuration
pvs
vgs
lvs

3.4 Data Integrity Baseline

# Generate SHA-256 checksums for all VM disk images on source SR
find /OVS/<sr_mount_point> -name "*.img" -type f -exec sha256sum {} \; > /tmp/source_checksums.txt

# Record block-level device sizes for cross-validation
for img in $(find /OVS/<sr_mount_point> -name "*.img" -type f); do
  echo "$img: $(stat -c %s $img) bytes"
done > /tmp/source_sizes.txt

# Verify OCFS2 journal is clean
debugfs.ocfs2 -R "stat /" /dev/mapper/<multipath_device>

3.5 Pre-Flight Validation

Check	Command	Expected Result
SR health	ovmcli show storageRepository id=<sr_id>	Status: ONLINE
OCFS2 mount	mount | grep ocfs2	SR mounted read-write
Multipath	multipath -ll	All paths active, no failed paths
FC connectivity	lsscsi | grep -i fibre	All HBAs present
OLVM VDSM	systemctl status vdsmd	active (running)
Storage domain	vdsm-client StorageDomain getInfo	Status: ACTIVE
Disk space	df -h /OVS/<sr_mount_point>	≥ 20% free space
LUN size match	fdisk -l /dev/mapper/<mpath>	Matches expected size

---

4. Step-by-Step Resolution Runbook

Step 0: Safety Checks (Mandatory)

⚠️ CRITICAL — Read before proceeding.

1. Backup Verification: Confirm that a full, restorable backup of all VMs exists. Test a restore on a non-production VM. Document the backup location and restore procedure.
2. Maintenance Window: Schedule a maintenance window that accommodates the full migration plus a 2-hour buffer for rollback. Typical migration time: 4–8 hours for 10–20 VMs.
3. Rollback Plan: Document the rollback procedure. The source OVM 3.4 environment must remain untouched and bootable until Step 6 validation passes.
4. Change Management: Obtain all required change approvals. Record the change ticket number in the migration log.
5. Communication Plan: Notify all stakeholders (application owners, DBAs, network team, storage team) of the maintenance window and expected downtime.
6. Environment Freeze: Freeze all VM creation, deletion, and configuration changes on the OVM 3.4 environment during migration.
7. Verify Credentials: Ensure you have root access to OVM Manager, OVM servers, OLVM Manager, and OLVM hosts. Verify SSH key-based authentication is configured between all systems.
8. Storage Team Coordination: Confirm the storage team has zoned the new FC LUNs to OLVM hosts and that LUN masking is correct.

---

Step 1: Inventory and Dependency Mapping

Goal: Build a complete inventory of VMs, SRs, LUNs, and dependencies.

# On OVM Manager
ovmcli list storageRepositories
ovmcli list vms

# For each VM, capture configuration
for vm_id in $(ovmcli list vms | grep -oP 'id=\K[0-9a-f-]+'); do
  ovmcli show vm id=$vm_id > /tmp/vm_${vm_id}.txt
done

# Capture SR-to-LUN mapping
for sr_id in $(ovmcli list storageRepositories | grep -oP 'id=\K[0-9a-f-]+'); do
  ovmcli show storageRepository id=$sr_id > /tmp/sr_${sr_id}.txt
done

Create a migration spreadsheet with the following columns:

VM Name	VM UUID	Source SR	Source LUN	Disk Size	OS Type	vCPU	RAM	Network	Target OLVM Cluster	Target Storage Domain
dbprod01	a1b2...	SR_FC_01	LUN_001	200 GB	Linux	8	32 GB	VLAN_10	OLVM_Cluster_A	SD_FC_01
appweb02	c3d4...	SR_FC_01	LUN_001	80 GB	Linux	4	16 GB	VLAN_20	OLVM_Cluster_A	SD_FC_01

Dependency mapping: Identify VMs that communicate with each other. Group them for migration in the same batch to minimize cross-platform network latency during cutover.

---

Step 2: FC SAN Zoning and LUN Presentation

Goal: Present new FC LUNs to all OLVM hosts in the target cluster.

2.1 — Storage Team Actions:

• Create new LUNs on the FC SAN array (size = source SR usage + 20% headroom).
• Zone the new LUNs to all OLVM host WWPNs.
• Mask the LUNs appropriately (do not present to OVM 3.4 servers).

2.2 — OLVM Host FC Rescan:

# On each OLVM host
for host in /sys/class/fc_host/host*; do
  echo 1 > "$host/issue_lip"
done
sleep 10

# Rescan SCSI buses
rescan-scsi-bus.sh --all

# Verify LUN visibility
lsscsi --scsi | grep -i disk

# Check multipath
multipath -ll

2.3 — Multipath Configuration:

Ensure /etc/multipath.conf on OLVM hosts includes the correct wwid for the new LUNs:

# Get the WWID
/usr/lib/udev/scsi_id -g -u -d /dev/sdX

# Add to multipath.conf
cat >> /etc/multipath.conf << 'EOF'
multipaths {
    multipath {
        wwid "3600a09803830304434244c704c4e4a4f"
        alias mpath_olvm_sd01
        path_grouping_policy multibus
        failback immediate
    }
}
EOF

# Reload multipath
systemctl reload multipathd
multipath -ll

2.4 — Verify LUN Consistency Across All OLVM Hosts:

# On each host, verify the same LUN WWID is visible
multipath -ll | grep -E "mpath|wwid"

# Compare outputs across hosts — they must match

---

Step 3: OLVM Storage Domain Creation

Goal: Create a VDSM-managed storage domain on the new FC LUNs.

3.1 — Via OLVM Admin Portal (GUI):

1. Navigate to Storage → Domains → New.
2. Select Data domain type.
3. Storage type: Fibre Channel.
4. Select the new LUN(s) from the discovered list.
5. Name the domain (e.g., SD_FC_01).
6. Set format: V4 (default for OLVM 4.x).
7. Click OK to create.

3.2 — Via REST API (Automated):

# Authenticate to OLVM API
curl -X POST https://<olvm-manager>/ovirt-engine/api \
  -H "Content-Type: application/xml" \
  -u admin@internal:password \
  -d '<action><login/></action>'

# Create storage domain
curl -X POST https://<olvm-manager>/ovirt-engine/api/storagedomains \
  -H "Content-Type: application/xml" \
  -u admin@internal:password \
  -d '<storage_domain>
        <name>SD_FC_01</name>
        <type>data</type>
        <storage>
          <type>fcp</type>
          <logical_units>
            <logical_unit id="3600a09803830304434244c704c4e4a4f"/>
          </logical_units>
        </storage>
      </storage_domain>'

3.3 — Verify Storage Domain Health:

# On OLVM host
vdsm-client StorageDomain getInfo --storageDomainID=<sd_id>

# Expected output:
# status: ACTIVE
# type: data
# version: 4
# available: <size>
# used: <size>

3.4 — Attach Storage Domain to Data Center and Cluster:

# Attach to data center
curl -X POST https://<olvm-manager>/ovirt-engine/api/datacenters/<dc_id>/storagedomains \
  -H "Content-Type: application/xml" \
  -u admin@internal:password \
  -d '<storage_domain id="<sd_id>"/>'

# Activate the storage domain
curl -X POST https://<olvm-manager>/ovirt-engine/api/storagedomains/<sd_id>/activate \
  -H "Content-Type: application/xml" \
  -u admin@internal:password \
  -d '<action/>'

---

Step 4: LVM Snapshot and Data Replication

Goal: Create a consistent snapshot of the OCFS2 SR and replicate VM disk images to the OLVM storage domain.

⚠️ CRITICAL: The OCFS2 SR must be quiesced before snapshot. Coordinate with application owners to ensure database consistency (e.g., Oracle ALTER TABLESPACE ... BEGIN BACKUP or sqlplus shutdown).

4.1 — Quiesce the SR:

# On OVM server — put SR in maintenance mode
ovmcli set storageRepository id=<sr_id> --maintenance

# Or, if using OCFS2 tools
ocfs2_hb_ctl -u /dev/mapper/<mpath_device>

4.2 — Create LVM Snapshot (if SR is on LVM):

# Check if SR LUN is managed by LVM
pvs | grep <mpath_device>

# Create snapshot (size = 10% of LV size)
lvcreate -L 20G -s -n sr_snapshot /dev/<vg_name>/<lv_name>

# Mount snapshot read-only
mkdir -p /mnt/sr_snapshot
mount -o ro /dev/<vg_name>/sr_snapshot /mnt/sr_snapshot

4.3 — If SR is a Raw LUN (no LVM):

Use dd for block-level copy or mount OCFS2 read-only directly:

# Mount OCFS2 read-only
mount -o ro -t ocfs2 /dev/mapper/<mpath_device> /mnt/sr_ro

4.4 — Replicate VM Disk Images:

# On OLVM host, create a staging directory in the storage domain
mkdir -p /rhev/data-center/<sd_uuid>/images/staging

# Rsync VM disk images from OVM SR to OLVM storage domain
# Use --sparse to preserve sparseness, --partial for resumability
rsync -av --sparse --partial --progress \
  /mnt/sr_snapshot/OVS/<sr_name>/ \
  /rhev/data-center/<sd_uuid>/images/staging/

# Verify checksums after rsync
cd /mnt/sr_snapshot/OVS/<sr_name>/
find . -name "*.img" -exec sha256sum {} \; > /tmp/source_checksums.txt

cd /rhev/data-center/<sd_uuid>/images/staging/
sha256sum -c /tmp/source_checksums.txt

4.5 — Create OLVM VM Disks and Copy Data:

For each VM, create a disk in OLVM and copy the raw image data:

# Create VM in OLVM (via API)
curl -X POST https://<olvm-manager>/ovirt-engine/api/vms \
  -H "Content-Type: application/xml" \
  -u admin@internal:password \
  -d '<vm>
        <name>dbprod01</name>
        <cluster><name>OLVM_Cluster_A</name></cluster>
        <memory>34359738368</memory>
        <cpu><architecture>x86_64</architecture></cpu>
        <os><type>rhel_7_64</type></os>
      </vm>'

# Create disk
curl -X POST https://<olvm-manager>/ovirt-engine/api/vms/<vm_id>/disks \
  -H "Content-Type: application/xml" \
  -u admin@internal:password \
  -d '<disk>
        <name>dbprod01_disk1</name>
        <size>214748364800</size>
        <format>raw</format>
        <storage_domains><storage_domain><name>SD_FC_01</name></storage_domain></storage_domains>
      </disk>'

# Locate the disk volume on the OLVM host
# Disks are stored as logical volumes: /dev/<vg_name>/<sd_uuid>_<disk_id>
ls -la /dev/mapper/*<disk_id>*

# Copy raw data from source to the OLVM disk volume
dd if=/mnt/sr_snapshot/OVS/<sr_name>/<vm_disk>.img \
   of=/dev/mapper/<vg_name>-<sd_uuid>_<disk_id> \
   bs=4M conv=sparse status=progress

# Verify block-level checksum
sha256sum /mnt/sr_snapshot/OVS/<sr_name>/<vm_disk>.img
sha256sum /dev/mapper/<vg_name>-<sd_uuid>_<disk_id>

---

Step 5: VM Re-registration in OLVM

Goal: Register VMs in OLVM with correct configuration and boot parameters.

5.1 — Configure VM Hardware:

# Set vCPU count
curl -X PUT https://<olvm-manager>/ovirt-engine/api/vms/<vm_id> \
  -H "Content-Type: application/xml" \
  -u admin@internal:password \
  -d '<vm><cpu><topology><sockets>2</sockets><cores>4</cores><threads>1</threads></topology></cpu></vm>'

# Attach network interface
curl -X POST https://<olvm-manager>/ovirt-engine/api/vms/<vm_id>/nics \
  -H "Content-Type: application/xml" \
  -u admin@internal:password \
  -d '<nic>
        <name>eth0</name>
        <interface>virtio</interface>
        <vnic_profile><name>VLAN_10</name></vnic_profile>
      </nic>'

# Attach the replicated disk
curl -X POST https://<olvm-manager>/ovirt-engine/api/vms/<vm_id>/disks \
  -H "Content-Type: application/xml" \
  -u admin@internal:password \
  -d '<disk id="<disk_id>"/>'

5.2 — Configure Boot Parameters:

# Set boot device to disk
curl -X PUT https://<olvm-manager>/ovirt-engine/api/vms/<vm_id> \
  -H "Content-Type: application/xml" \
  -u admin@internal:password \
  -d '<vm>
        <os>
          <type>rhel_7_64</type>
          <boot><devices><device>hd</device></devices></boot>
        </os>
      </vm>'

5.3 — For Linux VMs, Update fstab and Grub:

If the VM’s root device name changed (e.g., from /dev/xvda to /dev/vda), update the VM’s boot configuration:

# Mount the replicated disk on a temporary location
# (Use kpartx or guestmount to access the disk image)

# Using guestfish (from libguestfs)
guestfish --rw -a /dev/mapper/<vg_name>-<sd_uuid>_<disk_id> << 'EOF'
  run
  mount /dev/vda1 /
  write /etc/fstab "UUID=<new_uuid> / ext4 defaults 1 1"
  command "grub2-mkconfig -o /boot/grub2/grub.cfg"
  umount /
EOF

---

Step 6: Post-Migration Validation

Goal: Verify data integrity, boot VMs, and confirm application functionality.

6.1 — Block-Level Integrity Verification:

# Compare source and target checksums
echo "Source checksums:"
cat /tmp/source_checksums.txt

echo "Target checksums:"
sha256sum /dev/mapper/<vg_name>-<sd_uuid>_<disk_id>

# Verify disk sizes match
stat -c %s /mnt/sr_snapshot/OVS/<sr_name>/<vm_disk>.img
blockdev --getsize64 /dev/mapper/<vg_name>-<sd_uuid>_<disk_id>

6.2 — Boot Test:

# Start the VM in OLVM
curl -X POST https://<olvm-manager>/ovirt-engine/api/vms/<vm_id>/start \
  -H "Content-Type: application/xml" \
  -u admin@internal:password \
  -d '<action/>'

# Check VM status
curl -X GET https://<olvm-manager>/ovirt-engine/api/vms/<vm_id> \
  -H "Accept: application/xml" \
  -u admin@internal:password | grep -E "status|state"

# Wait for VM to boot (2-5 minutes)
sleep 120

# Verify VM is running
curl -X GET https://<olvm-manager>/ovirt-engine/api/vms/<vm_id> \
  -H "Accept: application/xml" \
  -u admin@internal:password | grep "<status>"

6.3 — Application-Level Validation:

# SSH to the VM (if network is configured)
ssh user@<vm_ip> "hostname && uptime && df -h"

# For Oracle databases, verify instance is up
ssh oracle@<vm_ip> "sqlplus / as sysdba <<< 'SELECT status FROM v\$instance;'"

# Check application logs
ssh user@<vm_ip> "tail -50 /var/log/messages"
ssh user@<vm_ip> "tail -50 /var/log/application.log"

6.4 — Performance Validation:

# Run I/O benchmark on the VM
ssh user@<vm_ip> "dd if=/dev/zero of=/tmp/testfile bs=1M count=1024 conv=fdatasync"

# Verify network throughput
ssh user@<vm_ip> "iperf3 -c <target_host> -t 30"

---

Step 7: Cutover and Decommissioning

Goal: Finalize migration, shut down source VMs, and decommission OVM 3.4 SRs.

7.1 — Final Incremental Sync:

# Shut down VMs on OVM 3.4
ovmcli stop vm id=<vm_id>

# Perform final rsync of any changed data
rsync -av --sparse --partial \
  /mnt/sr_snapshot/OVS/<sr_name>/ \
  /rhev/data-center/<sd_uuid>/images/staging/

# Final checksum verification
sha256sum -c /tmp/source_checksums.txt

7.2 — Start VMs on OLVM:

# Start all migrated VMs
for vm_id in $(cat /tmp/migrated_vms.txt); do
  curl -X POST https://<olvm-manager>/ovirt-engine/api/vms/$vm_id/start \
    -H "Content-Type: application/xml" \
    -u admin@internal:password \
    -d '<action/>'
done

7.3 — Decommission Source SRs:

# On OVM Manager — remove VMs from inventory
ovmcli delete vm id=<vm_id>

# Remove SR from OVM Manager
ovmcli delete storageRepository id=<sr_id>

# On OVM server — unmount OCFS2
umount /OVS/<sr_mount_point>

# Remove LVM snapshot
lvremove -f /dev/<vg_name>/sr_snapshot

# Coordinate with storage team to decommission source LUNs

7.4 — Post-Decommission Verification:

# Verify no VMs remain on OVM 3.4
ovmcli list vms

# Verify OLVM storage domain is healthy
vdsm-client StorageDomain getInfo --storageDomainID=<sd_id>

# Verify all VMs are running on OLVM
curl -X GET https://<olvm-manager>/ovirt-engine/api/vms \
  -H "Accept: application/xml" \
  -u admin@internal:password | grep -E "<name>|<status>"

---

5. Troubleshooting Common Errors

Symptom	Root Cause	Resolution
SR shows as OFFLINE	OCFS2 mount failure or LUN connectivity loss	Verify FC connectivity, check multipath, remount OCFS2
Storage domain fails to activate	LUN not properly formatted or VDSM metadata corruption	Recreate storage domain, verify LUN is clean
VM import fails in OLVM	Disk format mismatch or missing disk attachment	Verify disk is raw format, re-attach disk
I/O errors during rsync	Path failure or multipath misconfiguration	Check multipath -ll, verify all paths active
Checksum mismatch after copy	Inconsistent source snapshot or I/O error during copy	Re-run rsync, verify source snapshot consistency

---

📚 Official Documentation & Technical References

Oracle Documentation

• Oracle Linux Virtualization Manager 4.x Documentation
• Oracle VM 3.4 Storage Repository Guide
• OLVM Administration Guide - Storage

Related Resources

• Oracle Linux Virtualization Manager 4.4 Release Notes
• How to Migrate Oracle VM to Oracle Linux KVM
• OVIRT REST API Package
• oVirt Administration Guide - Storage

---

7. Need Expert Assistance?

Migrating from Oracle VM 3.4 to OLVM is a complex, high-risk operation that requires deep expertise in both platforms. DBPros.Net’s certified virtualization and database engineers have executed dozens of successful OVM-to-OLVM migrations for enterprise customers across financial services, healthcare, and government sectors.

Our migration services include:

• Full migration assessment — inventory, dependency mapping, risk analysis
• Automated migration tooling — scripted replication and validation
• Oracle Database optimization — post-migration performance tuning for Oracle workloads
• 24/7 migration support — on-call engineers during cutover windows
• Rollback planning — comprehensive rollback strategies to eliminate risk

Contact DBPros.Net Today for a free consultation and migration readiness assessment.

Explore Our Services — Oracle Database Administration, Virtualization Migration, and 24/7 Enterprise Support.

---

This article was authored by the Enterprise Database & Systems Engineering team at DBPros.Net. Last updated: August 2026.