Oracle Cloud Ravello Tutorial: Architecture, Pricing, Use Cases, and Hands-On Guide for Other Services

1. Introduction

Status note (important): Ravello (often referenced as Oracle Ravello Cloud Service) was an Oracle Cloud service acquired from Ravello Systems and historically used to run complex, VM-based application environments (including nested virtualization) on top of public cloud infrastructure. Oracle has since retired/discontinued Ravello. You should verify the current availability and end-of-life status in Oracle’s official notices and documentation before planning any new usage. Because new Ravello tenants are typically not available today, this tutorial also includes practical, executable guidance for Ravello-style workflows and migrations on Oracle Cloud Infrastructure (OCI) where appropriate.

What this service is

Ravello is (was) a cloud service for importing VM-based application stacks (for example, VMware vSphere or VirtualBox images), modeling their networking, and publishing them to run on public cloud capacity—without requiring you to redesign everything into cloud-native constructs on day one.

Simple explanation (one paragraph)

If you have an on-prem VM lab or a multi-VM enterprise app (web + app + database + AD, etc.) and you want to run it in the cloud quickly with minimal refactoring, Ravello provided a way to lift-and-shift entire environments—including complex networking—and run them as a cloud-hosted lab or dev/test environment.

Technical explanation (one paragraph)

Ravello combined a SaaS control plane (UI + APIs) with a virtualization/networking approach that allowed VM-centric blueprints to be imported (OVF/OVA), configured (CPU/RAM/disks), connected via virtual networks, and then deployed onto supported public clouds. Ravello was particularly known for supporting nested virtualization scenarios (for example, running ESXi inside the cloud for training labs) and abstracting underlying cloud networking differences.

What problem it solves

Ravello addressed the “cloud migration gap” where teams want cloud elasticity and on-demand environments but cannot immediately refactor: – Legacy or vendor appliances that only ship as VMs – Training labs requiring isolated student environments – Multi-VM enterprise stacks that depend on L2-ish assumptions or static network patterns – Rapid dev/test environments that match on-prem more closely than cloud-native equivalents

2. What is Ravello?

Official purpose (what Ravello was designed to do)

Ravello’s purpose was to let you run existing VM workloads and complex, multi-VM environments on public clouds with minimal changes, by modeling them as reusable application templates and deploying them on demand.

Because Ravello is retired, treat the following as historical capability descriptions and validate details in archived Oracle documentation where available.

Core capabilities

Import VM images (commonly OVF/OVA; sometimes VMDK-based artifacts depending on workflow)
Build reusable blueprints (templates) for complex, multi-tier applications
Create runnable applications/environments from those blueprints
Define virtual networks, subnets, and connectivity between VMs
Publish/deploy environments onto supported cloud infrastructure locations
Manage environment lifecycle: start/stop, scale (within limits), snapshot-like operations (feature details vary—verify in official docs)
Provide self-service provisioning for labs/dev/test (often used by training organizations)

Major components (conceptual model)

Terminology varied across versions, but the common conceptual pieces were:

Component	What it represented	Why it mattered
Blueprint	A template describing VMs, disks, networks, and boot order	Repeatable environments for teams or classes
Application / Environment	A running instance created from a blueprint	The actual deployed lab/dev/test stack
VM / Node	An individual virtual machine definition	Resource sizing, disk, NICs, metadata
Network	Virtual network(s) connecting VMs	Preserved topology and dependencies
Publish Location	Target cloud and region where it runs	Controls latency, data residency, cost
User / Role	Access control within the Ravello portal	Governance for teams and students

Service type

Type: Managed cloud service (SaaS control plane) orchestrating VM-based environments on public cloud compute.
Primary workload model: Virtual machines (VMs), VM networks, and multi-VM topologies (not containers-first).

Scope (regional/global/account-scoped)

Historically, Ravello behaved like: – Account/subscription-scoped service with tenants and users – A global control plane (SaaS) where you selected a target cloud region for actual runtime placement
Exact scoping (and supported regions/providers) changed over time—verify in official docs if you have an active legacy tenant.

How it fit into the Oracle Cloud ecosystem

When active, Ravello complemented Oracle Cloud by providing: – A VM-centric migration and lab platform for workloads not ready for OCI-native patterns – A bridge for VMware-like labs and training environments – A stepping stone toward OCI services (Compute, Networking, Object Storage, IAM)

Today, because Ravello is discontinued, Oracle Cloud users typically replace Ravello with: – OCI Compute (for general VM hosting) – OCI Networking (VCN) (for network topology and isolation) – OCI VMware Solution (for managed VMware SDDC use cases) – Oracle Cloud Migrations and partner tooling (where applicable)

3. Why use Ravello?

Because Ravello is generally unavailable for new usage, this section is written in two parts: 1) Why teams historically chose Ravello, and
2) What to choose now on Oracle Cloud.

Business reasons (historical)

Faster time-to-cloud for VM-based apps: lift-and-shift labs without re-architecture
Reduced training/lab logistics: eliminate on-prem lab hardware management
On-demand environments: provision per team, per student, per sprint
Better utilization: start/stop environments to reduce runtime costs (depending on pricing model and whether “stopped” still incurred storage charges)

Technical reasons (historical)

Multi-VM application modeling (blueprints) with consistent repeatability
Complex networking abstraction for labs and legacy stacks (verify exact capabilities per version)
Nested virtualization support scenarios (commonly cited in training/lab contexts)
Portability of VM artifacts (import from common VM formats)

Operational reasons (historical)

Centralized self-service portal for teams
Environment lifecycle operations (publish, stop/start, duplicate)
Isolation between environments (important for labs/training)

Security/compliance reasons (historical)

Ability to isolate environments per team/class
Choose deployment region/location for residency and latency (subject to available cloud locations)

Scalability/performance reasons (historical)

Scale by provisioning more environments rather than scaling a single environment infinitely
Performance depended heavily on the underlying public cloud instance types and storage/network characteristics

When teams should choose it (today)

In most cases, you should not plan new Ravello usage because it is retired. Choose Ravello only if: – Your organization has an existing legacy Ravello tenant still operating (rare), and – You need to maintain an existing lab temporarily while executing a migration plan.

When teams should not choose it

If you are starting a new project on Oracle Cloud today
If you need long-term supportability, modern security controls, or deep OCI-native integrations
If you need guaranteed roadmap and availability for new deployments

4. Where is Ravello used?

Industries

Historically common in: – Education & training (hands-on labs for VMware, networking, security, middleware) – Software vendors (demo environments and PoCs) – Enterprises with large VM estates needing interim cloud hosting – IT consulting and system integrators (portable customer demos)

Team types

Platform and lab operations teams
Dev/test teams supporting legacy stacks
Pre-sales engineering and solution architecture teams
Training delivery teams

Workloads

Multi-tier VM apps (web/app/db)
Directory services and identity labs (AD/LDAP)
Network/security labs (firewalls, IDS, jump hosts)
Vendor appliances delivered as VMs
Temporary staging environments resembling on-prem

Architectures

Blueprint-based repeatable environments
Per-tenant or per-student isolated networks
Hub/spoke patterns for shared services (historically possible depending on networking features—verify in official docs)

Real-world deployment contexts

Instructor-led training with dozens/hundreds of parallel student environments
Product demos spun up for short windows (hours/days)
Migration rehearsals: validate a VM stack in cloud before re-platforming

Production vs dev/test usage

Ravello was predominantly used for: – Dev/test, training, demos, PoCs It was less common (and often not recommended) as the long-term platform for mission-critical production systems due to lifecycle, provider abstraction limits, and operational constraints.

5. Top Use Cases and Scenarios

Below are realistic Ravello-aligned use cases (historical), with “what to do now” implications in mind.

1) Training labs with per-student isolated environments

Problem: You need 50–500 identical lab environments, isolated per student.
Why Ravello fit: Blueprints enabled mass cloning of identical stacks with consistent networking.
Example: A VMware + Linux admin course provisions a 6-VM lab per student for 3 days.

2) Lift-and-shift a VMware-based demo environment

Problem: Sales engineers need consistent demos without carrying hardware.
Why Ravello fit: Import OVAs and publish quickly; start/stop when not needed.
Example: A database vendor runs a 3-tier demo with preloaded datasets.

3) Multi-VM legacy application rehearsal before OCI migration

Problem: You need to test whether the app works in cloud before redesigning it.
Why Ravello fit: Recreated an on-prem-like environment quickly.
Example: A 10-VM app with static IP assumptions is validated in a cloud-hosted lab.

4) Vendor appliance evaluation (security, networking, monitoring)

Problem: Appliances are shipped as VMs and require specific NIC/network setups.
Why Ravello fit: VM-first and topology-focused workflow.
Example: Evaluate a virtual firewall and SIEM collector with multiple interfaces.

5) Reproducible QA environments for regression testing

Problem: QA needs identical environments for each release and bug reproduction.
Why Ravello fit: Blueprints and cloning reduced configuration drift.
Example: A 3-tier Java app environment is recreated per release candidate.

6) Classroom “reset” at scale

Problem: Students break labs; you must reset quickly.
Why Ravello fit: Recreate or revert environments (capabilities varied—verify in docs).
Example: Reset 120 student environments between sessions.

7) Temporary partner enablement labs

Problem: Partners need a sandbox for a week without VPN access to corporate networks.
Why Ravello fit: Self-service access to isolated environments.
Example: A partner enablement program runs labs across multiple time zones.

8) On-demand internal IT sandboxes

Problem: Infra teams need isolated testbeds for patching and changes.
Why Ravello fit: Quick provisioning of realistic VM stacks.
Example: Test AD schema changes, GPO updates, and patch bundles.

9) “Identical to on-prem” troubleshooting replicas

Problem: Production issue needs a close replica for debugging.
Why Ravello fit: Import production-like VM templates and mimic topology.
Example: Recreate an older OS + middleware stack to reproduce a memory leak.

10) Nested virtualization labs (where supported)

Problem: You need to teach vSphere concepts requiring ESXi/vCenter.
Why Ravello fit: Known for nested virtualization scenarios (verify exact support details).
Example: A vSphere class runs nested ESXi hosts inside cloud VMs for 2 days.

11) Disaster recovery rehearsal for VM stacks (limited scope)

Problem: You want to validate that VM workloads can run offsite.
Why Ravello fit: Could host VM environments in a cloud location for testing.
Example: Quarterly DR test for a departmental application suite.

12) Migration staging: converting OVA/OVF and validating boot

Problem: You need a pipeline to validate imported VM images.
Why Ravello fit: VM import + environment lifecycle made iterative testing easier.
Example: Convert golden images and test boot across multiple environments.

6. Core Features

Because Ravello is discontinued, the items below describe the core features Ravello was known for. If you still have a legacy Ravello tenant, verify exact feature availability in the tenant’s UI and archived Oracle docs.

6.1 VM import (OVF/OVA-centric workflows)

What it does: Lets you import VM appliances and multi-VM packages commonly exported from VMware/VirtualBox.
Why it matters: Minimizes refactoring and repackaging.
Practical benefit: Rapid onboarding of legacy systems and lab templates.
Limitations/caveats: Image compatibility, guest OS drivers, and networking expectations can still cause boot issues; import constraints and supported formats vary—verify in official docs.

6.2 Blueprint-based application modeling

What it does: A blueprint defines VMs, their resources, disks, networks, and relationships.
Why it matters: Repeatability and scale for labs and dev/test.
Practical benefit: “Create once, run many times” across teams/classes.
Limitations/caveats: Blueprint abstraction may not map 1:1 to OCI-native constructs (VCNs, NSGs, route tables).

6.3 Publish/deploy to a target cloud location

What it does: Deploys a blueprint/application to a chosen cloud location/region (depending on supported providers at the time).
Why it matters: Lets you select region proximity, cost, or data residency.
Practical benefit: Run the same blueprint across multiple locations for latency testing or regional classes.
Limitations/caveats: Underlying instance types and features differ by provider; performance and networking behavior can vary.

6.4 Environment lifecycle controls (start/stop/clone)

What it does: Operational controls to manage runtime environments.
Why it matters: Cost and operational efficiency for ephemeral labs.
Practical benefit: Turn off environments when not needed; clone for multiple users.
Limitations/caveats: “Stopped” may still incur storage charges; exact semantics depend on underlying cloud resources and Ravello implementation.

6.5 Multi-VM networking topology management

What it does: Define how VMs connect, including multi-NIC designs.
Why it matters: Many enterprise labs depend on topology, not just compute.
Practical benefit: Model realistic networks for training and validation.
Limitations/caveats: Deep L2 behaviors across public clouds are non-trivial; Ravello used abstraction approaches that may not match every edge case (verify historical docs).

6.6 Role-based access control (tenant users and permissions)

What it does: Controls who can manage blueprints, applications, and environments.
Why it matters: Essential for shared lab platforms.
Practical benefit: Separate instructors/admins from students/users.
Limitations/caveats: Integration with enterprise identity providers varies by era/version—verify in official docs.

6.7 Catalog-style reuse for labs and demos

What it does: Reuse standardized blueprints repeatedly.
Why it matters: Consistency across classes and demos.
Practical benefit: Reduce configuration drift and manual setup.

6.8 API/automation potential (where available)

What it does: Automate provisioning and lifecycle operations programmatically.
Why it matters: Integrates with CI/CD, class scheduling systems, or internal portals.
Practical benefit: Self-service lab provisioning at scale.
Limitations/caveats: API coverage and authentication methods depend on the service version—verify in official docs.

7. Architecture and How It Works

This section explains Ravello’s architecture at a high level and then maps practical equivalents on Oracle Cloud today.

High-level service architecture (conceptual)

Ravello typically consisted of: – A SaaS control plane (UI + API) where you managed blueprints and applications. – A runtime layer that placed VM workloads onto underlying public cloud compute resources. – A networking abstraction to connect VMs according to the blueprint’s topology. – Storage handling for VM disks, snapshots/versions (capabilities varied).

Request/data/control flow (conceptual)

User logs into Ravello portal and defines/imports a blueprint.
User creates an application/environment from the blueprint.
User selects a publish location (cloud/region).
Ravello orchestrates deployment: – Allocates compute resources – Attaches storage for VM disks – Configures network connectivity per blueprint
Users access VMs via public IPs, jump boxes, or VPN-like approaches (depending on design).

Integrations with related services (historical and present)

Historical: Integration was primarily with underlying IaaS providers (compute/network/storage abstraction).
In OCI today (replacement approach):
Use OCI Compute for VMs
Use VCN, subnets, route tables, NSGs/Security Lists for networking
Use Object Storage for image artifacts
Use IAM for identity and access control
Use Logging, Monitoring, Events, Notifications for ops visibility (OCI-native)

Dependency services

Ravello depended on: – Underlying cloud compute and storage – Reliable management/control plane connectivity – VM image compatibility (guest OS drivers, boot firmware, etc.)

Security/authentication model (conceptual)

Tenant user management with roles (details vary)
Environment isolation as a security boundary for labs
Network exposure controlled through published endpoints/public IPs and firewall rules defined per environment (details vary)

Networking model (conceptual)

Blueprint-defined networks connected VMs
Egress/ingress to the internet or shared services typically required additional configuration
Real behavior depends on the cloud provider and Ravello’s overlay/abstraction—verify in official docs

Monitoring/logging/governance considerations

Ravello: portal visibility and operational controls (historical)
OCI replacement: Cloud-native observability and governance via OCI services

Simple architecture diagram (conceptual Ravello flow)

flowchart LR
  U[User / Admin] --> P[Ravello Portal (UI/API)]
  P --> B[Blueprints & App Definitions]
  P --> PUB[Publish to Cloud Location]
  PUB --> CP[Underlying Cloud Compute/Storage/Network]
  CP --> VM[Running VMs / Multi-VM App]
  U -->|SSH/RDP/Web| VM

Production-style architecture diagram (Ravello-style labs + OCI migration landing zone)

flowchart TB
  subgraph Identity
    IDP[Enterprise IdP / SSO]
    OCI_IAM[OCI IAM]
  end

  subgraph Ops
    LOG[OCI Logging]
    MON[OCI Monitoring]
    VAULT[OCI Vault]
  end

  subgraph Network
    VCN[OCI VCN]
    SUBPUB[Public Subnet]
    SUBPRV[Private Subnet]
    IGW[Internet Gateway]
    NAT[NAT Gateway]
    BAST[Bastion / Jump Host]
  end

  subgraph Images
    OBJ[OCI Object Storage Bucket]
    IMG[OCI Custom Image]
  end

  subgraph Workloads
    APPVM[App VM(s)]
    DBVM[DB VM(s)]
  end

  IDP --> OCI_IAM
  OCI_IAM -->|AuthZ| OBJ
  OCI_IAM -->|AuthZ| APPVM

  OBJ --> IMG --> APPVM
  VCN --> SUBPUB --> BAST
  VCN --> SUBPRV --> APPVM
  VCN --> SUBPRV --> DBVM
  SUBPUB --> IGW
  SUBPRV --> NAT --> IGW

  APPVM --> LOG
  APPVM --> MON
  DBVM --> LOG
  DBVM --> MON
  APPVM --> VAULT

How to interpret this diagram: If you previously used Ravello to publish multi-VM labs, the OCI pattern is to build a secure landing zone (VCN + subnets + IAM), store/import images in Object Storage, run VMs on Compute, and use Bastion/jump hosts for controlled access.

8. Prerequisites

Because Ravello is discontinued, the hands-on portion focuses on Ravello-style VM image workflows on OCI (useful for migrations from Ravello or for teams modernizing VM labs).

Account/tenancy requirements

An Oracle Cloud (OCI) tenancy with billing enabled (or an eligible trial).
Access to the OCI Console.

Permissions / IAM

At minimum, you need permissions to: – Create/manage VCNs, subnets, gateways, route tables, NSGs/security lists – Create/manage Compute instances – Create/manage Object Storage buckets and objects – Create/manage Custom Images (image import)

If you’re in a restricted enterprise tenancy, ask an admin for a policy set that grants these capabilities in a compartment used for labs.

Billing requirements

You will incur OCI charges for:
Compute instances
Block volumes (boot and data)
Object Storage
Outbound data transfer
Use the smallest shapes and shortest runtime to minimize cost.

Tools needed

A workstation with:
ssh client
A browser
Optional (recommended for image conversion): Linux/macOS with:
- qemu-img
- tar
Optional: OCI CLI (not required for this lab)

Region availability

OCI: choose a region near you.
Ravello: legacy availability only; verify.

Quotas/limits

Common OCI limits you may hit: – Compute instance limits (per shape family) – Block volume limits – Object Storage request limits (usually high) – Custom image size limits (verify in official OCI docs)

Prerequisite services

OCI Networking (VCN)
OCI Compute
OCI Object Storage

9. Pricing / Cost

Ravello pricing model (historical)

Ravello pricing changed over time and may have been contract-based. Historically, costs were typically driven by: – VM runtime (hours) – Allocated resources (vCPU/RAM) – Storage consumed by VM disks and snapshots – Public IP addresses – Outbound data transfer

Important: Because Ravello is discontinued, public pricing pages may no longer be available. If you still operate under a legacy contract, consult your Oracle account team or archived documentation and invoices.

OCI pricing model (what you’ll use now)

For Ravello-style VM labs and migration staging on Oracle Cloud, OCI costs generally come from:

Pricing dimensions – Compute: instance-hours based on shape (ECPU/OCPU/vCPU model depends on shape family) – Block Volume: GB-month for boot and data volumes, plus performance tiers (depending on configuration) – Object Storage: GB-month stored, requests, and retrieval (tiers vary) – Networking: outbound data transfer, NAT Gateway usage, Load Balancer (if used) – Optional services: Bastion, Logging retention, Vault secrets, etc.

Free tier OCI has a Free Tier for some resources in many regions. Eligibility and included resources change—verify on the official OCI Free Tier page.

Cost drivers (direct + indirect)

Big VM images: imported images (tens of GB) increase Object Storage and transfer time/cost.
Egress traffic: labs with software downloads and updates can generate outbound bandwidth costs.
Always-on environments: leaving instances running 24/7 dominates cost.
NAT/Load Balancers: convenience services add recurring costs.

Hidden/indirect costs to watch

Object Storage PUT/GET requests at scale (for large lab automation)
Logging retention if you store high-volume logs for a long time
Multiple copies of VM images (bucket + custom image + boot volumes)

Cost optimization tips

Prefer ephemeral labs: start only during lab windows.
Use smaller shapes for students; reserve larger shapes for shared services.
Standardize images and avoid duplicate copies.
Use private subnets and a bastion instead of public IPs on every VM.
Consider instance pools or automation to create/destroy labs on schedule.

Example low-cost starter estimate (no fabricated numbers)

A minimal OCI lab environment typically includes: – 1 small compute instance – 1 boot volume – A small Object Storage bucket (for an image artifact) – A VCN and subnets (no direct cost)

Exact totals depend on region, shape, and hours used. Use the official OCI pricing pages and calculator:

OCI pricing landing page: https://www.oracle.com/cloud/pricing/
OCI cost estimator/calculator (if available in your region): https://www.oracle.com/cloud/costestimator.html (verify current URL in Oracle docs)

Example production cost considerations (what changes)

For a production-like lab platform (dozens/hundreds of environments): – Compute becomes the largest cost driver – Storage multiplies with per-environment boot volumes – Automation and observability costs (logging/metrics retention) – Network egress for updates and student access – Operational overhead: golden image management, vulnerability management, patching

10. Step-by-Step Hands-On Tutorial

Because Ravello is discontinued, this lab focuses on a real, executable workflow you’ll commonly need when leaving Ravello or replicating Ravello-style VM delivery on Oracle Cloud:

Take a VM appliance (OVA),
Convert it to a cloud-importable format,
Upload it to OCI Object Storage,
Import it as a Custom Image,
Launch a compute instance from that image,
Validate access,
Clean up.

Objective

Build a “Ravello-style” VM image pipeline on Oracle Cloud Infrastructure by importing an OVA appliance into OCI and launching it as a compute instance.

Lab Overview

You will: 1. Create an OCI network (VCN + subnet). 2. Prepare a VM image (OVA → disk image). 3. Upload the disk image to Object Storage. 4. Import a Custom Image in OCI. 5. Create an instance from the image. 6. Validate SSH access. 7. Clean up all resources to avoid ongoing costs.

Step 1: Prepare your OCI compartment and region

Sign in to the Oracle Cloud Console.
Select the Region you want to use (top right).
Choose or create a Compartment for the lab resources (for example, lab-ravello-migration).

Expected outcome: You have a dedicated compartment and region selected to keep resources organized.

Step 2: Create a VCN for the lab (VCN Wizard)

Go to Networking → Virtual Cloud Networks.
Click Create VCN.
Use VCN Wizard → VCN with Internet Connectivity (wording may vary).
Provide: – VCN name: ravello-style-vcn – CIDR: accept default (or use 10.0.0.0/16) – Create an Internet Gateway – Create a Public Subnet (for simplest validation)
For more secure setups, you would use a private subnet + Bastion, but this lab keeps it beginner-friendly.

Expected outcome: VCN, subnet, route table, and security list are created.

Verification: – Confirm the subnet has a route to the Internet Gateway (0.0.0.0/0).

Step 3: Obtain a small OVA to import (choose a legal test image)

You need an OVA you are allowed to use. Options: – A vendor-provided test appliance – Your own exported VM – A lightweight Linux VM you built yourself and exported as OVA from VirtualBox or VMware

Important: Some operating systems have redistribution restrictions. Use a compliant image.

Expected outcome: You have a local file, for example: – appliance.ova

Step 4: Convert OVA to a cloud import format (QCOW2 is common)

OCI supports several custom image formats, and support can change. Verify current OCI custom image import requirements in official docs. A safe, commonly used path is to convert to QCOW2.

On a Linux workstation:

Create a working directory:

mkdir -p ~/ravello-image-lab && cd ~/ravello-image-lab

Copy in your OVA:

cp /path/to/appliance.ova .

Extract the OVA (OVA is a tar archive):

tar -xvf appliance.ova

This typically produces: – *.ovf (descriptor) – *.vmdk (virtual disk) – *.mf (manifest) sometimes

Convert the VMDK to QCOW2:

qemu-img convert -p -f vmdk -O qcow2 disk1.vmdk appliance.qcow2

Check the disk image info:

qemu-img info appliance.qcow2

Expected outcome: You have appliance.qcow2 ready to upload.

Common issue: Some OVAs contain multiple VMDKs. Convert the boot disk first (or consolidate disks as required). OCI custom images typically expect a bootable disk image.

Step 5: Create an Object Storage bucket and upload the image

Go to Storage → Object Storage & Archive Storage → Buckets.
Click Create Bucket: – Name: ravello-image-import-bucket-<unique> – Default storage tier is fine for a lab
Open the bucket → Upload → upload appliance.qcow2.

Expected outcome: The QCOW2 image is stored in your bucket.

Verification: – Confirm the object appears with the correct size. – Copy the object name (you’ll reference it during image import).

Step 6: Import a Custom Image in OCI from Object Storage

Go to Compute → Custom Images (or Images → Custom Images, depending on console navigation).
Click Import image (wording may vary).
Provide: – Name: ravello-imported-image – OS / Image type details as requested (if prompted).
If OCI requires OS type for guest agent compatibility, choose the closest match. – Source: Object Storage – Bucket: your bucket – Object: appliance.qcow2 – Format: QCOW2 (select if prompted)
Start the import.

Expected outcome: A Custom Image enters an “Importing” state and eventually becomes “Available”.

Verification: – Wait until status is Available. – If it fails, open the import details and read the error.

Step 7: Launch a Compute instance from the imported image

Go to Compute → Instances → Create instance.
Name: ravello-imported-vm-01
Image: select Custom Images → ravello-imported-image
Shape: choose a small shape compatible with your tenancy and region.
Networking: – VCN: ravello-style-vcn – Subnet: the public subnet – Assign a public IPv4 address: Yes (for easiest validation)
Add SSH key: – Provide your public key (~/.ssh/id_rsa.pub or id_ed25519.pub)

Create the instance.

Expected outcome: Instance provisions and reaches Running state with a public IP.

Step 8: Validate access (SSH)

From your workstation:

ssh -i ~/.ssh/id_ed25519 <username>@<public_ip>

<username> depends on the OS image (commonly opc on Oracle Linux images, but for imported appliances it might differ).
If you don’t know the username, consult the appliance documentation.

Expected outcome: You can log in via SSH.

If SSH fails: – Confirm security list ingress allows TCP/22 from your IP. – Confirm the VM is actually listening on port 22. – Confirm the appliance firewall allows SSH. – Confirm cloud-init/agent expectations (imported appliances may not have OCI guest agent).

Validation

Use the following checks:

Instance status: Console shows Running.
Network reachability: You can ping the VM (ICMP may be blocked; not definitive).
SSH works: You can log in.
Disk/OS boots: Run:

uname -a
df -h
ip a

Troubleshooting

Import fails with “unsupported format” or “image not bootable”

Ensure you converted the correct disk and it’s bootable.
Confirm the format selection matches the file (QCOW2 vs VMDK).
Verify image requirements (firmware/UEFI vs BIOS) in official OCI custom image docs.

Instance boots but networking doesn’t work

Appliance might expect a specific NIC driver or static configuration.
Check ip a and ip r.
If the image uses static IP, reconfigure to DHCP or adjust VCN/subnet to match.

SSH key doesn’t work

Imported appliance may not install your SSH key automatically (no cloud-init).
You may need console access or to bake credentials into the image before export.

Port 22 blocked

Update the subnet security list or NSG to allow inbound SSH from your IP/CIDR.
Confirm the OS firewall (iptables/firewalld) allows SSH.

Cleanup

To avoid ongoing charges, delete resources in this order:

Terminate the instance – Compute → Instances → ravello-imported-vm-01 → Terminate – Choose to delete attached boot volume (if appropriate).
Delete the Custom Image – Compute → Custom Images → ravello-imported-image → Delete
Delete the Object Storage object and bucket – Storage → Buckets → delete appliance.qcow2 – Delete the bucket (must be empty)
Delete networking – Networking → VCNs → ravello-style-vcn → Terminate – If termination fails, delete dependent gateways/resources first.

Expected outcome: No compute, storage, or network resources remain in the compartment for this lab.

11. Best Practices

Architecture best practices

Treat Ravello-style blueprints as infrastructure-as-data: version control the VM build steps and documentation.
Separate golden images from runtime environments:
Golden image pipeline: build → test → publish
Runtime: create instances from known-good images

IAM/security best practices

Use least privilege IAM policies in OCI compartments.
Separate compartments for:
images (Object Storage + custom images)
labs-devtest (instances and networks)
Require MFA/SSO for admin users.

Cost best practices

Use schedules/automation to terminate or stop lab environments after class hours.
Minimize image sprawl:
Keep one canonical image per course/version
Delete old imports and old objects
Prefer private networking + bastion instead of public IPs on every VM.

Performance best practices

Choose shapes appropriate to the workload:
IO-heavy appliances need adequate block volume performance
Memory-heavy labs fail in subtle ways if undersized
Keep images lean (remove unused packages) to reduce boot time and storage.

Reliability best practices

Store golden images in a controlled bucket with retention and restricted write access.
Document a repeatable rebuild process; don’t rely on a single hand-built OVA.

Operations best practices

Tag everything: environment, owner, cost-center, course-id, expiration date.
Use OCI Monitoring/Logging for instances where possible (agent support varies by OS/image).
Keep a runbook: image import failures, networking fixes, access recovery.

Governance/tagging/naming best practices

Naming convention example:
img-ravello-mig-<app>-<version>
vm-lab-<course>-<studentid>
vcn-lab-<course>-<date>
Mandatory tags:
Owner, Purpose, Expiry, CostCenter, DataSensitivity

12. Security Considerations

Identity and access model

Ravello (historical): – Tenant users and role-based permissions. – Isolation between environments was a core requirement for labs.

OCI replacement (recommended today): – Use OCI IAM with compartments and policies. – Use groups/roles aligned to responsibilities: – Image builders – Lab operators – Students/users (ideally limited; often better to provide access via bastion or web front-ends rather than full console access)

Encryption

OCI Object Storage encrypts data at rest by default (verify current behavior in OCI docs).
Use customer-managed keys (OCI Vault) if required for compliance (where supported).

Network exposure

Avoid public IPs on every VM for labs.
Use:
Private subnets
Bastion/jump hosts
Tight NSG rules
Restrict inbound to known IP ranges (instructor VPN, corporate egress, etc.).

Secrets handling

Do not bake long-lived credentials into VM images.
Use OCI Vault for secrets where possible.
For training labs, rotate credentials per class and expire them.

Audit/logging

OCI provides audit logs for control-plane actions (IAM, networking, compute). Enable and retain per compliance needs.
For guest OS logs, use an agent-based approach where supported; imported appliances may not support OCI agents.

Compliance considerations

Data residency: choose the OCI region and control object locations.
Training labs often include sensitive configs (keys, certificates). Treat lab images as sensitive assets.

Common security mistakes

Leaving SSH open to the world (0.0.0.0/0) without restrictions
Reusing the same admin password across all student labs
Allowing students broad OCI console permissions
Storing images in publicly readable buckets

Secure deployment recommendations

Use private networking and a single controlled entry point.
Harden images: disable unnecessary services, enforce key-based SSH, patch regularly.
Implement automatic expiration and teardown of environments.

13. Limitations and Gotchas

Ravello-specific (legacy) limitations

Service discontinuation: You may not be able to create new tenants or run new workloads.
Supportability: Limited/no roadmap; dependencies and tooling may be frozen.
Integration gaps: Not equivalent to OCI-native governance and observability.

VM image portability gotchas (common when migrating from Ravello)

Guest OS driver mismatches (virtio, NIC naming)
DHCP vs static IP assumptions
BIOS vs UEFI boot mode mismatches
Cloud-init/agent expectations: imported appliances may not inject SSH keys automatically
Licensing constraints for commercial OS and software

Regional constraints

OCI services are region-specific.
Data transfer and latency vary by region; training labs in particular are sensitive to latency.

Pricing surprises

Outbound data transfer for updates, package repos, and student access
Keeping dozens of lab VMs running continuously
Duplicate storage copies of large images

Operational gotchas

Imported images often require manual access recovery methods.
“Golden image drift” if instructors modify running VMs and re-export ad hoc.

14. Comparison with Alternatives

Because Ravello is retired, comparisons focus on what replaces Ravello-like outcomes today.

Option	Best For	Strengths	Weaknesses	When to Choose
OCI Compute + VCN (DIY labs)	VM-based labs and dev/test	Native OCI, full control, broad availability	You build lifecycle automation yourself	Most teams replacing Ravello
OCI VMware Solution	Managed VMware SDDC needs	Familiar VMware tooling, vCenter, ESXi	Higher cost/complexity than single VMs	When you truly need VMware stack semantics
OCI Marketplace images	Quick start common stacks	Faster provisioning, supported images	Less control over appliance packaging	Standard workloads that don’t require custom OVAs
VMware Cloud (other providers)	VMware-first cloud operations	Strong VMware compatibility	Vendor lock-in, cost	When VMware operational model is required
OpenStack (self-managed)	Private cloud VM orchestration	Control, open ecosystem	Significant ops burden	When you need on-prem private cloud
KubeVirt / Kubernetes-based virtualization	VM workloads managed like K8s	Modern ops model, GitOps-friendly	Learning curve; not always drop-in	When platform team standardizes on Kubernetes

15. Real-World Example

Enterprise example: training and enablement platform modernization

Problem: A large enterprise previously delivered internal training using Ravello blueprints with multi-VM labs. Ravello retirement forces a new platform.
Proposed architecture (OCI):
OCI compartments per course
Golden images stored in Object Storage
Terraform to create VCNs, subnets, NSGs
Compute instances per student in private subnets
OCI Bastion for access
Scheduled automation to terminate labs after class
Why Ravello was chosen (historically): Rapid cloning of identical environments and lab isolation.
Expected outcomes (OCI replacement):
Long-term supportability and security controls
Better governance (IAM, audit)
Predictable operations with IaC and tagging
Reduced public exposure via bastion-based access

Startup/small-team example: VM-based product demos

Problem: A startup needs short-lived demo environments for prospects, originally built as OVAs.
Proposed architecture (OCI):
One hardened demo image (custom image)
One public-facing demo VM behind strict security rules
Automated teardown/rebuild per demo cycle
Why Ravello was chosen (historically): Easy publishing of a demo environment without rebuilding into cloud-native services.
Expected outcomes (OCI replacement):
Lower complexity than running a full VMware stack
Faster demos with image-based provisioning
Clear cost control via teardown

16. FAQ

Is Ravello currently available on Oracle Cloud?
Ravello is generally retired/discontinued. Verify current status via Oracle’s official documentation and announcements. If you have a legacy tenant, consult your Oracle account team for support and migration options.
What was Ravello best known for?
Running complex VM-based environments and training labs in the cloud, often with capabilities that supported nested virtualization and multi-VM topology reproduction (verify exact historical capabilities per version).
What should I use instead of Ravello on Oracle Cloud today?
Typically OCI Compute + VCN for VM-based labs, and OCI VMware Solution if you truly need managed VMware SDDC behavior.
Can I still import OVA/OVF files into Oracle Cloud?
Not via Ravello (if discontinued), but you can use OCI custom image import workflows. You often convert OVA→QCOW2/VMDK and import through the OCI Console.
Does OCI support running VMware ESXi nested in a VM?
Nested virtualization support depends on the compute shape and hypervisor capabilities and may have restrictions. Verify in official OCI docs for your region and shape.
Why do imported appliances sometimes fail to boot?
Common causes include BIOS/UEFI mismatch, unsupported disk controller drivers, incorrect disk selection from multi-disk OVAs, or missing bootloader configurations.
How do I handle SSH keys with imported appliances?
If the appliance doesn’t support cloud-init or OCI guest agent injection, your SSH key may not be added automatically. Consider pre-baking access or using a console recovery method.
What’s the most secure way to provide student access to labs on OCI?
Prefer private subnets + OCI Bastion (or a controlled jump host) and restrict ingress tightly, rather than giving every VM a public IP.
How do I reduce the cost of large training classes on OCI?
Use teardown automation, smaller shapes, shared services where appropriate, and avoid duplicating large images across many buckets/regions.
How do I version control lab environments without Ravello blueprints?
Use Infrastructure as Code (Terraform) for networking/instances and a documented image pipeline (Packer or scripted builds) for golden images.
Can I run multi-VM topologies on OCI like Ravello did?
Yes—use VCNs, subnets, NSGs, route tables, and optionally multiple VNICs per instance. You model topology in IaC rather than a Ravello blueprint UI.
What replaces Ravello’s “publish location” concept?
In OCI you choose the region, availability domain, and subnet where instances run.
How do I estimate OCI costs for a lab?
Use the official OCI pricing pages and cost estimator. Model costs by instance-hours, storage GB-month, and expected network egress.
What’s the biggest migration risk from Ravello to OCI?
VM image compatibility and access bootstrapping (cloud-init/agent differences), plus re-implementing blueprint-like automation.
Where can I find Ravello documentation now?
Oracle’s docs site may still host archived content. Start with Oracle documentation portals and official announcements; availability may vary over time.

17. Top Online Resources to Learn Ravello

Because Ravello is retired, official resources may be archived or partially removed. The table includes Ravello references and the key OCI replacement resources you’ll use in practice.

Resource Type	Name	Why It Is Useful
Official documentation (archived)	Oracle Documentation portal (search “Ravello”) — https://docs.oracle.com/	Best starting point to find any remaining Ravello docs and terminology references
Official cloud pricing	Oracle Cloud Pricing — https://www.oracle.com/cloud/pricing/	Use for current OCI pricing when replacing Ravello workloads
Official cost estimator	Oracle Cloud Cost Estimator — https://www.oracle.com/cloud/costestimator.html (verify)	Build estimates for VM labs, storage, and network usage
OCI custom images docs	OCI documentation (search “custom image import”) — https://docs.oracle.com/	Required to correctly import OVA-derived images
OCI networking docs	OCI VCN documentation — https://docs.oracle.com/	Replace Ravello network topology with VCN/subnets/NSGs
OCI architecture guidance	Oracle Architecture Center — https://docs.oracle.com/solutions/	Reference architectures for secure networking, bastion patterns, and governance
OCI tutorials/labs	Oracle Cloud tutorials (search) — https://docs.oracle.com/	Step-by-step OCI labs for compute, networking, and security
Video learning	Oracle Cloud YouTube channel — https://www.youtube.com/@OracleCloudInfrastructure	Practical walkthroughs for OCI services used to replace Ravello workflows
Community learning	Oracle Cloud community/blogs (verify relevance)	Useful for migration stories and image import troubleshooting (validate against official docs)

18. Training and Certification Providers

Institute	Suitable Audience	Likely Learning Focus	Mode	Website URL
DevOpsSchool.com	DevOps engineers, SREs, platform teams	OCI operations, automation, DevOps practices around cloud infrastructure	Check website	https://www.devopsschool.com/
ScmGalaxy.com	Beginners to intermediate engineers	DevOps fundamentals, CI/CD, cloud basics	Check website	https://www.scmgalaxy.com/
CLoudOpsNow.in	Cloud operations teams	Cloud ops, monitoring, reliability, cost awareness	Check website	https://www.cloudopsnow.in/
SreSchool.com	SREs and reliability-focused engineers	SRE practices, observability, incident response on cloud	Check website	https://www.sreschool.com/
AiOpsSchool.com	Ops teams exploring AIOps	Monitoring automation, AIOps concepts, operational analytics	Check website	https://www.aiopsschool.com/

19. Top Trainers

Platform/Site	Likely Specialization	Suitable Audience	Website URL
RajeshKumar.xyz	DevOps/cloud coaching and guidance (verify offerings)	Individuals and teams seeking mentoring-style training	https://rajeshkumar.xyz/
devopstrainer.in	DevOps training programs (verify specifics)	Beginners to advanced DevOps learners	https://www.devopstrainer.in/
devopsfreelancer.com	Freelance DevOps services/training platform (verify specifics)	Teams seeking practical, project-based help	https://www.devopsfreelancer.com/
devopssupport.in	DevOps support and learning resources (verify specifics)	Ops teams needing troubleshooting-driven learning	https://www.devopssupport.in/

20. Top Consulting Companies

Company	Likely Service Area	Where They May Help	Consulting Use Case Examples	Website URL
cotocus.com	Cloud/DevOps consulting	Cloud migration planning, automation, ops enablement	VM image pipelines, OCI landing zones, lab automation	https://cotocus.com/
DevOpsSchool.com	DevOps and cloud consulting	Delivery, enablement, CI/CD, platform engineering	Terraform-based lab platform, governance/tagging model	https://www.devopsschool.com/
DEVOPSCONSULTING.IN	DevOps consulting services	Implementation support, toolchain integration	Secure bastion setup, cost optimization for training labs	https://devopsconsulting.in/

21. Career and Learning Roadmap

What to learn before Ravello (or Ravello-like VM lab platforms)

Virtualization fundamentals: VMware/VirtualBox concepts, OVF/OVA, VMDK
Networking fundamentals: subnets, routing, firewalls, NAT, SSH/RDP
Linux basics: disk images, boot process, cloud-init basics

What to learn after (modern replacements)

OCI core services:
Compute, VCN, Object Storage, IAM
Monitoring/Logging, Vault, Bastion
Infrastructure as Code:
Terraform on OCI
Image pipelines (Packer or scripted builds)
Platform operations:
Tagging strategy, cost management, policy-as-code approaches

Job roles that use these skills

Cloud engineer (OCI)
DevOps engineer / Platform engineer
SRE (for lab platform reliability and automation)
Solutions architect (migration planning and platform design)
Training lab operations engineer

Certification path (if available)

Ravello-specific certifications are unlikely today due to retirement. For Oracle Cloud, consider OCI certifications (verify current tracks on Oracle’s official certification site).

Project ideas for practice

Build a golden image pipeline and import into OCI
Create a “student lab factory” with Terraform modules and scheduled teardown
Implement bastion-only access and per-student network isolation
Cost-model a 200-student class and optimize shapes and runtimes

22. Glossary

Ravello: Oracle’s (retired) service for modeling and running VM-based application environments on public cloud infrastructure.
Blueprint: A reusable template defining a multi-VM application environment (VMs, networks, resources).
Application/Environment: A deployed, runnable instance created from a blueprint.
Publish location: The target cloud/provider region where an environment runs (historical Ravello concept).
OVA/OVF: VM packaging formats commonly exported from VMware/VirtualBox; OVA is a tar archive containing OVF + disks.
VMDK: VMware virtual disk format commonly found inside OVA packages.
QCOW2: QEMU copy-on-write disk format commonly used for cloud image imports.
OCI: Oracle Cloud Infrastructure.
VCN: Virtual Cloud Network in OCI (your private network in the cloud).
NSG: Network Security Group in OCI; security rules applied to VNICs/instances.
Custom Image: An OCI image you import or create for launching instances.
Golden image: A standardized, hardened base VM image used to create consistent environments.

23. Summary

Ravello on Oracle Cloud was designed to help teams run VM-centric, multi-VM environments—especially labs, demos, and dev/test stacks—by importing VM artifacts and publishing them to cloud capacity. Ravello is now retired, so the practical path forward is to re-create Ravello outcomes using OCI Compute, VCN, Object Storage, and IAM, or to adopt OCI VMware Solution when VMware stack semantics are required.

Key takeaways: – Cost: primary drivers are compute hours, storage footprint of large images, and network egress. – Security: avoid broad public exposure; use least privilege IAM, private subnets, and bastion-based access. – When to use Ravello: only for legacy tenants during transition. – Next step: implement the lab in this guide (OVA → QCOW2 → OCI custom image → instance), then expand into Infrastructure as Code for repeatable, Ravello-like environment provisioning on Oracle Cloud.

rajeshkumar

Category