11 Compute ‐ advanced - KleberVales/OCI-Architect-Associate GitHub Wiki

1. Burstable Instances

1.1 Introduction

1.2 What Are Burstable Instances?

1.3 Key Characteristics

1.4 When Can Bursting Occur?

1.5 Supported Shapes

1.6 Use Cases

1.7 Creating a Burstable Instance

1.8 Pricing

2. Compute Vertical Scaling

2.1 Introduction

2.2 What Is Vertical Scaling?

2.3 Shape Selection Considerations

2.4 What Stays the Same?

2.5 What Changes?

2.6 Automation Possibility

2.7 Important Callouts

3. Compute AutoScaling

3.1 Introduction

3.2 Key Constructs

3.3 Types of Autoscaling Policies

3.4 Steps to Configure Autoscaling

3.5 Example Architecture

4. Oracle Cloud Agent

4.1 Introduction

4.2 What Is Oracle Cloud Agent?

4.3 What Do Plugins Do?

4.4 Requirements for Using Plugins

4.5 Plugin Examples

4.6 Installation

5. Oracle OS Management Hub

5.1 Introduction

5.2 Common Challenges in OS and Patch Management

5.3 Introducing OCI OS Management Hub

6. OS Management Hub - Workflow

6.1 Introduction

6.2 Scenario: Managing Instances in OCI

6.3 The Role of the Management Agent

6.4 Extending to On-Premises and Third-Party Clouds

6.5 Monitoring from the OS Management Hub Console

6.6 Four Key Benefits of OS Management Hub

7. OS Management Hub - Components

7.1 Introduction

7.2 Core Components of OS Management Hub

7.3 Configuring IAM Policies

7.4 Setting Up User Groups

7.5 Setting Up Dynamic Groups

7.6 Required IAM Policies

7.7 Supported OS Platforms

8. OS Management Hub for OCI Instances

8.1 Introduction

8.2 Key Steps Before Registration

9. Run Command

9.1 Introduction

9.2 What Is a Run Command?

9.3 Supported Platforms

9.4 Script Execution Details

9.5 Size Limits

10. Instance Console Connection

10.1 Introduction

10.2 What Is a Console Connection?

10.3 Connection Options

10.4 Types of Instance Console Connections

10.5 Use Cases

11. Infrastructure Maintenance

11.1 Introduction

11.2 Live Migration

11.3 Reboot Migration

11.4 Manual Migration

11.5 Infrastructure Failure Recovery

12. Shielded Instances

12.1 Introduction

12.2 The Threat: Rootkits and Bootkits

12.3 Enabling Shielded Instances

12.4 The Three Components of Shielded Instances

12.5 Secure Boot

12.6 Measured Boot

12.7 Trusted Platform Module (TPM)

13. Confidential Computing

13.1 Introduction

13.2 The Problem Before Confidential Computing

13.3 What Is Confidential Computing?

13.4 Powered by AMD EPYC Processors

13.5 Supported Compute Shapes

13.6 Benefits of Confidential Computing

.
.
.
.
.

1. Burstable Instances

Burstable instances are a cost-effective virtual machine option for workloads with low average CPU usage and occasional spikes. They provide a guaranteed baseline of CPU performance—either 12.5% or 50% of each core—and allow bursting above that baseline when the host has available resources. However, bursting is not guaranteed and depends on the instance's average CPU usage over the past 24 hours. Memory does not burst, only CPU. Supported shapes include VM.Standard3.Flex, VM.Standard.E3.Flex, and VM.Standard.F4.Flex. Creating a burstable instance involves selecting a supported shape, specifying the OCPU count, enabling the burstable option, and setting the baseline. Pricing is based solely on the baseline OCPU, making burstable instances an economical choice for microservices, dev/test environments, CI/CD tools, static websites, and monitoring systems.

1.1 Introduction

In this lesson, we explore the concept of burstable instances—a type of virtual machine instance designed to provide flexibility and cost savings for workloads with variable CPU demands.

1.2 What Are Burstable Instances?

A burstable instance is a virtual machine instance that offers a baseline level of CPU performance with the ability to burst to a higher level when needed to support occasional spikes in usage. These instances are ideal for scenarios where the instance is typically idle or has low CPU utilization, with only occasional increases in demand.

1.3 Key Characteristics

  • Cost-Effective: Burstable instances cost less than regular instances with the same total OCPU count.
  • Baseline CPU Utilization: When creating a burstable instance, you specify:
    • The total OCPU count
    • The baseline CPU utilization, which is a fraction of each CPU core—either 12.5% or 50%
  • Minimum Guaranteed CPUs: The baseline represents the minimum CPU resources that can be used constantly.
  • No Burst Guarantee: If the physical host is oversubscribed, there is no guarantee that the instance will be able to burst.

1.4 When Can Bursting Occur?

The system allows bursting only if the average CPU utilization for the instance has been below the baseline over the last 24 hours.

Important: Memory does not burst—only CPU does.

1.5 Supported Shapes

Not all shapes support burstable instances. Supported shapes include:

  • VM.Standard3.Flex
  • VM.Standard.E3.Flex
  • VM.Standard.F4.Flex

1.6 Use Cases

Burstable instances are well-suited for:

  • Microservices
  • Development and test environments
  • CI/CD tools
  • Static websites
  • Monitoring systems

These workloads typically run at a fraction of CPU capacity most of the time and can burst to full CPUs for limited periods.

1.7 Creating a Burstable Instance

The process is similar to creating an on-demand instance, with a few key differences:

  1. Change the shape to one of the supported burstable shapes.
  2. Specify the number of OCPUs (maximum CPU count).
  3. Select the burstable option.
  4. Set the baseline (e.g., 12.5% or 50%).

1.8 Pricing

Pricing for burstable instances is based on the baseline OCPU. Even if your instance bursts above the baseline, you still pay only for the baseline OCPU.

2. Compute Vertical Scaling

Compute vertical scaling—also known as scaling up or scaling down—allows you to change the shape of a virtual machine instance to add or remove resources without rebuilding instances or redeploying applications. Scaling up increases performance, while scaling down saves costs. When performing vertical scaling, the instance's public and private IP addresses, volume attachments, and VNIC attachments remain unchanged. However, the number of OCPUs, memory, network bandwidth, and maximum number of VNICs are all affected. The target shape you can select depends on the current shape series and image, and if the instance is running during the change, it will be rebooted. You can automate vertical scaling by using the monitoring service to trigger alarms that call functions to adjust the shape as needed. Just remember: scaling a virtual machine will always cause a reboot.

2.1 Introduction

In this lesson, we explore compute vertical scaling—the process of adding or removing resources from an instance to meet changing demand. This is also commonly referred to as scaling up and scaling down.

2.2 What Is Vertical Scaling?

Vertical scaling means you add additional resources to an instance so that it meets demand. It allows you to change the shape of a virtual machine instance without having to rebuild your instances or redeploy your applications.

There are two directions you can scale:

  • Scale Up: Increases performance by adding more resources.
  • Scale Down: Helps you save costs by reducing resources.

As shown in the screenshot, there is an option to edit the shape of your instance.

2.3 Shape Selection Considerations

When changing the shape of an instance, keep in mind:

  • The shape series and image of the original shape determine which shapes you can select as the target for the new shape.

2.4 What Stays the Same?

When you perform vertical scaling, the following remain unchanged:

  • IP address of the instance (both public and private)
  • Volume attachments
  • VNIC attachments

2.5 What Changes?

When a vertical scaling operation is performed, the following are affected:

  • Number of OCPUs
  • Memory
  • Network bandwidth
  • Maximum number of VNICs

Note: If the instance is running when you change the shape, it is rebooted as part of the change shape operation.

2.6 Automation Possibility

You can use the monitoring service to monitor metrics and raise an alarm when a particular metric is met. The alarm notification can then call a function to adjust the shape of the virtual machine as needed—allowing you to automate the vertical scaling process.

2.7 Important Callouts

  1. Automation: Monitoring + alarms + functions can automate shape adjustments.
  2. Reboot Required: Scaling a virtual machine will cause a reboot.

3. Compute AutoScaling

Compute autoscaling relies on two key constructs: instance configurations (templates defining instance settings) and instance pools (groups of instances managed together within a region). An instance configuration can be created from an existing instance or defined manually, and it excludes block volume contents. An instance pool can have only one instance configuration but can be used across multiple pools, and its size can be adjusted manually or automatically. Autoscaling can be metric-based (triggered by performance thresholds) or schedule-based (triggered at specific times). To configure autoscaling, you create an instance configuration, create an instance pool from it, configure the pool (size, instances, load balancers), and define an autoscaling policy. For example, a pool with an initial size of 2, a minimum of 1, and a maximum of 4 can scale out by adding 2 instances when CPU or memory utilization exceeds 70%, and scale in by removing 2 instances when utilization drops below 70%. This ensures consistent performance during high demand while reducing costs during low demand.

3.1 Introduction

In this lesson, we discuss compute autoscaling—the ability to automatically adjust the number of compute instances in a pool based on demand. We will explore the key constructs involved, the types of autoscaling policies, and the steps to configure autoscaling.

3.2 Key Constructs

1. Instance Configuration

An instance configuration is a template that defines the settings to use when creating compute instances.

  • You can use an instance configuration to create one or more instances in an instance pool.
  • You can also use it to create individual instances.
  • Important: It does not include the contents of any block volumes attached to the instance.

You have the option to:

  • Launch an instance from the instance configuration.
  • Create an instance pool from the instance configuration.

Note: To modify an existing instance configuration, you must create a new instance configuration with the desired settings.

When creating an instance configuration, you can either:

  • Use an existing compute instance as a template, or
  • Provide a list of configuration settings.

The instance configuration typically contains:

  • Operating system image
  • Metadata
  • Shape
  • VNICs
  • Storage
  • Subnet information

2. Instance Pool

Instance pools allow you to create and manage multiple compute instances within the same region as a group.

Key points:

  • You can use the same instance configuration for multiple instance pools.
  • However, an instance pool can have only one instance configuration associated with it.
  • After creating an instance pool, you can:
    • Update the size of the pool
    • Add or remove existing instances from the pool
    • Attach or detach load balancers
  • You can adjust the number of instances running in the pool using either metrics or a schedule.

Instances in a pool can be:

  • Deployed in different availability domains
  • Placed behind a load balancer

The whole point of grouping multiple instances together is to manage them as a group.

3.3 Types of Autoscaling Policies

1. Metric-Based Autoscaling

An autoscaling action triggered when a performance metric meets or exceeds a threshold.

Benefits:

  • Provides consistent performance for end users during periods of high demand.
  • Helps reduce costs during periods of low demand.

2. Schedule-Based Autoscaling

An autoscaling event that takes place at specific times that you schedule.

3.4 Steps to Configure Autoscaling

  1. Create the instance configuration.
  2. Create the instance pool from the instance configuration.
  3. Configure the instance pool:
    • Update the size of the pool
    • Add or remove existing instances
    • Attach or detach the load balancer
  4. Define a policy or rule using autoscaling configuration.

3.5 Example Architecture

Consider the following setup:

  • Initial pool size: 2 instances
  • Scaling rule:
    • Add 2 instances if CPU or memory utilization is greater than 70%
    • Remove 2 instances if utilization is below 70%
  • Minimum size: 1 instance
  • Maximum size: 4 instances

When a scale-out event happens, two instances are added to the pool, scaling it from 2 to 4 instances.

4. Oracle Cloud Agent

Oracle Cloud Agent is a lightweight process that manages plugins on compute instances and is installed by default on current platform images. Plugins are installed as part of the agent and are responsible for tasks such as collecting performance metrics, installing OS updates, and performing other instance management functions. To use plugins, the Oracle Cloud Agent software must be installed, and the plugins must be enabled and running. Common plugin examples include the Bastion plugin (required for OCI Bastion service to provide secure, time-limited access to resources without public endpoints), the OSMS plugin (required for the Operating System Management Service to manage patches and updates), and the Compute Instance Run Command plugin (which enables running scripts within the instance). Plugins can be enabled or disabled as needed. While Oracle Cloud Agent is installed by default on current platform images, it can also be manually installed on instances using other supported images.

4.1 Introduction

In this lesson, we explore the Oracle Cloud Agent—a lightweight process that manages plugins running on compute instances. We'll look at what it is, what plugins do, the requirements for using them, and some common plugin examples.

4.2 What Is Oracle Cloud Agent?

Oracle Cloud Agent is a lightweight process that manages plugins running on compute instances.

Key facts:

  • It is installed by default on current platform images.
  • Plugins are installed as part of Oracle Cloud Agent.

4.3 What Do Plugins Do?

Plugins perform a variety of instance management tasks, including:

  • Collecting performance metrics
  • Installing operating system updates
  • Performing other instance management tasks

4.4 Requirements for Using Plugins

To use plugins on an instance, the following conditions must be met:

  1. The Oracle Cloud Agent software must be installed on the instance.
  2. The plugins must be enabled.
  3. The plugins must be running.

4.5 Plugin Examples

1. Bastion

  • OCI provides a service known as OCI Bastion, which offers restricted and time-limited secure access to resources that don't have a public endpoint.
  • To use the Bastion service, you require the Bastion plugin to be enabled and running on the instance.

2. OSMS Agent

  • The Operating System Management Service (OSMS) manages patches and updates for the operating system environment in an instance.
  • To use OSMS, you require the OSMS plugin to be enabled and running.

3. Compute Instance Run Command

  • This plugin facilitates running scripts within the instance using the run command feature.

You can enable or disable a plugin as needed.

4.6 Installation

  • If you create an instance using a current platform image, Oracle Cloud Agent is installed by default.
  • It is also possible to manually install the Oracle Cloud Agent software on an instance that uses another supported image.

5. Oracle OS Management Hub

5.1 Introduction

Oracle OS Management Hub is a centralized cloud solution from Oracle for managing, updating, and monitoring operating systems (such as Oracle Linux) in a unified way.

It solves a major problem for IT administrators: managing security patches, update cycles, and compliance not only on servers running within the OCI itself, but also in hybrid and multi-cloud environments—that is, servers spread across on-premises data centers and even other clouds, such as AWS and Microsoft Azure.

5.2 Common Challenges in OS and Patch Management

1. Managing a Small Number of Instances

Even with just a few compute instances, administrators must handle:

  • Software management and patching — Applications and updates follow different cycles:
    • Oracle, as an OS vendor, releases critical patch updates quarterly.
    • Linux security patches are released frequently and unpredictably as vulnerabilities are discovered.
    • Staying on top of these updates requires constant attention.
  • Reporting security and compliance — Ensuring SLAs are met, generating reports, and maintaining security to meet regulatory standards.
  • Monitoring and assessment — Choosing tools to monitor performance, quickly identify issues, and resolve them.

2. Scaling to Hundreds of Instances

As the number of instances grows:

  • Manually managing patches and compliance becomes time-consuming, error-prone, and a major drain on team resources.
  • Teams end up spending time on repetitive tasks instead of important projects.
  • Risk increases: Missing a single patch or vulnerability can expose the entire system to attack.

3. Expanding Across Environments

When infrastructure spans on-premises and multiple cloud environments, complexity grows due to:

  • A growing number of systems
  • Diverse environments (on-premises, multiple cloud providers, different operating systems)
  • Maintaining security compliance across all systems
  • Lifecycle management — ensuring every system is up to date and running smoothly

As infrastructure grows, a centralized management solution becomes essential—providing a unified view, automating tasks, and simplifying management across all environments.

5.3 Introducing OCI OS Management Hub

OCI OS Management Hub is a management-as-a-service solution designed to simplify and centralize management across your organization.

Key Benefits

Benefit Description
Centralized Management Gain complete control over updates throughout your entire environment, reducing administrative overhead and improving efficiency.
Security and Compliance A clear, consolidated dashboard allows you to monitor compliance, track patch statuses, and review reports to stay proactive and aligned with security standards.
Zero Downtime Updates With Ksplice integration, apply critical Oracle Linux updates without rebooting systems, minimizing downtime and disruption.
Multi-Environment Support Manage systems across OCI, third-party clouds, and on-premises environments from a single unified view.

Supported Environments

No matter where your infrastructure resides—on-premises data centers, OCI, or third-party clouds like Microsoft Azure and AWS—the OS Management Hub supports easy management. It offers tools and resources for Oracle Linux, enhancing your experience and streamlining management.

6. OS Management Hub - Workflow

The OS Management Hub workflow begins by grouping instances that share the same OS type, release, and architecture, enabling centralized and unified management. For each managed instance, a management agent is deployed to gather patch status and compliance data and report it back to the OS Management Hub. When infrastructure expands beyond OCI to on-premises or third-party cloud environments, management stations act as a bridge—mirroring software repositories and locally distributing updates to reduce bandwidth usage. Only the management stations need direct communication with the OCI service, while instances connect to the management station and rely on agents to keep everything in sync. From the OS Management Hub console, administrators can monitor all instances regardless of location, view available security and bug updates, verify communication status, access real-time compliance reports with detailed security advisory information, apply or schedule updates, and download reports for further review. The service offers four key benefits: enhanced security through up-to-date patches, time savings through automation, cost reduction by eliminating third-party tools and reducing administrative needs, and simplified management via a centralized console with grouping and automated updates. Ultimately, OS Management Hub simplifies OS management across diverse environments—on-premises, OCI, or third-party clouds—improving security, saving time, lowering costs, and reducing management complexity.

6.1 Introduction

In this lesson, we explore the workflow of the OS Management Hub service using a simple architecture. We'll look at how instances are grouped, how management agents and management stations work together, and how administrators can monitor and manage their entire environment from a centralized console.

6.2 Scenario: Managing Instances in OCI

Suppose you have a few instances running in OCI that need to be managed. To simplify this process, you can group these instances together—provided they share the same:

  • OS type
  • Release
  • Architecture

This grouping makes it easier to:

  • Manage tasks
  • Apply updates
  • Maintain consistency across your environment

When your instances are grouped, the OS Management Hub service provides centralized, unified management across all your systems. It automates tasks like:

  • Patching
  • Monitoring compliance
  • Ensuring your system stays secure and up to date

This helps reduce manual effort.

6.3 The Role of the Management Agent

For each managed instance, a management agent is deployed.

The agent:

  • Gathers important data about the instance, such as patch status and compliance
  • Sends this data back to the OS Management Hub

This setup enables you to:

  • Easily automate updates
  • Manage patches across all systems
  • Maintain consistency

6.4 Extending to On-Premises and Third-Party Clouds

If your infrastructure expands to include instances not just in OCI but also on-premises or within third-party clouds, OS Management Hub can seamlessly manage all these systems from one centralized location—making it adaptable to your scaling needs.

Management Stations

To make this possible, you deploy one or more management stations, which act as a bridge between your on-premises or cloud instances and the OS Management Hub in OCI.

Key points about management stations:

  • They mirror the software repository and locally distribute updates, reducing bandwidth usage for patching.
  • Only the management stations need to communicate directly with the OCI service.
  • Your instances connect to the management station, receive updates from it, and don't need direct access to the OCI or OS Management Hub service.
  • Management agents are still deployed on both your managed instances and the management station, so the agents keep everything in sync by reporting back to OS Management Hub via the management station.

6.5 Monitoring from the OS Management Hub Console

From the OS Management Hub console, you as an administrator can easily:

  • Monitor the status of all your instances—whether they're on-premises, in a third-party cloud, or within OCI.
  • Get a clear view of available security and bug updates that haven't yet been applied across your managed environment.
  • See a status check to verify that all managed instances are properly communicating with the service.
  • Access real-time reports giving you a comprehensive view of your security patch compliance status.
    • These reports include detailed security advisory information, so you can quickly identify and address vulnerabilities.
  • Apply updates immediately or schedule them for a later time.
  • Download these real-time reports at any time for further review.

6.6 Four Key Benefits of OS Management Hub

Benefit Description
Enhanced Security Ensures your systems stay up to date with the latest security patches and bug fixes, minimizing vulnerabilities and keeping your OS environment secure and reliable.
Time Savings Automation for patching policies and scheduling updates streamlines processes, saving valuable time—especially when managing large-scale deployments.
Cost Reduction As a fully managed service, it reduces the need for additional administrative resources and eliminates the cost associated with third-party management tools, allowing you to achieve more with fewer resources.
Simplified Management Provides a centralized, simplified console to manage instances at scale with grouping for fleet management and automated updates, making large-scale operations easier to handle.

In short, OS Management Hub helps you secure your environment, save time, reduce cost, and simplify management—all from one unified platform.

7. OS Management Hub - Components

The OS Management Hub service relies on several core components: the management station (which mirrors and distributes software and bridges managed instances to the service), profiles (blueprints for consistent system management), software sources (repositories for standardized software), agents (enabling communication between instances and the hub), network configuration (ensuring connectivity and firewall settings), Ksplice (for reboot-free kernel patching), and reports (covering software updates, security vulnerabilities, and system health). To set up OSMH, you must configure IAM policies, starting with user groups (defining who can manage the service), dynamic groups (automatically grouping instances based on compartment rules, including non-OCI instances via management agent resources), and policy statements (granting specific permissions). The required policies include one for dynamic groups (allowing agents to interact with OSMH) and several for the user group (managing all OSMH resources, plus management station permissions for agents and the agent key). Permissions can be scoped at the compartment level, but read access to profiles and software sources must be granted at the tenancy level. Finally, OSMH supports Oracle Linux and specific Windows Server versions in OCI, and Oracle Linux 7, 8, and 9 for on-premises and third-party cloud environments.

7.1 Introduction

In this lesson, we explore the key components of the OS Management Hub (OSMH) service, so you can understand how it works. We will also cover the IAM policies you need to set up this service.

7.2 Core Components of OS Management Hub

OS Management Hub relies on several components, all designed to simplify your OS management tasks. Let's go through each of them.

1. Management Station

Think of it as the central hub located in your data center or third-party cloud environment.

Main roles:

  • Mirroring and distributing software
  • Acting as a bridge between your managed instances and the OS Management Hub service

2. Profiles

These are like blueprints for managing your systems.

  • They define the configurations your instances need
  • Make management consistent and streamlined

3. Software Sources

These specify which repositories your instances should access.

  • Allow you to control and standardize the software across your environment

4. Agents

Software components installed on each instance that you want to manage with OSMH.

  • Enable communication between your instances and the hub

5. Network Configuration

Ensures proper connectivity and firewall settings.

  • So the management station can communicate with both OSMH and the managed instances

6. Ksplice

A tool that lets you apply security patches to your Linux kernel without a reboot.

  • Enhances system availability and security

7. Reports

OS Management Hub provides valuable reports on:

  • Software updates — helping you track the update status across instances
  • Security vulnerabilities — allowing you to identify and resolve potential risks
  • System health — giving you visibility into performance and overall system status

By understanding these core components, you'll be ready to use OSMH to efficiently manage instances across your setup.

7.3 Configuring IAM Policies

To get started with OS Management Hub, the first step is configuring the required IAM policies. These policies ensure that only the right users and compute instances can interact with the service, maintaining security and control.

1. User Groups

These groups define which users or administrators can access and manage OS Management Hub components, ensuring the right people have the appropriate permissions.

2. Dynamic Groups

Allows you to group instances automatically based on defined rules, enabling flexible management for OS Management Hub.

3. Policy Statements

These provide the specific permissions and actions that users, groups, and instances can perform within the service.

7.4 Setting Up User Groups

You'll need to create a user group—let's call it OS Management Hub admins—or use an existing group for users who will manage the OS Management Hub.

  • This group will have the necessary permissions to administer the service across your tenancy.
  • If you want more control, you can create additional user groups with more restrictive policies.
    • This allows you to grant access to specific resources or functions within the OS Management Hub as needed, giving you precise management capabilities for different users or teams.

7.5 Setting Up Dynamic Groups

Dynamic groups define the specific resources that OS Management Hub will manage, including both:

  • OCI instances
  • Non-OCI instances (like those on-premises or in third-party clouds)

How It Works

  • The dynamic group will include managed instances based on rule statements that define the compartments or subcompartments where these instances are located.
  • This group will automatically grow or shrink as instances are added or retired within the specified compartments, ensuring the managed resources are always up to date.
  • For non-OCI instances, each rule statement should include a management agent resource in the designated compartment. This ensures that all non-OCI instances in the compartment are covered by the OS Management Hub service.

7.6 Required IAM Policies

Policy for Dynamic Groups

  • Allows agents on managed instances to interact with the OS Management Hub service.
  • The policy statement has managed instance access permission that allows agents the access they need.

Policies for the User Group That Manages the Service

Policy Purpose
First Policy Grants the user group permission to manage all OS Management Hub resources across the tenancy.
Second & Third Policies For the management station, allowing users to manage management agents and the agent key within the tenancy.

Note: You can also scope these permissions at the compartment level. If you do, ensure that read access to profiles and software sources is granted at the tenancy level—this is needed to replicate software sources and use service-provided profiles.

7.7 Supported OS Platforms

One important thing to note before you start is the supported OS platforms:

Environment Supported Platforms
OCI Oracle Linux and specific Windows Server versions
On-Premises & Third-Party Clouds Oracle Linux versions 7, 8, and 9

8. OS Management Hub for OCI Instances

Configuring OS Management Hub for OCI instances involves a structured workflow. First, network configuration must be verified—private subnets require a service gateway (with the All region label) or NAT gateway, public subnets require an internet gateway, and Windows instances need security rules allowing access to Windows update servers. Second, software sources must be set up, with at least one vendor software source required before registration. There are three types: vendor (basic vendor repository), custom (vendor base with package filters), and versioned custom (immutable, version-specific for lifecycle consistency). Third, profiles are configured as templates defining software sources, lifecycle stage membership, and group membership—applied only during registration and location-specific. Finally, registration involves three steps: creating the instance with proper network gateways, enabling the OS Management Hub agent plugin from Oracle Cloud Agent (selecting a profile during activation), and verifying the Oracle Cloud Agent version to ensure compatibility. Once complete, the instance appears as a managed instance in the OS Management Hub service within minutes.

8.1 Introduction

In this lesson, we will see how to configure the OS Management Hub (OSMH) service for OCI instances. We will walk through a step-by-step workflow to register an instance with the service, making it easy to understand and implement.

Scenario: Suppose you want to manage four compute instances in your working compartment with the OSMH service. We will assume:

  • The service is enabled in your tenancy.
  • All required IAM policies and dynamic groups are already in place.

8.2 Key Steps Before Registration

Before you create and register compute instances with the OSMH service, there are a few key steps to follow:

  1. Verify the network configuration to ensure connectivity and access.
  2. Set up software sources and profiles to standardize how your instances receive updates and patches.
  3. Create and register your compute instances with the service.

Step 1: Network Configuration

First, we need to make sure the network is set up correctly to support OS Management Hub resources for OCI instances.

Instance Location Required Configuration
Private Subnet Connect to a VCN that has a service gateway with the All region label in the Oracle Services network. Alternatively, configure a NAT gateway for that VCN to enable outbound internet access.
Public Subnet Configure an internet gateway to ensure your instances can communicate with the required external services.
Windows Instances Set up security lists or network rules that allow access to Windows update servers. Open the necessary ports and IP addresses in your security list or network security groups for Windows updates to function properly.

Step 2: Software Sources

Software sources are the first level of control over the content available to instances managed by the OS Management Hub service.

  • You must add at least one vendor software source before registering any instances with the service.
  • A software source is a collection of packages and modules similar to repositories used for updates.
  • Once added to OS Management Hub, it is available across all compartments, regions, and management stations.
  • This helps administrators control which packages can be installed on instances without having to set up repositories manually.

Three Main Types of Software Sources

Type Description
Vendor The most basic type—a repository of all software provided by the OS vendor. It serves as the foundation for all other software sources. You need at least one vendor software source added to your compartment before registering instances.
Custom Offers more flexibility. Start with a vendor software source as your base, then apply filters to include or exclude specific packages. Useful when you want to control exactly what is available to your instances.
Versioned Custom Works similarly to a custom software source, but is assigned a specific version number. Once created, you cannot modify its contents. Perfect for managing software across different lifecycle environments (development, testing, production).

Step 3: Configuring Profiles

Profiles help simplify and standardize the process of registering your instances. Instead of manually configuring each instance, you can use a profile to automatically apply the same settings to multiple instances at once.

Think of profiles as templates that define settings such as:

  • Software sources — the locations from which software updates and packages are retrieved and made available to managed instances.
  • Lifecycle stage membership — defines where an instance fits within a lifecycle environment (development, testing, or production).
  • Group membership — allows you to assign instances to specific groups, making it easier to manage and update them together.

Important Notes:

  • Profiles only impact instances during the registration process. Once an instance is registered, the profile no longer affects it.
  • Profiles are location-specific, meaning you cannot use a profile created for Oracle Cloud OCI on an instance in your own data center.

Step 4: Registering Your Instance

The registration process has three main steps:

1. Create the Instance

  • Create the instance based on your required configuration.
  • Ensure network setup is configured with the required gateways (service gateways for private subnets or internet gateways for public subnets).

2. Enable the OS Management Hub Agent

  • From Oracle Cloud Agent, activate the OS Management Hub agent plugin.
  • This plugin allows communication between your instance and the OS Management Hub service.
  • During activation, you will select a profile for your instance.
    • This profile automatically applies all necessary configurations, including software sources, lifecycle stage membership, and group membership.
  • Once completed, your instance becomes ready for centralized management and will appear as a managed instance in the OS Management Hub service.

3. Verify the Oracle Cloud Agent Version

  • Running a specific command to install or update to the latest version ensures compatibility.
  • This is useful for registering existing OCI instances with the OS Management Hub service.
  • Once you've confirmed the agent version, you can enable the OS Management Hub agent plugin.
  • Within a few minutes, your instance will appear in the list of Managed Instances, ready to be managed through the OS Management Hub service.

9. Run Command

Run command is a feature that allows you to remotely configure, manage, and troubleshoot compute instances by running scripts within the instance—even when the instance does not have SSH access or open inbound ports. It is supported on platform images including Oracle Autonomous Linux, Oracle Linux, CentOS, and Windows Server, but not Ubuntu. On Linux instances, scripts run in a bash shell by default, while on Windows instances they run as a batch file. There are size limits to be aware of: script files uploaded directly in plain text are limited to 4 KB (use object storage for larger files), and plain text script output is limited to the last 1 KB (again, use object storage for larger responses). Common use cases include automating tasks like configuring secondary VNICs and troubleshooting SSH connectivity.

9.1 Introduction

In this lesson, we will talk about run command. So let's get started.

9.2 What Is a Run Command?

Using run command, you can remotely configure, manage, and troubleshoot compute instances by running scripts within the instance.

Key capability:

  • You can run commands on an instance even when the instance does not have SSH access or open inbound ports.

9.3 Supported Platforms

The run command feature is supported on compute instances that use platform images.

Supported Not Supported
Oracle Autonomous Linux Ubuntu
Oracle Linux
CentOS
Windows Server

9.4 Script Execution Details

Instance Type Script Runs As
Linux Bash shell (by default)
Windows Batch file

9.5 Size Limits

Item Limit Workaround
Script file uploaded directly in plain text 4 KB maximum Save the file in an object storage location to provide a larger file.
Script output written as plain text Last 1 KB Save the output to an object storage location to save a larger response.

Examples of Use Cases

  • Automate tasks, such as configuring secondary virtual network interface cards (VNICs).
  • Troubleshoot SSH connectivity.

10. Instance Console Connection

Instance console connection provides a display of what is happening during the boot process, allowing you to remotely troubleshoot malfunctioning instances—it is a special case intended for troubleshooting, not normal operations. There are two connection options: Cloud Shell connection (which automatically creates the console connection and a temporary SSH key) and local connection (which requires generating an SSH key pair or uploading your own public key). There are two types of console connections: serial console connection, used mainly for Linux servers and CLI-based operating systems and accessed via SSH, and VNC console connection, used for servers with a graphical user interface and accessed by setting up a secure tunnel to the VNC server and connecting with a VNC client. Note that Cloud Shell can only be used for serial console connections, not VNC. Use cases include editing system configuration files, adding or resetting SSH keys for the OPC user, troubleshooting imported or customized images that fail to boot, and recovering instances that suddenly stop responding.

10.1 Introduction

In this lesson, we will look at instance console connection. So let's get started.

10.2 What Is a Console Connection?

The idea of a console connection is to give you a display of what is happening during the boot process. This allows you to remotely troubleshoot malfunctioning instances.

Important: This is a special case—you do not use it for normal operations, but for troubleshooting.

10.3 Connection Options

There are two options for creating a console connection:

1. Cloud Shell Connection

  • The Cloud Shell integration automatically creates the instance console connection and the temporary SSH key.

2. Local Connection

  • When you create a local connection, you need to generate an SSH key pair, or you can upload your own public key.

10.4 Types of Instance Console Connections

1. Serial Console Connection

  • Mainly used for Linux servers and other CLI-based operating systems.
  • After you create the console connection for the instance, you can connect to the serial console using a Secure Shell (SSH) connection.

2. VNC Console Connection

  • Commonly used for connecting to servers that have a graphical user interface (GUI).
  • You need to set up a secure tunnel to the VNC server on the instance, and then you can connect with a VNC client.

Note: You cannot use Cloud Shell for VNC console connections. You can only use it for serial console connections.

10.5 Use Cases

Once you are connected with an instance console connection, you can perform tasks such as:

  • Editing system configuration files
  • Adding or resetting the SSH keys for the OPC user

Troubleshooting Scenarios

  • An imported or customized image that is not booting successfully
  • An instance that was working fine but suddenly stops responding

In these scenarios, you can make use of instance console connections for troubleshooting.

11. Infrastructure Maintenance

Infrastructure maintenance is a necessary part of any environment, and OCI performs routine maintenance on physical infrastructure for VM instances while offering three migration options to minimize inconvenience: live migration, reboot migration, and manual migration. Live migration moves supported VM instances from a host needing maintenance to a healthy host with minimal disruption—it emits maintenance events at start and end, is only supported by Linux operating systems, and is restricted to specific shapes. If live migration isn't supported, OCI schedules a reboot migration due date within 14 to 16 days and sends a notification; if you don't proactively reboot before the due date, the instance is stopped, migrated, and restarted, with a short downtime you can control by rebooting proactively. Note that rebooting the operating system does not trigger migration—only rebooting the instance from the Console, CLI, or API does. Manual migration is sometimes required for instances without a reboot maintenance date, requiring termination and recreation (preserve the boot volume). When infrastructure fails, standard VMs are recovered via reboot migration to a healthy host, while dense I/O VMs are recovered by rebooting on the same host; if that's not possible, OCI notifies you to delete the instance within 14 days, after which it disables and deletes it within seven more days—though boot volumes and remote-attached data volumes are preserved.

11.1 Introduction

In this lesson, we will look at infrastructure maintenance. So let's get started.

Maintenance is a necessary part of any environment. Oracle Cloud Infrastructure (OCI) also performs routine maintenance on the physical infrastructure for virtual machine instances. OCI strives to minimize this inconvenience by offering different options to relocate virtual machines:

  1. Live migration
  2. Reboot migration
  3. Manual migration

11.2 Live Migration

During an infrastructure maintenance event, OCI live migrates supported virtual machine instances from the physical VM host that needs maintenance to a healthy VM host.

Key points:

  • There is minimal disruption to running instances.
  • When a live migration begins and ends, an infrastructure maintenance event is emitted.
  • Live migration is only supported by Linux operating systems and restricted to specific shapes.

11.3 Reboot Migration

If the virtual machine instance does not support live migration, OCI schedules a due date for reboot migration within 14 to 16 days and sends you a notification.

Key points:

  • If you do not proactively reboot the instance before the due date, the instance is stopped and migrated to a healthy host and restarted.
  • There is a short downtime during the migration.
  • You can control when the downtime occurs by proactively reboot migrating the instance before the maintenance due date.

Important Callout: Rebooting the operating system is not the same as rebooting the instance from the Console, CLI, or API. The operating system reboot does not trigger the migration.

11.4 Manual Migration

Despite all efforts, sometimes a manual migration will be required.

Key points:

  • For instances without a date in the reboot maintenance field, you must move the instance manually.
  • In this scenario, the instance will need to be terminated and recreated.
  • When it is time to terminate, don't forget to preserve the boot volume.

11.5 Infrastructure Failure Recovery

When the underlying infrastructure of a virtual machine instance fails, OCI automatically attempts to recover the instance.

Instance Type Recovery Method
Standard VM Instances Recovered using reboot migration, which automatically restores the VM on a healthy host.
Dense I/O VMs Recovered by rebooting the instance on the same physical host.

If Recovery on the Same Host Is Not Possible (Dense I/O VMs)

  • OCI notifies you to delete or terminate the instance within 14 days.
  • If you don't delete the instance before the deadline, OCI disables the instance on the deadline and deletes it within the next seven days.
  • However, the boot volume and remote-attached data volumes are preserved.

12. Shielded Instances

Shielded instances protect virtual machines and bare metal instances against low-level threats like Rootkits and Bootkits, which have kernel-level privileges, can infect firmware and the operating system, and are very difficult to detect. Enabling shielded instances follows the standard instance deployment flow—simply choose an image and shape with a shield icon, then enable Secure Boot and Measured Boot in the advanced options (enabling Measured Boot for VMs automatically enables TPM). Shielded instances combine three components: Secure Boot (a UEFI feature that prevents unauthorized, unsigned bootloaders and operating systems from booting), Measured Boot (which stores measurements of boot components like bootloaders, drivers, and operating systems, and verifies they don't change between boots), and Trusted Platform Module (a specialized security chip used by Measured Boot to securely store boot measurements in Platform Configuration Registers, or PCRs, which summarize all measurement results). Secure Boot and TPM are available on all supported bare metal and VM instances, while Measured Boot is only available on VM instances—and all these services are provided for the OCI platform at no charge.

12.1 Introduction

In this lesson, we will look at shielded instances. So let's get started.

12.2 The Threat: Rootkits and Bootkits

Threats like Rootkits and Bootkits that have kernel-level privileges can:

  • Infect the firmware and operating system
  • Be very difficult to detect

Shielded instances protect virtual machines and bare metal instances against these low-level threats.

12.3 Enabling Shielded Instances

Enabling shielded instances is simple—you need to follow the standard instance deployment flow.

Key points:

  • Images and shapes that support shielded instances have a shield icon next to the image and shape.
  • When you choose an image and shape that support shielded instances, you can enable Secure Boot and Measured Boot in the advanced options.
  • Enabling Measured Boot for virtual machines automatically enables Trusted Platform Module (TPM) as well.

12.4 The Three Components of Shielded Instances

A shielded instance uses a combination of:

  1. Secure Boot
  2. Measured Boot
  3. Trusted Platform Module (TPM)

Availability

Feature Availability
Secure Boot All supported bare metal and virtual machine instances
Trusted Platform Module All supported bare metal and virtual machine instances
Measured Boot Only VM instances

These services are provided for the OCI platform at no charge.

12.5 Secure Boot

Secure Boot is a Unified Extensible Firmware Interface (UEFI) feature that prevents unauthorized bootloaders and operating systems from booting.

Key point:

  • Boot components that are not properly signed are not allowed to run, preventing the system from booting.

12.6 Measured Boot

Measured Boot complements and enhances Secure Boot by:

  • Storing measurements of boot components, such as:
    • Bootloaders
    • Drivers
    • Operating systems
  • Verifying that these measurements don't change from one boot to the next.

12.7 Trusted Platform Module (TPM)

Trusted Platform Module is a specialized security chip that is used by Measured Boot to store the boot measurements securely.

Key points:

  • Enabling Measured Boot for virtual machines automatically enables the virtual Trusted Platform Module.
  • Measurements taken by Measured Boot are stored in Platform Configuration Registers (PCRs) inside the Trusted Platform Module.
  • A PCR is a memory location in the TPM that is used to hold a value that summarizes all the measurement results.

13. Confidential Computing

Confidential computing takes encryption to the next level by securing data while it is loaded in memory, not just at rest or in transit—previously, all data running in memory was accessible as clear text. It protects data in use at the hardware level by encrypting and isolating both the data and the application processing it, preventing unauthorized access or modification. It also minimizes the list of trusted parties (operating system, ecosystem partners, administrators), reducing the risk of data exposure. Powered by AMD EPYC processors, confidential computing enables confidential virtual machines via Secure Encrypted Virtualization (SEV) and confidential bare metal servers via Secure Memory Encryption (SME)—features of AMD Infinity Guard available in second and third generation AMD EPYC processors in all OCI E3 and E4 shapes. Supported VM shapes include VM.Standard.E4.Flex and VM.Standard.E3.Flex (on Oracle Linux 7.x or 8.x platform images), while supported bare metal shapes include BM.DenseIO.E4.128, BM.Standard.E4.128, and BM.Standard.E3.128 (on any platform image). The key benefits are: improved isolation using real-time encryption with a per-VM key generated at VM creation that resides solely in the AMD secure processor and is inaccessible to any application, hypervisor, or OCI; no application changes required; and little to no performance impact.

13.1 Introduction

Hello and welcome. Let's talk about Confidential Computing.

13.2 The Problem Before Confidential Computing

Prior to the arrival of confidential computing, all data running in memory was accessible as clear text.

Today, there are a range of processor families that enable data to be encrypted while running in memory.

13.3 What Is Confidential Computing?

Confidential computing promises to take encryption to the next level by securing data while it is loaded in memory—not just at rest or in transit.

Key points:

  • It minimizes the list of trusted parties (operating system, ecosystem partners, or administrators), thereby helping reduce the risk of data exposure.
  • It protects data in use at the hardware level.
  • Both the data and the application processing the data are encrypted and isolated while the application processes the data.
  • This prevents unauthorized access or modification of either the data or the application.

13.4 Powered by AMD EPYC Processors

Confidential computing is powered by AMD EPYC processors, allowing customers to enable:

Offering AMD Feature
Confidential Virtual Machines Secure Encrypted Virtualization (SEV)
Confidential Bare Metal Servers Secure Memory Encryption (SME)

These features are part of AMD Infinity Guard and take advantage of security components available in second and third generation AMD EPYC processors, available in all OCI E3 and E4 shapes.

13.5 Supported Compute Shapes

Virtual Machine Compute Shapes

  • VM.Standard.E4.Flex
  • VM.Standard.E3.Flex

Supported on: Oracle Linux 7.x or 8.x platform images.

Bare Metal Instance Compute Shapes

  • BM.DenseIO.E4.128
  • BM.Standard.E4.128
  • BM.Standard.E3.128

Supported on: Any platform image.

13.6 Benefits of Confidential Computing

1. Improved Isolation Using Real-Time Encryption

  • Data and applications are encrypted using a per-VM encryption key generated during VM creation.
  • The key resides solely in the AMD secure processor, which is part of the CPU.
  • The key is not accessible from any application—whether the VM, the instance, the hypervisor, or Oracle Cloud Infrastructure.

2. No Application Changes Required

  • If you want to enable confidential VMs, you don't require any change in the application.

3. Little to No Performance Impact

  • Applications experience little to no performance impact with confidential computing enabled.