Overview

This guide covers migrating workloads from Microsoft Hyper-V or KVM environments into Oracle Cloud VMware Solution (OCVS).

Although less common than VMware-to-VMware migrations, this path enables infrastructure standardization under a single VMware SDDC on OCI.

This migration requires cross-hypervisor conversion tools to transform disk formats, adjust virtual hardware mappings, and reconstruct workloads reliably inside vSphere.

Introduction

Oracle Cloud Infrastructure (OCI) provides global-scale infrastructure services designed for enterprise-grade workloads.

Oracle Cloud VMware Solution (OCVS) preserves the full VMware software-defined datacenter stack:

• vSphere
• vSAN
• NSX
• vCenter

Migrating Hyper-V or KVM workloads to OCVS allows organizations to:

• Standardize heterogeneous estates
• Consolidate multiple hypervisors
• Align operational tooling
• Reduce platform complexity

This is not a lift-and-shift — it is a cross-hypervisor transformation.

Target Platform: Oracle Cloud VMware Solution (OCVS)

Key Characteristics:

• Hypervisor: VMware ESXi
• Management: vCenter, NSX, HCX, vSAN
• Networking: NSX
• Storage: vSAN or OCI Block Storage
• Best Use Case: VMware standardization and consolidation

Migration Tooling

VMware HCX Enterprise – OS-Assisted Migration (OSAM)

OS-Assisted Migration (OSAM) enables guest-level migration from non-vSphere hypervisors (Hyper-V, KVM) into OCVS.

Unlike vMotion or Bulk Migration, OSAM:

• Installs a migration agent inside the guest OS
• Replicates disk and configuration data
• Reconstructs the VM inside vSphere
• Performs hardware mapping adjustments

OSAM requires HCX Enterprise licensing.

How OSAM Works

1. Guest-level agent installed
2. Full disk replication initiated
3. Continuous delta synchronization maintained
4. Final switchover scheduled
5. Hardware mapping adjustments performed
6. VMware Tools installed
7. VM reboot completes migration

The source VM remains online during replication until the final delta synchronization.

OSAM Considerations

• Full sync begins immediately; delta maintained until cutover
• Final switchover can be scheduled
• VM reboots during hardware mapping
• VMware Tools installed automatically
• OSAM does not support P2V
• Edge case handling required if power-off behavior fails

OSAM is ideal for one-time consolidation initiatives.

RackWare (Alternative Approach)

RackWare provides an alternative heterogeneous migration platform.

It supports:

• Hyper-V
• KVM
• VMware
• Physical servers

Key advantages:

• Policy-driven automation
• Migration + DR + Backup in one platform
• Wave-based orchestration
• OCI Marketplace availability

RackWare is often preferred when:

• Multiple hypervisors must be consolidated simultaneously
• DR architecture is built alongside migration
• A single platform strategy is required

Assessment and Discovery

Cross-hypervisor migration introduces additional validation requirements.

Workload Discovery

• Identify VM configurations
• Map application dependencies
• Capture storage and network characteristics

Dependency Mapping

• DNS dependencies
• Firewall policies
• IP preservation requirements
• Hypervisor-specific services

Right-Sizing

• Evaluate actual CPU/memory utilization
• Define OCVS node sizing
• Align vSAN capacity and performance

Networking Planning

• Design NSX segmentation
• Evaluate L2 extension if IP preservation required
• Plan FastConnect or IPSec

Testing

• Pilot representative workloads
• Validate application functionality post-conversion
• Benchmark performance

Migration Considerations

Disk Format Conversion

• Hyper-V (VHD/VHDX) → VMDK
• KVM (QCOW2/RAW) → VMDK

Conversion is handled automatically by OSAM or RackWare.

Networking Considerations

• IP preservation possible via HCX L2 Extension
• NSX integration post-migration
• Gateway alignment required
• Security policy redesign may be required

Storage Considerations

• Converted disks placed on vSAN or OCI Block Storage
• Validate IOPS alignment
• Consider storage tiering

Operating System Considerations

• Remove Hyper-V Integration Services
• Remove KVM-specific drivers
• Install VMware Tools
• Validate boot loader configuration

Cross-hypervisor driver replacement is a common risk area.

Choosing This Path Strategically

Hypervisor consolidation is usually driven by:

• Operational simplification
• Licensing optimization
• Skill alignment
• Vendor standardization

Decision Guidance

Choose Hyper-V/KVM → OCVS when:

• Long-term VMware standardization is strategic objective
• Existing enterprise tooling is VMware-aligned
• Operational consistency is required
• Multi-hypervisor complexity must be eliminated

Avoid this path when:

• Workloads are better suited for cloud-native transformation
• OCI Native integration is the primary goal

In such cases, migrating directly to OCI Native may be more appropriate.

Enterprise & Mission Critical Databases

Cross-hypervisor transformation increases migration complexity for large databases.

Consider hybrid strategy:

• Oracle DB → Data Guard / GoldenGate
• PostgreSQL/MySQL → Native replication
• Active Directory → Additional domain controllers
• Exchange → Hybrid / DAG models

Application-aware replication reduces downtime and risk.

Best Practices

• Execute phased migration waves
• Validate application behavior post-conversion
• Document IP, DNS, firewall dependencies
• Perform post-migration performance validation
• Align operational processes before cutover

Strategic Insight

Hypervisor consolidation is rarely a purely technical initiative.

It is typically an operational and governance decision.

Migrating Hyper-V or KVM workloads into OCVS represents:

• Platform rationalization
• Tooling unification
• Operational simplification

Handled correctly, it eliminates hypervisor fragmentation and creates a single operational control plane across hybrid infrastructure.