Oracle is not an inherent obstacle to moving to Proxmox VE. The database runs in the guest operating system; the target platform provides CPU, memory, networking and storage. Production use requires three things: an appropriate technical design, clarified licensing and a reliable support route. For RAC, also plan shared data access and failure behaviour. Technical feasibility is distinct from vendor approval.
Licensing scope
Which systems and uses are covered?
Support route
Who supports this exact configuration?
Operational validation
Does the application work after a failure?
Plan Oracle into the new platform
The move is an opportunity to size the database environment to actual needs. Oracle can be included in Proxmox operational processes for monitoring, maintenance and capacity planning. Whether shared hosts or a dedicated environment fit better depends on load, availability and licensing scope. The goal is a system your infrastructure team and DBA can operate together.
- Start with a representative application and test the target environment under real load.
- Compare database-level migration with moving the VM. Data volume, version changes and permitted interruption determine the appropriate route.
- Include existing Oracle licences and support agreements in planning. Changing hypervisor alone does not reduce Oracle licensing requirements.
Start with an Oracle inventory
Create an inventory sheet for each database: application, DBA, edition, patch level, options, storage connectivity, current host and possible target hosts. Leave unresolved questions visibly marked. For example, a VM is intended for host A but may run on B or C during maintenance. All three belong in the assessment, not just normal operation.
- Record database edition, version, Release Update, Grid Infrastructure and guest operating system.
- Collect contracts, licensing metrics and options actually used. Include test, development, recovery and parallel operation during migration.
- Record physical hosts with CPU models and core counts. Identify possible destinations for maintenance, HA and manual migration.
- Agree data volume, peak load, tolerable interruption and recovery objectives with the application owner.
CPU pinning is not licensing approval
The linked Oracle Partitioning Policy classifies methods not explicitly recognised as Soft Partitioning. Proxmox is not listed as Hard Partitioning. CPU pinning or HA rules should therefore not be treated as Oracle-recognised limits on licensing scope. The policy describes itself as a non-contractual informational document. Your actual obligations require qualified assessment of your contracts and usage.
- A large mixed cluster widens the deployment scope to assess. However, “always license the entire cluster” is no substitute for a contract review.
- A dedicated environment can make deployment boundaries easier to demonstrate. It does not, by itself, provide binding licensing assurance.
Count physical cores, not just vCPUs
A Processor-based calculation requires an established licensing scope and CPU model. Oracle's table lists a 0.5 factor for many Xeon and EPYC models, but not universally for every Intel or AMD processor. The example below shows only the effect of host count. It does not determine which hosts count under your contract.
Two hosts within the assessed scope
2 hosts × 32 physical cores × 0.5
32Processor licences
in this example
Six hosts within the assessed scope
6 hosts × 32 physical cores × 0.5
96Processor licences
in this example
- Check edition, metric, options and minimum quantities separately. This is not a calculation for Standard Edition 2 or Named User Plus.
- Hard Partitioning is not limited to Oracle hardware. The policy also names certain IBM technologies, for example.
- The Oracle Linux KVM with OLVM guidance is not approval for arbitrary KVM platforms. It requires specific CPU assignments and excludes live migration of VMs limited in this way. “Two vCPUs equal one core” is not a general rule for Proxmox.
Clarify support in writing before migration
Oracle's public matrix lists KVM with specific Oracle Linux configurations, but not Proxmox VE as a separate platform. This establishes neither blanket Proxmox approval nor a complete refusal of support. The linked MOS Note 249212.1 concerns VMware and is not a reliable basis for a Proxmox support commitment.
- Present Oracle with the exact database, Grid Infrastructure, guest OS, kernel, Proxmox version and storage configuration.
- Clarify support scope and potential requirements for reproducing faults. If another platform is needed, plan capacity, licensing, data transfer and time.
- Also obtain approval from the ERP or application vendor. A working database alone is not enough.
Distinguish Single Instance, Proxmox HA and RAC
Proxmox HA can restart a VM after host failure. The database must then become available again. RAC runs multiple database instances against shared data. These are different mechanisms with different requirements. Do not carry RAC forward without checking it against the application's recovery objective.
- RAC replaces neither independent backup nor a tested recovery path. Shared storage also remains a dependency.
For RAC, plan data paths and failure scenarios first
All RAC nodes need appropriate shared access to the database files. FC or iSCSI can be part of the solution, but are not the only possible approaches. What matters is supported storage connectivity for your configuration. Shared storage for Proxmox hosts does not automatically mean multiple guests can safely write to the same database disks simultaneously.
Test connections and recovery too
Private interconnect
Latency · Redundancy · Failure behaviour
Both instances access the same database.
Check storage paths and shared failure points.Independent backup and a tested recovery path
- Storage: check device identifiers, concurrent access, write behaviour, path failures and path recovery with the DBA. Do not simply attach the same virtual disk twice.
- Interconnect: plan separate communication paths and redundancy. Measure latency and packet loss under load and during a path failure.
- Placement: distribute RAC VMs across separate physical hosts. Test your Proxmox version's affinity-rule behaviour during maintenance and when remaining capacity is insufficient.
- Fencing: consider Oracle Clusterware and Proxmox HA together. A failure must leave no ambiguity about which instance is excluded and when a VM may restart. Do not copy timeouts from other environments without validation.
Base acceptance on the application
A successful VM start is not a successful migration. Agree a small set of concrete acceptance tests with the DBA, infrastructure team and business owners. Run failure tests only in an approved environment with backups, stop criteria and clear responsibility.
- Normal and peak load: compare important business transactions, batch runtimes and response times with the source system. Include load following a host failure.
- Host failure: measure database availability, application reconnection and actual interruption.
- For RAC: test interconnect and storage-path failures in a controlled way. Record Clusterware events and access by the remaining instance.
- Recovery: restore a suitable database backup in a separate environment and validate business functionality. A hypervisor snapshot alone is not evidence.
- Rollback: define how to preserve data created after starting on the target. Simply powering the old VM back on can lose data.
Oracle need not hold up the entire VMware exit
If licensing or support remains unresolved, treat Oracle as a separate migration workstream. Other systems may be able to move earlier. Record remaining dependencies and parallel-running costs. For Oracle itself, then compare a platform change, a dedicated environment or temporarily retaining the current setup.
- The concrete preparation outputs are an inventory sheet, assessed licensing scope, documented support route, target architecture and agreed acceptance plan. Only then commit to the cutover window.
Questions to resolve
- Are licensing scope and support clear for the exact target configuration?
- Which hosts may run Oracle VMs in normal operation, maintenance and failures?
- Have data paths, placement and remaining capacity been tested?
- Who confirms the application is usable after cutover and recovery?
- How will new data be preserved if rollback is needed?