Manage VM Clusters

Learn how to manage your VM clusters on Oracle Exadata Database Service on Cloud@Customer.

About Managing VM Clusters on Oracle Exadata Database Service on Cloud@Customer

The VM cluster provides a link between your Oracle Exadata Database Service on Cloud@Customer infrastructure and Oracle Databases you deploy.

The VM cluster contains an installation of Oracle Clusterware, which supports databases in the cluster. In the VM cluster definition, you also specify the number of enabled CPU cores, which determines the amount of CPU resources that are available to your databases

Before you can create any databases on your Exadata Cloud@Customer infrastructure, you must create a VM cluster network, and you must associate it with a VM cluster.

Note

Avoid entering confidential information when assigning descriptions, tags, or friendly names to your cloud resources through the Oracle Cloud Infrastructure Console, API, or CLI.

Overview of VM Cluster Node Subsetting

VM Cluster Node Subsetting enables you to allocate a subset of database servers to new and existing VM clusters to enable maximum flexibility in the allocation of compute (CPU, memory, local storage) resources.

With VM Cluster Node Subsetting, you can:
  • Create a smaller VM cluster to host databases that have low resource and scalability requirements or to host a smaller number of databases that require isolation from the rest of the workload.
  • Expand or shrink an existing VM cluster by adding and removing nodes to ensure optimal utilization of available resources.
Consider reviewing the points below that will assist you in subsetting VM cluster nodes.
  • VM Cluster Node Subsetting capability is available for new and existing VM clusters in Gen2 Exadata Cloud@Customer service.
  • All VMs across a VM cluster will have the same resource allocation per VM irrespective of whether the VM was created during cluster provisioning or added later by extending an existing VM cluster.
  • VM Clusters only need a minimum of 1 VM with node subsetting. However, Oracle recommends a minimum of 2 VMs per VM Cluster to provide high availability.
  • Each VM cluster network is pre-provisioned with IP addresses for every DB Server in the infrastructure. One cluster network can only be used by a single VM cluster and is validated to ensure the IP addresses do not overlap with other cluster networks. Adding or removing VMs to the cluster does not impact the pre-provisioned IP addresses assigned to each DB server in the associated cluster network.

For the Maximum number of VMs per DB server and Maximum number of VM Clusters per System, see the System Shape and Configuration Tables. The Maximum number of VM Clusters per System depends on the resources available per DB server and is subject to the per DB Server maximum VM limit.

Note

When a cluster contains a node-subsetted database, the attributed usage and cost feature for pluggable databases will not work because the process of creating node-subsetted databases happens on the backend, and the metadata for node-subsetted databases doesn't get synchronized with the Control Plane Server.

However, if the database was originally created without using node-subsetting and later converted to a node-subsetted database, this issue will not arise since the metadata is already available in the Control Plane.

Overview of Automatic Diagnostic Collection

By enabling diagnostics collection and notifications, Oracle Cloud Operations and you will be able to identify, investigate, track, and resolve guest VM issues quickly and effectively. Subscribe to Events to get notified about resource state changes.

  • Enable Diagnostic Events

    Allow Oracle to collect and publish critical, warning, error, and information events to you. For more information, see Database Service Events.

  • Enable Health Monitoring

    Allow Oracle to collect health metrics/events such as Oracle Database up/down, disk space usage, and so on, and share them with Oracle Cloud operations. You will also receive notification of some events. For more information, see Health Metrics.

  • Enable Incident Logs and Trace Collection

    Allow Oracle to collect incident logs and traces to enable fault diagnosis and issue resolution. For more information, see Incident Logs and Trace Files.

Diagnostics Collection is:

  • Enabled: When you choose to collect diagnostics, health metrics, incident logs, and trace files (all three options).
  • Disabled: When you choose not to collect diagnostics, health metrics, incident logs, and trace files (all three options).
  • Partially Enabled: When you choose to collect diagnostics, health metrics, incident logs, and trace files (one or two options).

Disabling diagnostic events and health monitoring will only stop the collection and notification of data/events from the time you uncheck the checkboxes tied to the options. However, historical data will not be purged from Oracle Cloud Operations data repositories.

Incident Logs and Trace Files

This section lists all of the files that can be collected by Oracle Support if you opt-in for incident logs and trace collection.

Note

  • Oracle will create a service request (SR) against the infrastructure Customer Support Identifier (CSI) when an issue is detected and needs customer interaction to resolve.
  • The customer's Oracle Cloud Infrastructure tenancy admin email will be used as the CSI contact to create SR and attach logs to it. Ensure tenancy admin is added as a CSI contact in My Oracle Support (MOS).

Oracle Trace File Analyze (TFA) Component Driven Logs Collections

The directories are generally assigned to a component and that component can then be used to guide TFA to the files it needs to collect, for example, requesting the CRS component would tell TFA to look at directories mapped to the CRS component and find files that match the required collection time frame.

Note

If have previously opted in for incident log and trace file collection and decide to opt out when Oracle Cloud operations run a log collection job, then the job will run its course and will not cancel. Future log collections won't happen until you opt-in again to the incident logs and trace file collection option.

TFA is shipped with scripts that run when a particular component is requested, for example, for CRS component, crscollect.pl will run a number of crsctl commands and gather the input. By default, TFA does not redact collected logs.

Table 5-12 Oracle Trace File Analyze (TFA) Component Driven Logs Collections

Component Script Files/Directories

OS: Operating system logs

oscollect.pl

  • /var/log/messages
  • OSWatcher archive
  • Exadata Only: ExaWatcher archive

    /opt/oracle.ExaWatcher/archive/

CRS: Grid Infrastructure and cluster logs

crscollect.pl

  • /etc/oracle
  • GIHOME/crf/db/HOSTNAME1
  • GIHOME/crs/log
  • GIHOME/css/log
  • GIHOME/cv/log
  • GIHOME/evm/admin/log
  • GIHOME/evm/admin/logger
  • GIHOME/evm/log
  • GIHOME/log/-/client
  • GIHOME/log/HOSTNAME1
  • GIHOME/log/HOSTNAME1/admin
  • GIHOME/log/HOSTNAME1/client
  • GIHOME/log/HOSTNAME1/crflogd
  • GIHOME/log/HOSTNAME1/crfmond
  • GIHOME/log/HOSTNAME1/crsd
  • GIHOME/log/HOSTNAME1/cssd
  • GIHOME/log/HOSTNAME1/ctssd
  • GIHOME/log/HOSTNAME1/diskmon
  • GIHOME/log/HOSTNAME1/evmd
  • GIHOME/log/HOSTNAME1/gipcd
  • GIHOME/log/HOSTNAME1/gnsd
  • GIHOME/log/HOSTNAME1/gpnpd
  • GIHOME/log/HOSTNAME1/mdnsd
  • GIHOME/log/HOSTNAME1/ohasd
  • GIHOME/log/HOSTNAME1/racg
  • GIHOME/log/HOSTNAME1/srvm
  • GIHOME/log/HOSTNAME1/xag
  • GIHOME/log/diag/asmtool
  • GIHOME/log/diag/clients
  • GIHOME/log/procwatcher/PRW_SYS_HOSTNAME1
  • GIHOME/network/log
  • GIHOME/opmn/logs
  • GIHOME/racg/log
  • GIHOME/scheduler/log
  • GIHOME/srvm/log
  • GRIDBASE/crsdata/@global/cvu
  • GRIDBASE/crsdata/HOSTNAME1/core
  • GRIDBASE/crsdata/HOSTNAME1/crsconfig
  • GRIDBASE/crsdata/HOSTNAME1/crsdiag
  • GRIDBASE/crsdata/HOSTNAME1/cvu
  • GRIDBASE/crsdata/HOSTNAME1/evm
  • GRIDBASE/crsdata/HOSTNAME1/output
  • GRIDBASE/crsdata/HOSTNAME1/ovmmwallets
  • GRIDBASE/crsdata/HOSTNAME1/scripts
  • GRIDBASE/crsdata/HOSTNAME1/trace
  • GRIDBASE/diag/crs/-/crs/cdump
  • GRIDBASE/diag/crs/HOSTNAME1/crs/cdump
  • GRIDBASE/diag/crs/HOSTNAME1/crs/incident
  • GRIDBASE/diag/crs/HOSTNAME1/crs/trace

Database: Oracle Database logs

No DB Specific Script - runs opatch lsinventory for the ORACLE_HOME the DB runs from TFA will run ipspack based on the time range for certain DB incidents.

  • ORACLE_BASE/diag/rdbms/<dbname>/<instance_name>/cdump
  • ORACLE_BASE/diag/rdbms/<dbname>/<instance_name>/trace
  • ORACLE_BASE/diag/rdbms/<dbname>/<instance_name>/incident

Cloud Tool Logs

  • Creg files: /var/opt/oracle/creg/*.ini files with masked sensitive info
  • Cstate file: /var/opt/oracle/cstate.xml
  • Database related tooling logs:

    If dbName specified, /var/opt/oracle/log/<dbName>, else collect logs for all databases /var/opt/oracle/log/

    If dbName specified, /var/opt/oracle/dbaas_acfs/log/<dbName>, else collect logs for all databases /var/opt/oracle/log/<dbName>

  • Database env files: If dbName specified, /home/oracle/<dbName>.env, else collect logs for all databases /home/oracle/*.env
  • Pilot logs: /home/opc/.pilotBase/logs
  • List of log directories:
    • /var/opt/oracle/log
    • /var/opt/oracle/dbaas_acfs/log
    • /var/opt/oracle/dbaas_acfs/dbsystem_details
    • /var/opt/oracle/dbaas_acfs/job_manager
    • /opt/oracle/dcs/log

DCS Agent Logs

  • /opt/oracle/dcs/log/

Tooling-Related Grid Infrastructure/Database Logs

  • Grid Infrastructure: GI_HOME/cfgtoollogs
  • Database alertlog: /u02/app/oracle/diag/rdbms/*/*/alert*.log

Health Metrics

Review the list of database and non-database health metrics collected by Oracle Trace File Analyzer.

Note

Oracle may add more metrics in the future, but if you have already chosen to collect metrics, you need not update your opt-in value. It will remain enabled/disabled based on your current preference.

Guest VM Health Metrics List - Database Metrics

Table 5-13 Guest VM Health Metrics List - Database Metrics

Metric Name Metric Display Name Unit Aggregation Interval Collection Frequency Description

CpuUtilization

CPU Utilization

Percentage

Mean

One minute

Five minutes

The CPU utilization is expressed as a percentage, which is aggregated across all consumer groups. The utilization percentage is reported with respect to the number of CPUs the database is allowed to use, which is two times the number of OCPUs.

StorageUtilization

Storage Utilization

Percentage

Mean

One hour

One hout

The percentage of provisioned storage capacity currently in use. Represents the total allocated space for all tablespaces.

BlockChanges

DB Block Changes

Changes per second

Mean

One minute

Five minutes

The Average number of blocks changed per second.

ExecuteCount

Execute Count

Count

Sum

One minute

Five minutes

The number of user and recursive calls that executed SQL statements during the selected interval.

CurrentLogons

Current Logons

Count

Sum

One minute

Five minutes

The number of successful logons during the selected interval.

TransactionCount

Transaction Count

Count

Sum

One minute

Five minutes

The combined number of user commits and user rollbacks during the selected interval.

UserCalls

User Calls

Count

Sum

One minute

Five minutes

The combined number of logons, parses, and execute calls during the selected interval.

ParseCount

Parse Count

Count

Sum

One minute

Five minutes

The number of hard and soft parses during the selected interval.

StorageUsed

Storage Space Used

GB

Max

One hour

One hour

Total amount of storage space used by the database at the collection time.

StorageAllocated

Storage Space Allocated

GB

Max

One hour

One hour

Total amount of storage space allocated to the database at the collection time.

StorageUsedByTablespace

Storage Space Used By Tablespace

GB

Max

One hour

One hour

Total amount of storage space used by tablespace at the collection time. In the case of container databases, this metric provides root container tablespaces.

StorageAllocatedByTablespace

Allocated Storage Space By Tablespace

GB

Max

One hour

One hour

Total amount of storage space allocated to the tablespace at the collection time. In the case of container databases, this metric provides root container tablespaces.

StorageUtilizationByTablespace

Storage Space Utilization By Tablespace

Percentage

Mean

One hour

One hour

This indicates the percentage of storage space utilized by the tablespace at the collection time. In the case of container databases, this metric provides root container tablespaces.

Guest VM Health Metrics List - Non-Database Metrics

Table 5-14 Guest VM Health Metrics List - Non-Database Metrics

Metric Name Metric Display Name Unit Aggregation Collection Frequency Description

ASMDiskgroupUtilization

ASM Diskgroup Utilization

Percentage

Max

10 minutes

Percentage of usable space used in a Disk Group. Usable space is the space available for growth. DATA disk group stores our Oracle database files. RECO disk group contains database files for recovery such as archives and flashback logs.

FilesystemUtilization

Filesystem Utilization

Percentage

Max

One minute

Percent utilization of provisioned filesystem.

CpuUtilization

CPU Utilization

Percentage

Mean

One minute

Percent CPU utilization.

MemoryUtilization

Memory Utilization

Percentage

Mean

One minute

Percentage of memory available for starting new applications, without swapping. The available memory can be obtained via the following command: cat /proc/meminfo.

SwapUtilization

Swap Utilization

Percentage

Mean

One minute

Percent utilization of total swap space.

LoadAverage

Load Average

Number

Mean

One minute

System load average over 5 minutes.

NodeStatus

Node Status

Integer

Mean

One minute

Indicates whether the host is reachable.

OcpusAllocated

OCPU Allocated

Integer

Max

One minute

The number of OCPUs allocated.

Introduction to Scale Up or Scale Down Operations

With the Multiple VMs per Exadata system (MultiVM) feature release, you can scale up or scale down your VM cluster resources.

Scaling Up or Scaling Down the VM Cluster Resources

You can scale up or scale down the memory, local disk size (/u02), ASM Storage, and CPUs.

Note

Oracle doesn't stop billing when a VM or VM Cluster is stopped. To stop billing for a VM Cluster, lower the OCPU count to zero.

Scaling up or down of these resources requires thorough auditing of existing usage and capacity management by the customer DB administrator. Review the existing usage to avoid failures during or after a scale down operation. While scaling up, consider how much of these resources are left for the next VM cluster you are planning to create. Exadata Cloud@Customer Cloud tooling calculates the current usage of memory, local disk, and ASM storage in the VM cluster, adds headroom to it, and arrives at a "minimum" value below which you cannot scale down, and expects that you specify the value below this minimum value.

Note

  • When creating or scaling a VM Cluster, setting the number of OCPUs to zero will shut down the VM Cluster and eliminate any billing for that VM Cluster, but the hypervisor will still reserve the minimum 2 OCPUs for each VM. These reserved OCPUs cannot be allocated to any other VMs, even though the VM to which they are allocated is shut down. The Control Plane does not account for reserved OCPUs when showing maximum available OCPU, so you should account for these reserved OCPU when performing any subsequent scaling operations to ensure the operation can acquire enough OCPUs to successfully complete the operation.
  • For memory and /u02 scale up or scale down operations, if the difference between the current value and the new value is less than 2%, then no change will be made to that VM. This is because memory change involves rebooting the VM, and /u02 change involves bringing down the Oracle Grid Infrastructure stack and un-mounting /u02. Productions customers will not resize for such a small increase or decrease, and hence such requests are a no-op.
  • You can scale the VM Cluster resources even if any of the DB servers in the VM Cluster are down:
    • If a DB server is down and scaling is performed, the VMs on that server will not be automatically scaled to the new OCPUs when the DB server and the VMs come back online. It's your responsibility to ensure that all the VMs in the cluster have the same OCPU values.
    • Even if the DB server is down, billing does not stop for the VM Cluster that has the VMs on that DB server.

Resizing Memory and Large Pages

You can scale the database server memory up and down in a VM Cluster. Scaling memory requires a rolling restart of the database servers to take effect. For memory scaling to succeed, the databases must autostart in the Open state.

Changing the memory in a VM Cluster will affect the large pages (HugePages) settings for the VMs in that cluster. When a VM is initially created, each VM's operating system is configured with 50% of the memory allocated to the VM for large pages, and databases are configured to use that memory for their SGA. Oracle recommends you not modify the large pages configuration unless you understand the implication of any changes you make. Improper configurations can prevent all databases from starting, and even prevent the VM from booting.

Although modifying the large pages configuration is not recommended, it is permitted. However, any changes made may be overridden by cloud automation if the VM's memory is resized later. During a memory resize operation, cloud automation will attempt to maintain the large pages memory as a percentage of total memory, with a maximum limit of 60%. If large pages are configured to use more than 60% of the total memory, cloud automation will automatically resize it to this 60% limit.

Once the new large pages allocation is calculated, the automation will perform the following checks:
  • Condition 1: The current HugePages usage, multiplied by 1.15 (15% more than currently used), must be less than the new large pages allocation.
  • Condition 2: The current HugePages usage, multiplied by 1.15, must also be less than 60% of the new total memory size.
Note

The current HugePages usage is determined by subtracting the free HugePages from the total current HugePages.
If both conditions are met, cloud automation will apply the memory changes to the VMs. If either condition is not met, the process will terminate with an error similar to the following:
EXACLOUD: Requested memory is insufficient. The new hugepage count is <<>>, which is less than the minimum required for the VM. Not proceeding with the change.

This process ensures there is enough conventional memory for the VM to boot. Before proceeding with the resize, automation performs a precheck to determine the current large pages usage by running database instances. If the precheck indicates that there will not be enough large pages memory after the resize to support the existing databases, the resize will fail, and the process will not continue.

Calculating the ASM Storage

Use the following formula to calculate the minimum required ASM storage:

  • For each disk group, for example, DATA, RECO, note the total size and free size by running the asmcmd lsdg command on any Guest VM of the VM cluster.
  • Calculate the used size as (Total size - Free size) / 3 for each disk group. The /3 is used because the disk groups are triple mirrored.
  • DATA:RECO ratio is:

    80:20 if Local Backups option was NOT selected in the user interface.

    40:60 if Local Backups option was selected in the user interface.

  • Ensure that the new total size as given in the user interface passes the following conditions:

    Used size for DATA * 1.15 <= (New Total size * DATA % )

    Used size for RECO * 1.15 <= (New Total size * RECO % )

Example 5-3 Calculating the ASM Storage

  1. Run the asmcmd lsdg command in the Guest VM:
    • Without SPARSE:
      /u01/app/19.0.0.0/grid/bin/asmcmd lsdg
      ASMCMD>
      State   Type Rebal Sector Logical_Sector Block AU     Total_MB   Free_MB    Req_mir_free_MB   Usable_file_MB   Offline_disks    Voting_files   Name
      MOUNTED HIGH N        512     512        4096 4194304 12591936   10426224   1399104           3009040           0                       Y      DATAC5/
      MOUNTED HIGH N        512     512        4096 4194304 3135456    3036336    348384            895984            0                       N      RECOC5/
      ASMCMD>
    • With SPARSE:
      /u01/app/19.0.0.0/grid/bin/asmcmd lsdg
      ASMCMD>
      State   Type Rebal Sector Logical_Sector Block AU       Total_MB   Free_MB   Req_mir_free_MB   Usable_file_MB   Offline_disks    Voting_files   Name
      MOUNTED HIGH N        512     512        4096 4194304   12591936   10426224  1399104           3009040            0                       Y     DATAC5/
      MOUNTED HIGH N        512     512        4096 4194304   3135456    3036336   348384            895984             0                       N     RECOC5/
      MOUNTED HIGH N        512     512        4096 4194304   31354560   31354500  3483840           8959840            0                       N     SPRC5/
      ASMCMD>
    Note

    The listed values of all attributes for SPARSE diskgroup (SPRC5) present the virtual size. In Exadata DB Systems and Exadata Cloud@Customer, we use the ratio of 1:10 for physicalSize:virtualSize. Hence, for all purposes of our calculation we must use 1/10th of the values displayed above in case of SPARSE for those attributes.

  2. Used size for a disk group = (Total_MB - Free_MB) /3
    • Without SPARSE:

      Used size for DATAC5 = (12591936 - 10426224 ) / 3 = 704.98 GB

      Used size for RECO5 = (3135456 - 3036336 ) / 3 = 32.26 GB

    • With SPARSE:

      Used size for DATAC5 = (12591936 - 10426224 ) / 3 ~= 704.98 GB

      Used size for RECO5 = (3135456 - 3036336 ) /3 ~= 32.26 GB

      Used size for SPC5 = (1/10 * (31354560 - 31354500)) / 3 ~= 0 GB

  3. Storage distribution among diskgroups
    • Without SPARSE:

      DATA:RECO ratio is 80:20 in this example.

    • With SPARSE:

      DATA RECO: SPARSE ratio is 60:20:20 in this example.

  4. New requested size should pass the following conditions:
    • Without SPARSE: (For example, 5 TB in user interface.)

      5 TB = 5120 GB ; 5120 *.8 = 4096 GB; 5120 *.2 = 1024 GB

      For DATA: (704.98 * 1.15 ) <= 4096 GB

      For RECO: (32.36 * 1.15) <= 1024 GB

    • With SPARSE: (For example, 8 TB in the user interface.)

      8 TB = 8192 GB; 8192 *.6 = 4915 GB; 8192 *.2 = 1638 GB; 8192 *.2 = 1638 GB

      For DATA: (704.98 * 1.15 ) <= 4915 GB

      For RECO: (32.36 * 1.15) <= 1638 GB

      For SPR: (0 * 1.15) <= 1638 GB

Above resize will go through. If above conditions are not met by the new size, then resize will fail the precheck.

Estimating How Much Local Storage You Can Provision to Your VMs

VM Images include the files necessary to boot and run the VM and its operating system, as well as space for Oracle Homes stored in /u02. To estimate how much additional local storage space beyond the minimum can be allocated to any file system associated with a VM, subtract the size of the VM images for all VMs on a server from the total available space. If you have not modified the default VM Image size by expanding any file systems, use the VM Image size (default and minimum) below. If you have or plan to modify your VM Image size, you must use the OCI console and "Scale VM Cluster" action to check the allocated and available for an existing VM Cluster as expanding some non-/u02 file systems will consume more incremental storage than was added to the file system. This information is also available in the "Configure VM Cluster" action while creating a new VM Cluster.

X8-2 and X7-2 Systems

  • Total space available for VM images (X7 All Systems): 1237 GB
  • Total space available for VM images (X8 All Systems): 1037 GB
  • VM Image size (default and minimum) including /u02: 244 GB
  • Default (minimum) /u02: 60 GB

X8M-2 Systems

  • Total space available for VM images (X8M Base System): 1237 GB
  • Total space available for VM images (X8M Elastic): 2500 GB
  • VM Image size (default and minimum) including /u02: 244 GB
  • Default (minimum) /u02: 60 GB

X10M and X9M-2 Systems

  • Total Available for VM Images (Base System X9M): 1077 GB
  • Total Available for VM Images (Elastic): 2243 GB
  • VM Image size (default and minimum) including /u02: 244 GB
  • Default (minimum) /u02: 60 GB

Scaling Local Storage

Scale Local Space Operation Guidelines

You can scale local storage by modifying the size of many of the individual file systems in a VM. By default, the file systems are created at their minimum size. You can increase the size of the file systems as required. However, note that you can only shrink /u02. Other file systems can only be increased in size. The maximum supported size of any file system is 900 GB.

The storage consumed by all file systems is greater than the sum of the file system sizes. Refer to the calculations displayed in the OCI console to see the effects on free local storage when resizing a file system.

Using the OCI Console or API, you can increase or decrease the size of the following local file systems:

  • /u02

Using the OCI Console or API, you can increase the size of following local filesystems:

  • /
  • /u01
  • /tmp
  • /var
  • /var/log
  • /var/log/audit
  • /home

However, you cannot resize the following local file systems:

  • /crashfiles
  • /boot
  • /acfs01
  • /u01/app/19.0.0.0/grid
Note

  • With the exception of /u02, you can only expand the file systems and cannot reduce their size once they have been expanded.
  • A rolling restart of each VM is required for the resizing to take effect.
  • Each file system can only be expanded to a maximum of 900 GB
  • Ability to increase the size of additional local file systems is only supported on X8M and later systems.

For more information about resizing these file systems, see Estimating How Much Local Storage You Can Provision to Your VMs.

Resource Limit Based On Current Utilization

  • Any scale-down operation must leave 15% buffer on top of highest local space utilization across all nodes in the cluster.
  • The lowest local space per node allowed is higher of the above two limits.
  • Run the df –kh command on each node to find out the node with the highest local storage.
  • You can also use the utility like cssh to issue the same command from all hosts in a cluster by typing it just once.
  • Lowest value of local storage each node can be scaled down to would be = 1.15x (highest value of local space used among all nodes).

ACFS File Systems

If requested by support, you can also resize the /acfs01 file system. This file system is used by the system to stage software. It uses Exadata storage and is not subject to the limits described above for /u02. It is a shared file system visible from all nodes in the cluster, and can be online resized from the command line of any VM.

  • Default size: The default size of /acfs01 is 100 GB.
  • Scaling /acfs01: You can scale acfs01 as user grid from any VM via the /sbin/acfsutil command. No reboot is required. The resize operation will not affect the availability of the database service running in the VM Cluster. The following command issued by the grid user will increase the size of /acfs01 by 100 GB: /sbin/acfsutil size +100 GB /acfs01.
  • You can create additional ACFS file systems if required. These will also consume storage from the Exadata Storage diskgroups and may be shared across all VMs in the cluster. Refer to the ACFS documentation for more information.

Using the Console to Manage VM Clusters on Oracle Exadata Database Service on Cloud@Customer

Learn how to use the console to create, edit, and manage your VM Clusters on Oracle Exadata Database Service on Cloud@Customer.

Using the Console to Create a VM Cluster

To create your VM cluster, be prepared to provide values for the fields required for configuring the infrastructure.

To create a VM cluster, ensure that you have:

  • Active Exadata infrastructure is available to host the VM cluster.
  • A validated VM cluster network is available for the VM cluster to use.
  1. Open the navigation menu. Under Oracle Database, click Exadata Database Service on Cloud@Customer.
  2. Choose the Region that contains your Exadata infrastructure.
  3. Click VM Clusters.
  4. Click Create VM Cluster.
  5. Provide the requested information on the Create VM Cluster page:
    1. Choose a compartment: From the list of available compartments, choose the compartment that you want to contain the VM cluster.
    2. Provide the display name: The display name is a user-friendly name that you can use to identify the VM cluster. The name doesn't need to be unique because an Oracle Cloud Identifier (OCID) uniquely identifies the VM cluster.
    3. Select Exadata Database Service on Cloud@Customer Infrastructure: From the list, choose the Exadata infrastructure to host the VM cluster. You are not able to create a VM cluster without available and active Exadata infrastructure.
    4. Select a VM Cluster Network: From the list, choose a VM cluster network definition to use for the VM cluster. You must have an available and validated VM cluster network before you can create a VM cluster.
    5. Choose the Oracle Grid Infrastructure version: From the list, choose the Oracle Grid Infrastructure release (19c and 23ai) that you want to install on the VM cluster.

      The Oracle Grid Infrastructure release determines the Oracle Database releases that can be supported on the VM cluster. You cannot run an Oracle Database release that is later than the Oracle Grid Infrastructure software release.

      Note

      Minimum requirements for provisioning a VM Cluster with Grid Infrastructure 23ai:
      • Exadata Guest VM running Exadata System Software 23.1.8
      • Exadata Infrastructure running Exadata System Software 23.1.x
    6. Choose an Exadata image version:
      • Exadata infrastructure with Oracle Linux 7 and Exadata image version 22.1.10.0.0.230422:
        • The Change image button is not enabled.
        • The Oracle Grid Infrastructure version defaults to 19.0.0.0.0.
        • The Exadata guest version will be the same as that of the host OS.
      • Exadata infrastructure with Oracle Linux 8 and Exadata image version 23.1.3.0.0.230613:
        • The Exadata guest version defaults to the latest (23.1.3.0).
        • The Oracle Grid Infrastructure version defaults to 19.0.0.0.0
        • The Change image button is enabled.
        • Click Change image.

          The resulting Change image panel displays the list of available major versions of Exadata image (23.1.3.0 and 22.1.3.0).

          The most recent release for each major version is indicated by "(latest)".

        • Slide Display all available versions.

          Six past versions including the latest versions of Exadata images 23.1.3.0 and 22.1.3.0 are displayed.

        • Choose a version.
        • Click Save Changes.
    7. Configure VM Cluster:
      • Click Select DB Servers for VM placement to allocate VM resources.
      • On the Select DB Servers dialog, select a minimum of one database server for VM placement. If you require a high availability database service that remains available during maintenance and unplanned outages, select at least two database servers. Maximum resources available for allocation per VM are based on the number of database servers selected.
        Note

        • DB Servers, which already have 8 VMs running on them are not available for selection.
        • When calculating maximum local storage resources across selected DB Servers, the reserved local storage needed by the system to host a VM based on hardware generation is deducted from the DB Server with the least resources.

          For example, if the local storage available across selected DB servers is 823 GB for DB Server 3 and 813 GB for DB Server 4, then the minimum across selected servers is 813 GB and the maximum available for resource allocation is 813 GB - 184 GB (reserved local storage for hosting VM on X8M DB servers) = 629 GB.

          For more information, see Estimating How Much Local Storage You Can Provision to Your VMs.

      • Click Save Changes.
    8. Specify the OCPU count per VM: Specify the OCPU count to be provisioned for each VM in this cluster. The minimum value is 2 OCPUs per VM (for a live VM condition), unless you are specifying zero OCPUs (for a shutdown VM condition).

      If you specify a value of zero, then the VM cluster virtual machines are all shut down at the end of the cluster creation process. In this case, you can later start the virtual machines by scaling the OCPU resources. See Using the Console to Scale the Resources on a VM Cluster.

      The value for OCPU count for the whole VM Cluster will be calculated automatically based upon the per VM OCPU count you have specified, and the number of physical Database Servers configured for the VM Cluster.

      OCPU: An Oracle Compute Unit (OCPU) provides CPU capacity equivalent of one physical core of an Intel Xeon processor with hyperthreading enabled. Each OCPU corresponds to two hardware execution threads, known as vCPUs.

      See, Oracle Platform as a Service and Infrastructure as a Service – Public Cloud Service DescriptionsMetered & Non-Metered.
    9. Requested OCPU count for the VM Cluster: Displays the total number of CPU cores allocated to the VM cluster based on the value you specified in the Specify the OCPU count per VM field. This field is not editable.
    10. Specify the memory per VM (GB): Specify the memory for each individual VM. The value must be a multiple of 1 GB and is limited by the available memory on the Exadata infrastructure.
    11. Requested memory for the VM Cluster (GB): Displays the total amount of memory allocated to the VM cluster based on the value you specified in the Specify the memory per VM (GB) field. This field is not editable.
    12. Specify the local file system size per VM (GB): Specify the local file system size for each individual VM. The value must be a multiple of 1 GB and is limited by the available size of the file system on the X8-2 and X7-2 infrastructures.

      Note that the minimum size of local system storage must be 60 GB. Each time when you create a new VM cluster, the space remaining out of the total available space is utilized for the new VM cluster.

      For more information and instructions to specify the size for each individual VM, see Introduction to Scale Up or Scale Down Operations.

      1. Click Show additional local file systems configuration options.
      2. Resize the /, /u01, /tmp, /var, /var/log, /var/log/audit, and /home file systems as needed.
        Note

        • You can only expand these file systems and cannot reduce the size once expanded.
        • Due to backup partitions and mirroring, the / and /var file systems will consume twice the space they were allocated, which is indicated in the read-only Total allocated storage for / (GB) due to mirroring and Total allocated storage for /var (GB) due to mirroring fields.
        • After creating the VM Cluster, check the Exadata Resources section on the Exadata Infrastructure Details page to check the file size allocated to the local storage (/u02) and local storage (additional file systems).
    13. Reserved local storage per VM (GB): Displays the local storage size reserved internally for root file systems, Oracle Grid Infrastructure Homes, and diagnostic logs. This field is not editable.
    14. Configure the Exadata Storage: The following settings define how the Exadata storage is configured for use with the VM cluster. These settings cannot be changed after creating the VM cluster.
      • Specify Usable Exadata Storage: Specify the size for each individual VM. The minimum recommended size is 2 TB.
      • Allocate Storage for Exadata Snapshots: Check this option to create a sparse disk group, which is required to support Exadata snapshot functionality. Exadata snapshots enable space-efficient clones of Oracle databases that can be created and destroyed very quickly and easily.
      • Allocate Storage for Local Backups: Check this option to configure the Exadata storage to enable local database backups. If you select this option, more space is allocated to the RECO disk group to accommodate the backups. If you do not select this option, you cannot use local Exadata storage as a backup destination for any databases in the VM cluster.

      Table 5-15 Storage Allocation

      Storage Allocation DATA Disk Group RECO Disk Group SPARSE Disk Group

      Exadata Snapshots: No

      Enable Backups on Local Exadata Storage: No

      80%

      20%

      0% (The SPARSE disk group is not created.)

      Exadata Snapshots: No

      Enable Backups on Local Exadata Storage: Yes

      40%

      60%

      0% (The SPARSE disk group is not created.)

      Allocate Storage for Exadata Snapshots: Yes

      Enable Backups on Local Exadata Storage: No

      60%

      20%

      20%

      Allocate Storage for Exadata Snapshots: Yes

      Enable Backups on Local Exadata Storage: Yes

      35%

      50%

      15%

    15. Add SSH Key: Specify the public key portion of an SSH key pair that you want to use to access the VM cluster virtual machines. You can upload a file containing the key, or paste the SSH key string.

      To provide multiple keys, upload multiple key files or paste each key into a separate field. For pasted keys, ensure that each key is on a single, continuous line. The length of the combined keys cannot exceed 10,000 characters.

    16. Choose a license type:
      • Bring Your Own License (BYOL): Select this option if your organization already owns Oracle Database software licenses that you want to use on the VM cluster.
      • License Included: Select this option to subscribe to Oracle Database software licenses as part of Exadata Database Service on Cloud@Customer.
    17. Diagnostics Collection:

      By enabling diagnostics collection and notifications, Oracle Cloud Operations and you will be able to identify, investigate, track, and resolve guest VM issues quickly and effectively. Subscribe to Events to get notified about resource state changes. For more information, see Getting Started with Events.

      Note

      You are opting in with the understanding that the list of events, metrics, and log files collected can change in the future. You can opt out of this feature at any time.
      • Enable Diagnostic Events: Allow Oracle to collect and publish critical, warning, error, and information events to me.
      • Enable Health Monitoring: Allow Oracle to collect health metrics/events such as Oracle Database up/down, disk space usage, and so on, and share them with Oracle Cloud operations. You will also receive notification of some events.
      • Enable Incident Logs and Trace Collection: Allow Oracle to collect incident logs and traces to enable fault diagnosis and issue resolution.

        All three checkboxes are selected by default. You can leave the default settings as is or clear the checkboxes as needed. You can view the Diagnostic Collection settings on the VM Cluster Details page under General Information >> Diagnostics Collection.
        • Enabled: When you choose to collect diagnostics, health metrics, incident logs, and trace files (all three options).

        • Disabled: When you choose not to collect diagnostics, health metrics, incident logs, and trace files (all three options).

        • Partially Enabled: When you choose to collect diagnostics, health metrics, incident logs, and trace files ( one or two options).
    18. Show Advanced Options:
      • Time zone: The default time zone for the Exadata Infrastructure is UTC, but you can specify a different time zone. The time zone options are those supported in both the Java.util.TimeZone class and the Oracle Linux operating system.
        Note

        If you want to set a time zone other than UTC or the browser-detected time zone, then select the Select another time zone option, select a Region or country, and then select the corresponding Time zone.

        If you do not see the region or country you want, then select Miscellaneous, and then select an appropriate Time zone.

      • Tags: Optionally, you can apply tags. If you have permission to create a resource, you also have permission to apply free-form tags to that resource. To apply a defined tag, you must have permission to use the tag namespace. For more information about tagging, see Resource Tags. If you are not sure if you should apply tags, skip this option (you can apply tags later) or ask your administrator.
  6. Optionally, you can save the resource configuration as a stack.
    • To save the resource configuration as a Stack:
      1. Click Save as Stack.
      2. In the resulting Save as Stack dialog, provide the following details:
        1. Name: (Optional) Provide an easy to remember descriptive name.
        2. Description: (Optional) Enter a short description.
        3. Compartment: Select a compartment where this Stack will reside.
        4. Tags: Add tags.
      3. Click Save.

        After saving the Stack, the system displays a banner with a link to the saved Stack.

      4. Click the link to open the Stack in the Resource Manager Service console.

        See, Resource Manager and Terraform.

    • To view the details of a Stack:
      1. Open the navigation menu. Under Developer Services, click Resource Manager.
      2. Click Stacks.
      3. Click the name of the Stack that you want to view details.

        Or, click the Actions menu (three dots), and select the View stack details option.

  7. Click Create VM Cluster.

    The VM Cluster Details page is now displayed. While the creation process is running, the state of the VM cluster is Pending. When the VM cluster creation process completes, the state of the VM cluster changes to Available.

Using the Console to Enable, Partially Enable, or Disable Diagnostics Collection

You can enable, partially enable, or disable diagnostics collection for your Guest VMs after provisioning the VM cluster. Enabling diagnostics collection at the VM cluster level applies the configuration to all the resources such as DB home, Database, and so on under the VM cluster.

Note

  • You are opting in with the understanding that the list of events, metrics, and log files collected can change in the future. You can opt-out of this feature at any time.
  • Oracle may add more metrics in the future, but if you have already chosen to collect metrics, you need not update your opt-in value. It will remain enabled/disabled based on your current preference.
  • If have previously opted in for incident log and trace file collection and decide to opt out when Oracle Cloud operations run a log collection job, then the job will run its course and will not cancel. Future log collections won't happen until you opt-in again to the incident logs and trace file collection option.
  1. Open the navigation menu. Under Oracle Database, click Exadata Database Service on Cloud@Customer.
  2. Choose the Region that contains your Exadata infrastructure.
  3. Click VM Clusters.
  4. Click the name of the VM cluster you want to enable or disable diagnostic data collection.
  5. On the VM Cluster Details page, under General Information, enable, partially enable, or disable Diagnostics Collection.
  6. Click Edit.

    Edit Diagnostics Collection Settings window is displayed.

  7. Select or clear the checkboxes and then click Save Changes.

Using the Console to Add VMs to a Provisioned Cluster

To add virtual machines to a provisioned cluster, use this procedure.

Once the VM cluster is upgraded to Exadata Database Service Guest VM OS 23.1, you will be able to add a new VM or a new database server to this VM cluster if Exadata Cloud@Customer Infrastructure is running an Exadata System Software version 22.1.16 and later.

Note

Upgrade to Exadata System Software 23.1 for Exadata Cloud@Customer Infrastructure will be available with February 2023 update cycle.
Consider reviewing the points below that will assist you in adding VMs to a provisioned cluster.
  • The same Guest OS Image version running on the existing provisioned VMs in the cluster is used to provision new VMs added to extend the VM cluster. However, any customizations made to the Guest OS Image on the existing VMs must be manually applied to the newly added VM.
  • For VM clusters running a Guest OS Image version older than a year, you must update the Guest OS Image version before adding a VM to extend the cluster.
  • Adding a VM to a cluster will not automatically extend any database which is part of a Data Guard configuration (either primary or standby) to the newly provisioned VM.
  • For databases not part of a Data Guard configuration, only databases that are running on all VMs in the existing cluster will be added to the newly provisioned VM. Any database running on a subset of VMs will not extend automatically to run on the newly added VM.
When you attempt to add a VM to a VM cluster, you might encounter the error [FATAL] [INS-32156] Installer has detected that there are non-readable files in oracle home. To resolve the issue, follow the steps outlined in Adding a VM to a VM Cluster Fails before you try adding a cluster node.
  1. Open the navigation menu. Under Oracle Database, click Exadata Database Service on Cloud@Customer.

    VM Clusters is selected by default.

  2. Choose your Compartment.

    A list of VM Clusters is displayed for the chosen Compartment.

  3. Click the name of a VM cluster where you want to add virtual machines.
  4. In the VM Cluster Details page, under Resources, click Virtual Machines, and then click Add Virtual Machines.
  5. On the Add Virtual Machines dialog, select additional DB servers on which to add the VM.

    You cannot unselect existing DB Servers. The maximum resources available per VM get updated based on the newly added DB servers.

    DB Server Statuses include In this VM cluster, Network not configured, Available to add, and Insufficient resources. You can only add DB servers with the Available to add status.

    DB servers that do not have a network configured are not available to add. To configure the network, edit the VM Cluster Network of the associated infrastructure. For more information, see Using the Console to Add Another DB Server to the VM Cluster Network.

  6. Select the DB servers with the Available to add status and then click Save Changes.

    The statuses of the DB servers change to Allocated.

    Note

    You cannot remove an allocated DB server.

To extend the database instance for Data Guard-enabled databases for the newly added VMs, see Nodelist is not Updated for Data Guard-Enabled Databases.

Using the Console to View a List of DB Servers on an Exadata Infrastructure

To view a list of database server hosts on an Oracle Exadata Cloud@Customer system, use this procedure.

  1. Open the navigation menu. Under Oracle Database, click Exadata Database Service on Cloud@Customer.
  2. Under Infrastructure, click Exadata Infrastructure.
  3. In the list of Exadata Infrastructures, click the display name of the infrastructure you wish to view details.
  4. Under Resources, click DB Servers.
  5. In the list of DB Servers, click the name of the DB Server that you wish to view details.

    DB Server lists VMs from each cluster hosted on them along with resources allocated to them.

Using the Console to Remove a VM from a VM Cluster

To remove a virtual machine from a provisioned cluster, use this procedure.

Note

Terminating a VM from a cluster requires the removal of any database which is part of a Data Guard configuration (either primary or standby) from the VM to proceed with the terminate flow. For more information on manual steps, see My Oracle Support note 2811352.1.
  1. Open the navigation menu. Under Oracle Database, click Exadata Database Service on Cloud@Customer.
  2. Choose the Region and Compartment that contains the VM cluster for which you want to scale the CPU resources.
  3. Click VM Clusters.
  4. Click the name of the VM cluster for which you want to remove a virtual machine.
  5. Under Resources, click Virtual Machines.
  6. In the list of virtual machines, click the Actions icon (three dots) for a virtual machine, and then click Remove.
  7. On the Terminate Virtual Machine dialog, enter the name of the virtual machine, and then click Remove.

    VM removed from the cluster. VM Cluster Details page displays the updated resource allocation details under VM Cluster Resource Allocation.

Using the Console to Update the License Type on a VM Cluster

To modify licensing, be prepared to provide values for the fields required for modifying the licensing information.

  1. Open the navigation menu. Under Oracle Database, click Exadata Database Service on Cloud@Customer.
  2. Choose the Region and Compartment that contains the VM cluster for which you want to update the license type.
  3. Click VM Clusters.
  4. Click the name of the VM cluster for which you want to update the license type.

    The VM Cluster Details page displays information about the selected VM cluster.

  5. Click Update License Type.
  6. In the dialog box, choose one of the following license types and then click Save Changes.
    • Bring Your Own License (BYOL): Select this option if your organization already owns Oracle Database software licenses that you want to use on the VM cluster.
    • License Included: Select this option to subscribe to Oracle Database software licenses as part of Exadata Database Service on Cloud@Customer.

    Updating the license type does not change the functionality or interrupt the operation of the VM cluster. Customers are permitted to change the license type for a VM Cluster at most once per month.

Using the Console to Add SSH Keys After Creating a VM Cluster

  1. Open the navigation menu. Under Oracle Database, click Exadata Cloud@Customer.
  2. Choose the Region that contains your Exadata infrastructure.
  3. Click VM Clusters.
  4. Click the name of the VM cluster that you want to add SSH key(s).
  5. In the VM Cluster Details page, click Add SSH Keys.
  6. In the ADD SSH Keys dialog, choose any one of the methods:
    • Generate SSH key pair: Select this option if you want the Control Plane to generate public/private key pairs for you.

      Click Save Private Key and Save Public Key to download and save SSH Key pair.

    • Upload SSH key files: Select this option to upload the file that contains SSH Key pair.
    • Paste SSH keys: Select this option to paste the SSH key string.

      To provide multiple keys, click Another SSH Key. For pasted keys, ensure that each key is on a single, continuous line. The length of the combined keys cannot exceed 10,000 characters.

  7. Click Save Changes.

Using the Console to Scale the Resources on a VM Cluster

Starting in Oracle Exadata Database Service on Cloud@Customer, you can scale up or down multiple resources at the same time. You can also scale up or down resources one at a time.

Scale down resources under the following circumstances:
  • Use Case 1: If you have allocated all of the resources to one VM cluster, and if you want to create multiple VM clusters, then there wouldn't be any resources available to allocate to the new clusters. Therefore, scale down the resources as needed to then create additional VM clusters.
  • Use Case 2: If you want to allocate different resources based on the workload, then scale down or scale up accordingly. For example, you may want to run nightly batch jobs for reporting/ETL and scale down the VM once the job is over.
You can scale down the following resources in any combinations:
  • OCPU
  • Memory
  • Local storage
  • Exadata storage

Each scaling operation can take several minutes to complete. The time for each operation will vary based on activity in the system, but as a general rule, most operations should complete within 15 minutes for a quarter rack, 20 minutes for a half rack, and 30 minutes for a full or larger rack. Performing multiple OCPU scaling operations over a short period of time can lengthen the time for completion. Although online, OCPU scaling is not implemented on all VMs in parallel so as to detect and protect from any anomalies before they affect the entire system. Memory and Local Storage scaling require a VM reboot, and are performed one VM at a time in a rolling manner.

If you run multiple scale down operations, then each operation is performed serially. For example, if you scale memory and local storage from the Console, then the system will first scale memory, and when that operation completes, it will scale storage. The time to complete all operations will be the sum of the time to complete individual operations.

  1. Open the navigation menu. Under Oracle Database, click Exadata Database Service on Cloud@Customer.
  2. Choose the Region and Compartment that contains the VM cluster for which you want to scale the CPU resources.
  3. Click VM Clusters.
  4. Click the name of the VM cluster for which you want to scale the CPU resources.

    The VM Cluster Details page displays information about the selected VM cluster.

  5. Click Scale Up/Down.
  6. In the dialog box, adjust any or all of the following:
    • OCPU Count:

      The OCPU Count value must be a multiple of the number of virtual machines so that every virtual machine has the same number of CPU cores enabled.

      If you set the OCPU Count to zero, then the VM cluster virtual machines are all shut down. If you change from a zero setting, then the VM cluster virtual machines are all started. Otherwise, modifying the number of enabled CPU cores is an online operation, and virtual machines are not rebooted because of this operation. See also System Configuration.

      Note

      If you have explicitly set the CPU_COUNT database initialization parameter, that setting is not affected by modifying the number of CPU cores that are allocated to the VM cluster. Therefore, if you have enabled the Oracle Database instance caging feature, the database instance does not use extra CPU cores until you alter the CPU_COUNT setting. If CPU_COUNT is set to 0 (the default setting), then Oracle Database continuously monitors the number of CPUs reported by the operating system and uses the current count.
    • Memory:

      Specify the memory for each individual VM. The value must be a multiple of 1 GB and is limited by the available memory on the Exadata infrastructure.

      When you scale up or down the memory, the associated virtual machines are rebooted in a rolling manner one virtual machine at a time to minimize the impact on the VM cluster.

    • Local file system size:

      Specify the size for each individual VM. The value must be a multiple of 1 GB and is limited by the available size of the file system on the Exadata infrastructure.

      When you scale up or down the local file system size, the associated virtual machines are rebooted in a rolling manner one virtual machine at a time to minimize the impact on the VM cluster.

      1. Click Show additional local file systems configuration options.
      2. Resize the /, /u01, /tmp, /var, /var/log, /var/log/audit, and /home file systems as needed.
        Note

        • You can only expand these file systems and cannot reduce the size once expanded.
        • Due to backup partitions and mirroring, the / and /var file systems will consume twice the space they were allocated, which is indicated in the read-only Total allocated storage for / (GB) due to mirroring and Total allocated storage for /var (GB) due to mirroring fields.
      3. After creating the VM Cluster, check the Exadata Resources section on the Exadata Infrastructure Details page to check the file size allocated to the local storage (/u02) and local storage (additional file systems).

      Reserved local storage per VM (GB): Displays the size reserved internally for root file systems, Oracle Grid Infrastructure Homes, and diagnostic logs.

    • Usable Exadata storage size:

      Specify the total amount of Exadata storage that is allocated to the VM cluster. This storage is allocated evenly from all of the Exadata Storage Servers. The minimum recommended size is 2 TB.

      You may reduce the Exadata storage allocation for a VM cluster. However, you must ensure that the new amount covers the existing contents, and you should also allow for anticipated data growth.

      Note

      When you downsize, the new size must be at least 15% more than the currently used size.

      Modifying the Exadata storage allocated to the VM cluster is an online operation. Virtual machines are not rebooted because of this operation.

  7. . Click Save Changes.

Using the Console to Stop, Start, or Reboot a VM Cluster Virtual Machine

Use the console to stop, start, or reboot a virtual machine.

  1. Open the navigation menu. Under Oracle Database, click Exadata Database Service on Cloud@Customer.
  2. Choose the Region and Compartment that is associated with the VM cluster that contains the virtual machine that you want to stop, start, or reboot.
  3. Click VM Clusters.
  4. Click the name of the VM cluster that contains the virtual machine that you want to stop, start, or reboot.

    The VM Cluster Details page displays information about the selected VM cluster.

  5. In the Resources list, click Virtual Machines.

    The list of virtual machines is displayed.

  6. In the list of nodes, click the Actions icon (three dots) for a node, and then click one of the following actions:
    1. Start: Restarts a stopped node. After the node is restarted, the Stop action is enabled.
    2. Stop: Shuts down the node. After the node is stopped, the Start action is enabled.
    3. Reboot: Shuts down the node, and then restarts it.

Using the Console to Check the Status of a VM Cluster Virtual Machine

Review the health status of a VM cluster virtual machine.

  1. Open the navigation menu. Under Oracle Database, click Exadata Database Service on Cloud@Customer.
  2. Choose the Region and Compartment that is associated with the VM cluster that contains the virtual machine that you are interested in.
  3. Click VM Clusters.
  4. Click the name of the VM cluster that contains the virtual machine that you are interested in.

    The VM Cluster Details page displays information about the selected VM cluster.

  5. In the Resources list, click Virtual Machines.

    The list of virtual machines displays. For each virtual machine in the VM cluster, the name, state, and client IP address are displayed.

  6. In the node list, find the virtual machine that you are interested in and check its state.

    The color of the icon and the associated text it indicates its status.

    • Available: Green icon. The node is operational.
    • Starting: Yellow icon. The node is starting because of a start or reboot action in the Console or API.
    • Stopping: Yellow icon. The node is stopping because of a stop or reboot action in the Console or API.
    • Stopped: Yellow icon. The node is stopped.
    • Failed: Red icon. An error condition prevents the continued operation of the virtual machine.

Using the Console to Move a VM Cluster to Another Compartment

To change the compartment that contains your VM cluster on Oracle Exadata Database Service on Cloud@Customer, use this procedure.

When you move a VM cluster, the compartment change is also applied to the virtual machines and databases that are associated with the VM cluster. However, the compartment change does not affect any other associated resources, such as the Exadata infrastructure, which remains in its current compartment.

  1. Open the navigation menu. Under Oracle Database, click Exadata Database Service on Cloud@Customer.
  2. Choose the Region and Compartment that contains the VM cluster that you want to move.
  3. Click VM Clusters.
  4. Click the name of the VM cluster that you want to move.

    The VM Cluster Details page displays information about the selected VM cluster.

  5. Click Move Resource.
  6. In the resulting dialog, choose the new compartment for the VM cluster, and click Move Resource.

Using the Console to Terminate a VM Cluster

Before you can terminate a VM cluster, you must first terminate the databases that it contains.

Terminating a VM cluster removes it from the Cloud Control Plane. In the process, the virtual machines and their contents are destroyed.
  1. Open the navigation menu. Under Oracle Database, click Exadata Database Service on Cloud@Customer.
  2. Choose the Region and Compartment that contains the VM cluster that you want to terminate.
  3. Click VM Clusters.
  4. Click the name of the VM cluster that you want to terminate.

    The VM Cluster Details page displays information about the selected VM cluster.

  5. Click Terminate.
  6. In the resulting dialog, enter the name of the VM cluster, and click Terminate VM Cluster to confirm the action.

Using the API to Manage Oracle Exadata Database Service on Cloud@Customer VM Clusters

Review the list of API calls to manage your Oracle Exadata Database Service on Cloud@Customer VM cluster networks and VM clusters.

For information about using the API and signing requests, see "REST APIs" and "Security Credentials". For information about SDKs, see "Software Development Kits and Command Line Interface".

Use these API operations to manage Oracle Exadata Database Service on Cloud@Customer VM cluster networks and VM clusters:

VM cluster networks:
  • GenerateRecommendedVmClusterNetwork
  • CreateVmClusterNetwork
  • DeleteVmClusterNetwork
  • GetVmClusterNetwork
  • ListVmClusterNetworks
  • UpdateVmClusterNetwork
  • ValidateVmClusterNetwork
VM clusters:
  • CreateVmCluster
  • DeleteVmCluster
  • GetVmCluster
  • ListVmClusters
  • UpdateVmCluster

For the complete list of APIs, see "Database Service API".

Troubleshooting Virtual Machines Using Console Connections

You can troubleshoot malfunctioning virtual machines using console connections. For example, a previously working Guest VM stops responding.

Note

The use of the serial console feature requires Exadata Infrastructure version 22.1.10 or higher for 22.X users and version 23.1.1 or higher for 23.X users. The serial console feature will be available on any new VM Clusters created immediately but will only be available on previously existing VM Clusters after the next quarterly maintenance cycle. Also, make sure to review all prerequisites stated below, including setting a password for either the opc or the root user. Failure to make necessary changes for meeting these requirements in advance will result in the inability to urgently connect to the serial console when the need arises when the VM is not otherwise accessible.

To connect to a running instance for administration and general use, use a Secure Shell (SSH). For more information, see Connecting to a Virtual Machine with SSH

To make an SSH connection to the serial console, follow these configuration steps.
  1. Ensure that you have the correct permissions.
  2. Complete the prerequisites, including creating your SSH key pair (in case you don't have one yet).
  3. Create the Virtual Machine Serial Console.
  4. Connect to the serial console via SSH.
To check the DB server version installed, follow these steps:
  1. Open the navigation menu. Under Oracle Database, click Exadata Database Service on Cloud@Customer.
  2. Under Region, select the region that you want to associate with the Oracle Exadata infrastructure.
  3. Under Infrastructure, click Exadata Infrastructure.
  4. Click the name of the infrastructure that you are interested in.
  5. In the resulting Infrastructure Details page, go to the Version section to the find the DB Server version installed.

Required IAM Policies

An administrator must grant you secure access to the virtual machine console on the Exadata Database Service on Cloud@Customer system through an IAM policy.

This access is required whether you're using the Console or the REST API with an SDK, CLI, or other tools. If you get a message that you don’t have permission or are unauthorized, verify with your administrator what type of access you have and which compartment to work in.

To create virtual machine console connections, an administrator needs to grant user access to read and manage virtual machine console connections through an IAM policy. The resource name for virtual machine console connections is dbnode-console-connection. The resource name for virtual machine is db-nodes. The following policies grant users the ability to create virtual machine console connections:

Allow group <group_name> to manage dbnode-console-connection in tenancy
Allow group <group_name> to read db-nodes in tenancy

Prerequisites

You must install an SSH client and create SSH key pairs.

Ports to Open for Control Plane Connectivity

Ensure that the firewall rules are correct so that the Control Plane Server (CPS) can reach the required OCI endpoints. For more information, see Table 3-2

Install an SSH Client and a Command-line Shell (Microsoft Windows)

Microsoft Windows does not include an SSH client by default. If you are connecting from a Windows client, you need to install an SSH client. You can use PuTTY plink.exe with Windows PowerShell or software that includes a version of OpenSSH such as:

The instructions in this topic frequently use PuTTY and Windows PowerShell.

If you want to make the console connection from Windows with Windows PowerShell, PowerShell might already be installed on your Windows operating system. If not, follow the steps at the link. If you are connecting to the instance from a Windows client using PowerShell, plink.exe is required. plink.exe is the command link connection tool included with PuTTY. You can install PuTTY or install plink.exe separately. For installation information, see http://www.putty.org.

Create SSH Key Pairs

To create the secure console connection, you need an SSH key pair. The method to use for creating key pairs depends on your operating system. When connecting to the serial console, you must use an RSA key. The instructions in this section show how to create an RSA SSH key pair.

Create the SSH key Pair for Linux

If you're using a UNIX-style system, you probably already have the ssh-keygen utility installed. To determine whether the utility is installed, type ssh-keygen on the command-line. If the utility isn't installed, you can download OpenSSH for UNIX from http://www.openssh.com/portable.html and install it.

  1. Open a shell or terminal for entering the commands.
  2. At the prompt, enter ssh-keygen and provide a name for the key when prompted. Optionally, include a passphrase.

    The keys will be created with the default values: RSA keys of 2048 bits.

    Alternatively, you can type a complete ssh-keygen command, for example:
    ssh-keygen -t rsa -N "" -b 2048 -C "<key_name>" -f <path/root_name>
    Argument Description

    -t rsa

    Use the RSA algorithm.

    -N "<passphrase>"

    A passphrase to protect the use of the key (like a password). If you don't want to set a passphrase, don't enter anything between the quotes.

    A passphrase is not required. You can specify one as a security measure to protect the private key from unauthorized use. If you specify a passphrase, when you connect to the instance you must provide the passphrase, which typically makes it harder to automate connecting to an instance.

    -b 2048

    Generate a 2048-bit key. You don't have to set this if 2048 is acceptable, as 2048 is the default.

    A minimum of 2048 bits is recommended for SSH-2 RSA.

    -C "<key_name>"

    A name to identify the key.

    -f <path/root_name>

    The location where the key pair will be saved and the root name for the files.

Create the SSH Key Pair for Windows Using PuTTY

If you are using a Windows client to connect to the instance console connection, use an SSH key pair generated by PuTTY.

Note

Ensure that you are using the latest version of PuTTY, see http://www.putty.org.

  1. Find puttygen.exe in the PuTTY folder on your computer, for example, C:\Program Files (x86)\PuTTY. Double-click puttygen.exe to open it.
  2. Specify a key type of SSH-2 RSA and a key size of 2048 bits:
    • In the Key menu, confirm that the default value of SSH-2 RSA key is selected.
    • For the Type of key to generate, accept the default key type of RSA.
    • Set the Number of bits in a generated key to 2048 if not already set.
  3. Click Generate.
  4. To generate random data in the key, move your mouse around the blank area in the PuTTY window.

    When the key is generated, it appears under Public key for pasting into OpenSSH authorized_keys file.

  5. A Key comment is generated for you, including the date and timestamp. You can keep the default comment or replace it with your own more descriptive comment.
  6. Leave the Key passphrase field blank.
  7. Click Save private key, and then click Yes in the prompt about saving the key without a passphrase.

    The key pair is saved in the PuTTY Private Key (PPK) format, which is a proprietary format that works only with the PuTTY tool set.

    You can name the key anything you want, but use the ppk file extension. For example, mykey.ppk.

  8. Select all of the generated key that appears under Public key for pasting into OpenSSH authorized_keys file, copy it using Ctrl + C, paste it into a text file, and then save the file in the same location as the private key.
    Note

    Do not use Save public key because it does not save the key in the OpenSSH format.

    You can name the key anything you want, but for consistency, use the same name as the private key and a file extension of pub. For example: mykey.pub.

  9. Write down the names and location of your public and private key files. You need the public key when creating an instance console connection. You need the private key to connect to the instance console connection using PuTTY. For example: $HOME\Documents\mykey.ppk.
To create a connection using the SSH key pair generated using PuTTY

For more information about generating SSH key pair, see Create the SSH Key Pair for Windows Using PuTTY

Do the following on the Create serial console access window:

  1. Paste the SSH Key generated from OpenSSH format or choose Upload SSH key file and provide the path of the public key saved at step 8 in Create the SSH Key Pair for Windows Using PuTTY.
  2. Once the connection is Active, click Copy serial console connection for Windows.
  3. Paste the connection string copied from the previous step into a text file.
  4. In the text file, replace <PATH_FILE_PUTTY_PRIVATE.ppk> to point to your PuTTY Private Key (PPK) file path on your computer. For example, if you have saved .ppk file at $HOME\Documents\mykey.ppk.
  5. Paste the modified connection string into the PowerShell window, and then press Enter to connect to the console.
Sign in to a Virtual Machine From the Serial Console

If you want to sign in to a virtual machine using a virtual machine console connection, you can use Secure Shell (SSH) connection to sign in. If you want to sign in with a username and password, you need a user account with a password. Oracle Exadata Cloud does not set a default password for the opc or root users. Therefore, if you want to sign in as the opc or root user, you need to create a password for the opc or root user. Otherwise, add a different user with a password and sign in as that user. This should be completed in-advance, before a potential situation that might require you to log in to the serial console.

Connect Through Firewalls

If the client you will use to access the serial console is behind a firewall, you must ensure that this client is able to reach the required endpoint in order to access the serial console of the virtual machine. The client system connecting to the serial console must be able to reach the serial console server (for example, vm-console.exacc.us-ashburn-1.oci.oraclecloud.com) over SSH using port 443, directly or through a proxy.

Create the Virtual Machine Serial Console Connection

Before you can make a local connection to the serial console, you need to create the virtual machine console connection.

Note

Virtual machine console connections are limited to one client at a time. If the client fails, the connection remains active for approximately five minutes. During this time, no other client can connect. After five minutes, the connection is closed, and a new client can connect. During the five-minute timeout, any attempt to connect a new client fails with the following message:

channel 0: open failed: administratively prohibited: console access is limited to one connection at a time
  1. Open the navigation menu. Under Oracle Database, click Exadata Database Service on Cloud@Customer.
  2. Click the VM Cluster that you're interested in.
  3. In the resulting VM Cluster Details page, click the name of the virtual machine that you're interested in.

    Under Resources, Console connection is selected by default.

  4. Click Create serial console access.
  5. In the resulting Create serial console access window, you have three options for adding the SSH key
    • Generate a key pair for me: You can have Oracle Cloud Infrastructure generate an SSH key pair to use. If you are using PowerShell or PuTTY to connect to the instance from a Windows client, you cannot use the generated SSH key pair without first converting it to a .ppk file.
    • Upload public key file: Browse to a public key file on your computer. If you followed the steps in Creating SSH Key Pairs in the Prerequisites section to create a key pair, use this option to navigate to the .pub file.
    • Paste public key: Paste the content of your public key file into the text box.
  6. Click Create console connection.

    When the console connection has been created and is available, the state changes to Active.

Make an SSH Connection to the Serial Console

After you create the console connection for the virtual machine, you can connect to the serial console using a Secure Shell (SSH) connection. When making an SSH connection to the serial console, you must use an RSA key. You can use the same SSH key for the serial console that was used when you launched the instance, or you can use a different SSH key.

When you are finished with the serial console and have terminated the SSH connection, you should delete the serial console connection. If you do not disconnect from the session, Oracle Cloud Infrastructure terminates the serial console session after 24 hours and you must reauthenticate to connect again.

Validate Server Host Keys

When you first connect to the serial console, you're prompted to validate the fingerprint of the server host key. The fingerprint of the server host key is the SHA256 hash of the server host's public SSH key. The server SSH handshake response is signed with the associated private key. Validating the server host key's fingerprint protects against potential attacks.

When you make a manual connection to the serial console, the fingerprint of the server host key is not automatically validated. To manually validate the fingerprint, compare the fingerprint value displayed in the Oracle Cloud Infrastructure Console to the value of the RSA key fingerprint that appears in the terminal when you connect.

To find the fingerprint of the server host key in the Console, on the Virtual Machine details page, under Resources, click Console connection. The table displays the fingerprint of the server host key. The fingerprint in the Console should match the value of the RSA key fingerprint shown in the terminal when you connect to the serial console.

The server host keys are periodically rotated for security purposes. Key rotation reduces the risk posed when keys are compromised by limiting the amount of data encrypted or signed by one key version. When your key is rotated and you try to connect to the serial console, a warning appears indicating a potential attack. The warning includes an Host key verification failed error and a line number in your .ssh/known_hosts file. Delete that line in your .ssh/known_hosts file and then reconnect to the serial console. You are then prompted to accept a new server host key fingerprint.

Connect from Mac OS X and Linux Operating Systems

Use an SSH client to connect to the serial console. Mac OS X and most Linux and UNIX-like operating systems include the SSH client OpenSSH by default.

To connect to the serial console using OpenSSH on Mac OS X or Linux

  1. Open the navigation menu. Under Oracle Database, click Exadata Database Service on Cloud@Customer.
  2. Click the VM Cluster that you're interested in.
  3. In the resulting VM Cluster Details page, click the name of the virtual machine that you're interested in.
  4. On the Virtual Machine details page in the Oracle Cloud Infrastructure Console, under Resources, click Console connection.
  5. Click the Actions menu (three dots), and then click Copy serial console connection for Linux/Mac.
  6. Paste the connection string into a terminal window on a Mac OS X or Linux system, and then press Enter to connect to the console.

    If you are not using the default SSH key or ssh-agent, modify the serial console connection string to include the identity file flag, -i to specify the private key portion for the SSH key to use, for example, id_rsa. Specify this flag for both the SSH connection and the SSH ProxyCommand, as shown in the following line:

    ssh -i /<path>/<ssh_key> -o ProxyCommand='ssh -i /<path>/<ssh_key> -W %h:%p -p 443...
  7. If prompted, validate and accept the fingerprint of the server host key.

    If you have previously accepted a fingerprint for the server host key but the key has been rotated, a warning appears indicating a potential attack. The warning includes an Host key verification failed error and a line number in your .ssh/known_hosts file. Delete the specified line in your .ssh/known_hosts file and then reconnect to the serial console. Validate and accept the new server host key fingerprint.

  8. Press Enter again to activate the console.

    If the connection is active, a message appears in the console:

    =================================================
    IMPORTANT: You are now connected to the serial console for this VM. This should be used in emergency situations only.
    
    See product documentation for more details and alternative connectivity options for normal operations
    =================================================
  9. Reboot your virtual machine.

    You do not need to enter a username or password. If the Virtual Machine is functional and the connection is active, the serial output appears in your console. If the serial output does not appear in the console, the Guest VM operating system is not booting.

    For more troubleshooting options, see Troubleshooting Virtual Machines from Guest VM Console Connections on Linux Operating Systems.

    1. Go to the ExaDB-C@C VM Cluster Details page.
    2. Under Resources, click Virtual Machines.
    3. Select Reboot from the Actions menu (three dots) for the virtual machine that you want to reboot.
Connect from Windows Operating Systems

The steps to connect to the serial console from Microsoft Windows PowerShell are different from the steps for OpenSSH. The following steps do not work in the Windows terminal.

Note

If you are connecting to the instance from a Windows client using PowerShell, plink.exe is required. plink.exe is the command link connection tool included with PuTTY. You can install PuTTY or install plink.exe separately. For more information, see Installing an SSH Client and a Command-line Shell (Windows).

To connect to the serial console on Microsoft Windows

  1. On the Virtual Machine details page in the Oracle Cloud Infrastructure Console, under Resources, click Console connection.
  2. Click the Actions menu (three dots).

    Depending on which SSH client you are using, do one of the following:

    • If you are using Windows PowerShell, click Copy serial console connection for Windows.
    • If you are using OpenSSH, click Copy serial console connection for Linux/Mac.
    Note

    The copied connection string for Windows contains the parameter -i specifying the location of the private key file. The default value for this parameter in the connection string references an environment variable that might not be configured on your Windows client, or it might not represent the location where the private key file is saved. Verify the value specified for the -i parameter and make any required changes before proceeding to the next step.

  3. Paste the connection string copied from the previous step into a text file so that you can add the file path to the private key file.
  4. In the text file, replace $env:homedrive$env:homepath\oci\console.ppk with the file path to the .ppk file on your computer. This file path appears twice in the string. Replace it in both locations.
  5. Paste the modified connection string into the PowerShell window or your OpenSSH client, and then press Enter to connect to the console.
  6. If prompted, validate and accept the fingerprint of the server host key.
    If you have previously accepted a fingerprint for the server host key, but the key has been rotated, a warning appears indicating a potential attack. The warning includes a Host key verification failed error and a line number in your .ssh/known_hosts file. Delete the specified line in your .ssh/known_hosts file and then reconnect to the serial console. Validate and accept the new server host key fingerprint.
  7. Press Enter again to activate the console.
  8. Reboot your virtual machine.

    You do not need to enter a username or password. If the Virtual Machine is functional and the connection is active, the serial output appears in your console. If the serial output does not appear in the console, the Guest VM operating system is not booting.

    For more troubleshooting options, see Troubleshooting Virtual Machines from Guest VM Console Connections.

    1. Go to the ExaDB-C@C VM Cluster Details page.
    2. Under Resources, click Virtual Machines.
    3. Select Reboot from the Actions menu (three dots) for the virtual machine that you want to reboot.
To create a connection using the SSH key pair generated using the OCI Console

Do the following on the Create serial console access window:
  1. Click Generate a key pair for me.
  2. Click Save Private Key.
  3. Click Create console connection.
    Note

    Ensure that you are using the latest version of PuTTY, see http://www.putty.org.

  4. Find puttygen.exe in the PuTTY folder on your computer, for example, C:\Program Files (x86)\PuTTY. Double-click puttygen.exe to open it.
  5. On the PuTTY Key Generator, click the Conversions menu and then click Import.
  6. On the Windows Explorer, select OCI Console generated SSH key (step 1) and then click Open.

    PuTTY imports the key and displays information about key on the PuTTY Key Generator window.

  7. Click Save private key.
  8. Click Yes when prompted about saving the key without a passphrase.

    The key pair is saved in the PuTTY Private Key (PPK) format, which is the proprietary format that works only with the PuTTY tool set.

    You can name the key anything you want, but use the .ppk file extension. For example, $HOME\Desktop\key-vm-console.ppk.

  9. Use a text editor to change the command to point to your PuTTY Private Key (PPK) path. Replace <PATH_FILE_PUTTY_PRIVATE.ppk> to point to your PuTTY Private Key (PPK) file path on your computer. For example, if you have saved .ppk file at $HOME\Desktop\key-vm-console.ppk.
  10. Paste the modified connection string into the PowerShell window, and then press Enter to connect to the console.
To convert a generated .key private key file

  1. Open PuTTYgen.
  2. Click Load, and select the private key generated when you created the instance.
    The extension for the key file is .key.
  3. Click Save private key.
  4. Specify a name for the key.
    The extension for the new private key is .ppk.
  5. Click Save.

Using Cloud Shell to Connect to the Serial Console

You can connect to the serial console quickly and easily using the Cloud Shell integration. Cloud Shell is a web browser-based terminal accessible from the Console. The Cloud Shell integration automatically creates the instance console connection and a temporary SSH key. The only prerequisite for connecting to the serial console from Cloud Shell is granting users the correct permissions. For an introductory walkthrough of using Cloud Shell, see Using Cloud Shell.

Note

  • By default, Cloud Shell limits network access to OCI internal resources in your tenancy home region only unless you have enabled the Cloud Shell managed Public Network. Your administrator must configure an Identity policy to enable Cloud Shell Public Network. For more information, see Cloud Shell Networking.
  • You cannot concurrently connect to more than one DB node using Cloud Shell. As an example, if you have an open connection to DBnode1 and want to connect to DBnode2, you must first exit the active Cloud Shell from DBnode1 and then establish a connection to DBnode2.
  • Ensure that the firewall rules are correct so that the Control Plane Server (CPS) can reach the required OCI endpoints. For more information, see Table 3-2

When you are finished with the serial console and have terminated the SSH connection, you should delete the serial console connection. If you do not disconnect from the session, Oracle Cloud Infrastructure terminates the serial console session after 24 hours and you must re-authenticate to connect again.

To connect to the serial console using Cloud Shell

  1. Sign in to the Console.
  2. Open the navigation menu. Under Oracle Database, click Exadata Database Service on Cloud@Customer.
  3. On the instance details page in the Oracle Cloud Infrastructure Console, under Resources, click Console connection.
  4. Click Launch Cloud Shell connection.

    This action displays the Cloud Shell in a "drawer" at the bottom of the Console.

  5. If a console connection already exists, you are asked if you want to delete the existing resource. Press y, and then press Enter.
  6. When you are done, exit the instance console connection.

Displaying the Console History for a Virtual Machine

Note

To access the serial console and to use console history, firewall rules must be configured so that the Control Plane Server (CPS) can access the necessary OCI endpoints. Please review Table 3-2 details for Object Storage and VM console connectivity requirements.

You can capture and display recent serial console data for a Virtual Machine. The data includes configuration messages that occur when the Virtual Machine boots, such as kernel and BIOS messages, and is useful for checking the status of the Virtual Machine or diagnosing and troubleshooting problems.

The console history captures up to a megabyte of the most recent serial console data for the specified Virtual Machine. Note that the raw console data, including multi-byte characters, is captured.

The console history is a point-in-time record. To troubleshoot a malfunctioning Virtual Machine using an interactive console connection, use a serial console connection.

Managing Console History Data

You can use the Console or API to manage console history captures. Console history lets you see serial output from your Virtual Machine without having to connect to the instance remotely. The console history can be used to audit previous access and actions taken with the serial console.

On the instance details page in the Console, you can capture and download console histories, view and edit metadata details, and delete console history captures.

Using the Console to Capture the Console History

  1. Open the navigation menu. Under Oracle Database, click Exadata Database Service on Cloud@Customer.
  2. Click the VM Cluster that you're interested in.
  3. n the resulting VM Cluster Details page, click the name of the virtual machine that you're interested in.

    Under Resources, Console connection is selected by default.

  4. Click Console history.
  5. Click the name of the history that you're interested in.
  6. In the resulting window, click Download to download a copy of the console history.
  7. Click Save and close.to save the history and close the window.
Using the Console to Download Console History Captures

  1. Open the navigation menu. Under Oracle Database, click Exadata Database Service on Cloud@Customer.
  2. Click the VM Cluster that you're interested in.
  3. n the resulting VM Cluster Details page, click the name of the virtual machine that you're interested in.

    Under Resources, Console connection is selected by default.

  4. Click Console history.
  5. Click the name of the history that you're interested in.
  6. In the resulting window, click Download to download a copy of the console history.
Using the Console to View Console History Captures

  1. Open the navigation menu. Under Oracle Database, click Exadata Database Service on Cloud@Customer.
  2. Click the VM Cluster that you're interested in.
  3. n the resulting VM Cluster Details page, click the name of the virtual machine that you're interested in.

    Under Resources, Console connection is selected by default.

  4. Click Console history.
  5. Click the name of the history that you're interested in.
  6. In the console history list, for the console history capture that you want to view, click the Actions menu, and then click View details.
Using the Console to View and Edit the Metadata Details of a Console History Capture

  1. Open the navigation menu. Under Oracle Database, click Exadata Database Service on Cloud@Customer.
  2. Click the VM Cluster that you're interested in.
  3. n the resulting VM Cluster Details page, click the name of the virtual machine that you're interested in.

    Under Resources, Console connection is selected by default.

  4. Click Console history.
  5. In the console history list, for the console history capture that you want to view, click the Actions menu, and then click View details.
  6. Optionally, edit the name for the console history. Avoid entering confidential information.
  7. To view or edit tags, click Show tagging options.
  8. To edit or remove tags, click the edit icon next to the tag. To edit a tag, in the Edit Tag dialog, make any changes, and then click Save. To remove a tag, click Remove Tag.
  9. Click Save and close.
Using the Console to Delete Console History Captures

  1. Open the navigation menu. Under Oracle Database, click Exadata Database Service on Cloud@Customer.
  2. Click the VM Cluster that you're interested in.
  3. n the resulting VM Cluster Details page, click the name of the virtual machine that you're interested in.

    Under Resources, Console connection is selected by default.

  4. Click Console history.
  5. In the console history list, for the console history capture that you want to view, click the Actions menu, and then click Delete.
  6. In the confirmation dialog, click Delete console history.
Using the API to Manage the Console History Data

Review the list of API calls to manage console history data.

For information about using the API and signing requests, see REST APIs and Security Credentials. For information about SDKs, see Software Development Kits and Command Line Interface.

For the complete list of APIs, see Database Service API.

Use the following API operations to manage the console history data.

  • To capture the console history, use the createDbNodeConsoleHistory method.
  • To get details of console history metadata, use the getDbNodeConsoleHistory method.
  • To get the details of console history content, use the getDbNodeConsoleHistoryContent method.
  • To edit console history metadata, use the updateDbNodeConsoleHistory method.
  • To list console history captures, use the listDbNodeConsoleHistories method.
  • To delete console history captures, use the deleteDbNodeConsoleHistory method.

Troubleshooting Virtual Machines from Guest VM Console Connections on Linux Operating Systems

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

  • Edit system configuration files.
  • Add or reset the SSH keys for the opc user.
  • Reset the password for the opc user.

These tasks require you to boot into a Bash shell in maintenance mode.

To boot into maintenance mode

Note

Default user and password:
  • Account: Grub boot loader
  • Username: root
  • Default Password: sos1Exadata
  • Account Type: Operating system user

For more information, see Default User Accounts for Oracle Exadata.

  1. Reboot the VM from the VM Cluster.
  2. For virtual machines running Oracle Linux 7.x or Oracle Linux 8.x, when the reboot process starts, switch back to the terminal window, and you see Console messages start to appear in the window. As soon as the GRUB boot menu appears, use the up/down arrow key to stop the automatic boot process, enabling you to use the boot menu.
  3. In the boot menu, highlight the top item in the menu, and press e to edit the boot entry.
  4. In edit mode, use the down arrow key to scroll down through the entries until you reach the line that starts with linux16.
  5. At the end of that line, add the following:
    init=/bin/bash
  6. Reboot the instance from the terminal window by entering the keyboard shortcut CTRL+X.

    When the instance has rebooted, you see the Bash shell command-line prompt, and you can proceed with the following procedures.

To edit the system configuration files

  1. From the Bash shell, run the following command to load the SElinux policies to preserve the context of the files you are modifying:
    /usr/sbin/load_policy -i
  2. Run the following command to remount the root partition with read/write permissions:
    /bin/mount -o remount, rw /
  3. Edit the configuration files as needed to try to recover the instance.
  4. After you have finished editing the configuration files, to start the instance from the existing shell, run the following command:
    exec /usr/lib/systemd/systemd
    Alternatively, to reboot the instance, run the following command:
    /usr/sbin/reboot -f
To add or reset the SSH key for the opc user

  1. From the Bash shell, run the following command to load the SElinux policies to preserve the context of the files you are modifying:
    /usr/sbin/load_policy -i
  2. Run the following command to remount the root partition with read/write permissions:
    /bin/mount -o remount, rw /
  3. From the Bash shell, run the following command to change to the SSH key directory for the opc user:
    cd ~opc/.ssh
  4. Include your public key entry to the authorized_keys file.
    Note

    You can edit the file and remove your previous key if you want to. However, make sure to keep the cloud automation keys to prevent cloud automation from breaking.
    echo '<contents of public key file>' >> authorized_keys
  5. Restart the instance by running the following command:
    /usr/sbin/reboot -f
To reset the password for the opc user

  1. From the Bash shell, run the following command to load the SElinux policies to preserve the context of the files you are modifying.

    This step is necessary to sign in to your instance using SSH and the Console.

    /usr/sbin/load_policy -i
  2. Run the following command to remount the root partition with read/write permissions:
    /bin/mount -o remount, rw /
  3. Run the following command to reset the password for the opc user:
    sudo passwd opc
  4. Restart the instance by running the following command:
    sudo reboot -f
    Note

    Setting a root password would be an acceptable alternative to setting an opc password.

Exiting the Virtual Machine Serial Console Connection

To exit the serial console connection

When using SSH, the ~ character at the beginning of a new line is used as an escape character.

  1. To exit the serial console, enter:
    ~.
  2. To suspend the SSH session, enter:
    ~^z

    The ^ character represents the CTRL key.

  3. To see all the SSH escape commands, enter:
    ~?
To delete the serial console connection for a Virtual Machine

  1. Open the navigation menu. Under Oracle Database, click Exadata Database Service on Cloud@Customer.
  2. Click the VM Cluster that you're interested in.
  3. In the resulting VM Cluster Details page, click the name of the virtual machine that you're interested in.

    Under Resources, Console connection is selected by default.

  4. Click the Actions menu, and then click Delete. Confirm when prompted.