7 Task Overviews and Basic Concepts

This chapter introduces some of the important tasks performed by users with the Exalogic Systems Admin, Cloud Admin, and Cloud User roles. It also describes a few basic concepts.

This chapter contains the following sections:

7.1 Cloud Admin Tasks

This section introduces the following tasks:

7.1.1 Account Creation

An Account entitles designated Cloud Users the authorization to use computing, network, and storage resources of the Exalogic vDC. The Account provides the required capabilities to manage these resources.

The following are the prerequisites for creating an account:

  • Estimate the resource quotas to be allocated for the account

  • Identify the Cloud Users to be assigned to the account

The quota for vCPU, memory, and storage resources are defined during Account creation. The Resource Quota Information display in the account wizard creation indicates how much of the corresponding vDC resources can be used. It also displays whether the vDC resources are oversubscribed or undersubscribed.

You can configure an account to be able create a maximum of 4096 private vNets in an account. You can set the limit of number of private vNets that can be created in an account. The allowable number of defined networks is a function of the server pool configuration defined in the Exalogic vDC. Within each server pool, you can create a maximum of 64 private networks. However, note that some networks are already defined for use by Exalogic Control.

During Account creation, the public networks that are available in the vDC are listed. You can set the number of public IP addresses allocated to the account from this resource. This public IP address can be used by the Cloud User to assign to the vServer, as required. You can choose what defined public networks are available to each Account.

You provide an entitlement to the virtual resources for an account. You allocate the resources from the vDC to an account. The resource allocation for all of the accounts in a vDC can be more than the actual resources in a vDC. This oversubscription of the resources must be identified and planned for a vDC. You must configure the virtual resources for an account properly and update the resource configuration when the requirement increases. If an account does not have enough resources, then the Cloud User will get notifications that they cannot create vServers if the resources are not available.As a Cloud Admin user, you must watch the resource usage and configure resources for an account. You can create as many or few Accounts as your business requires. By doing so, you can partition the Exalogic vDC by Account, based on resource allocation.

7.1.2 Account Management

As a Cloud Admin user, you can update the resource configuration for an account, assign Cloud Users to an account, and delete an account.

You can assign Cloud Users to an account during account creation or separately. Cloud Users have access to only the specific Accounts to which they are added. As a Cloud Admin user, you can manage the access of the Cloud Users to all Accounts in the Exalogic vDC.

7.1.3 vServer Types

A vServer Type is a profile that defines the memory and virtual CPUs to be allocated to vServers creating by using that profile. A Cloud User is restricted to using these definitions to create vServers.

The following default system-defined vServer types are available in the Exalogic vDC:

  • EXTRA_LARGE: 16 GB memory and 4 vCPUs

  • LARGE: 8 GB memory and 2 vCPUs

  • SMALL: 4 GB memory and 1 vCPU

As a Cloud Admin user, you can create additional vServer types and delete them. However, you cannot delete the system-defined vServer types. For information about creating vServer types, see Section 9.1.3, "Creating vServer Types."

When you create a vServer type, the following information is displayed in the wizard, based on the resources defined:

  • The number of Oracle VM Servers in the Exalogic vDC that have sufficient physical resources to host a vServer with the selected resources

  • An estimation of the number of vServers that can be hosted using the available physical resources in the vDC

7.2 Cloud User Tasks

A Cloud User with access to an account is entitled to manage and use computing, network, and storage resources in an Exalogic vDC within the limits of the account quotas.Cloud Users can create and manage the life cycle of vServers for their applications. To accomplish this, a Cloud User can manage the following virtual resources for an account:

7.2.1 Virtual Network Resources

Virtual networks restrict the network connectivity of a vServer. Virtual network management involves connecting and restricting the network access to vServers.

The following types of virtual networks are visible to a Cloud User:

  • Public External Networks

    Defined by Cloud Admin users. Cloud Users cannot create, update, or delete this type of vNet. This type of virtual network can be shared among a number of Accounts in an Exalogic vDC. vServers that are members of public external vNets also have external communication beyond the Exalogic vDC, and they can be used to host public services. A separate IP can be allocated to this type of virtual network.

  • Private vNets

    Defined by Cloud Users according to their requirements and within the limits of the account quota. A private vNet is created based on the private network from the network domain of the Exalogic vDC. Private vNets are only accessible within an account. All vServers that have membership of a private vNet in common can communicate freely through that subnet.

A Cloud User defines the public external vNet or private vNets to which a vServer is assigned. Membership of a vServer to one or more vNets can only be specified at vServer creation time. Cloud Users can also reserve a number of IP addresses from any existing virtual network. Reserved IP addresses can be used later for static allocation to vServers.

When creating vServers, a Cloud User chooses one of the following methods available to allocate IP addresses to vServer:

  • Static method

    This method requires a reserved IP address from each selected virtual network to the vServer. This method can be used only when creating a single vServer at a time.

  • Automatic method

    This method dynamically allocates an IP address from each selected virtual network. This method is used when creating multiple vServers at a time.

A Cloud User can release a reserved IP address that is not allocated to a vServer. IP addresses dynamically allocated to vServers are released automatically when the vServers are deleted.

A vNet has the following attributes visible to Cloud Users:

  • Name - An identifier in the system for the vNet.

  • Description - Descriptive text for the vNet.

  • Type - Private vNet or public external vNet.

  • Subnet - Defines the IP address range for a vNet.

  • Allocatable Addresses - The maximum number of IP addresses that can be allocated to vServers from a vNet.

  • Reserved Addresses - The number of reserved IP addresses.

  • Status - The current status of the vNet.

  • Tags - Available tags for a vNet. Tags can be used for better identification and classification of the vNet.

7.2.2 Server Templates

A Server Template is an OS image in a certain format that can be used to create a vServer. Server templates are specific to processor architecture of the server pool and virtualization type. A server template is needed for creating vServers.

Server templates are loaded into the central software library associated with the Exalogic vDC and cannot be changed later. By default, a server template is bound to a specific Account. You can register a server template for public use within any Account inside the Exalogic vDC.

You can upload a new server template to be used for creating vServers. A server template has the following attributes visible to Cloud Users:

  • Name: An identifier in the system for the server template.

  • Description: Descriptive text for the server template.

  • Size: Size of the server template in GB.

  • Memory: Memory defined in GB for the server template.

  • OS: Type of operating system defined for the server template.

  • CPUs: The number of CPUs defined for the server template.

  • Assembly: The name of the assembly of the server template. This field is empty because you are uploading the server template using a template sub-type file.

  • Public: The field that indicates if the server template is shared with other Accounts in the Exalogic vDC.

  • Tags: Available tags for a server template. Tags can be used for better identification and classification of the server template.

7.2.3 Virtual Storage Resources

The following types of storage resources are visible to Cloud Users in the Exalogic vDC:

  • vServer Root Disks

    Root disks are created at vServer creation time based on the server template. This is the disk in which a vServer OS operates. Root disks are available after a vServer reboot, and a root disk is deleted only when a vServer is deleted.

    A vServer root disk has the following attributes visible to Cloud Users:

    vServer, Size (GB), Status, and Created By

  • Volumes

    A volume is a virtual block storage device that can be attached or detached from vServers. Cloud Users can attach one or more volumes to a vServer at vServer creation time or at a later time to a stopped vServer. Storage space for volumes is limited by Account's quota.Cloud Users can create an empty volume, create a volume from a snapshot, or import a volume from an HTTP server.

    Volumes can be shared at volume's creation time. If a volume is shared, the volume can be attached to multiple vServers. Volumes that are not attached to any vServer can be deleted.

    A volume has the following attributes visible to Cloud Users:

    Name, Description, Max Size (GB), Usage Size (GB), Attached To, Share Status, Use Status, Root Volume, R/W, Created By, Status, and Tags

  • Snapshots

    A snapshot is a clone of a volume at a specific time. The snapshot captures the current state of the volume and is immutable.

    Cloud Users can create a snapshot from an existing volume. They can create a volume from a snapshot and attach those volumes to vServers at vServer creation time or later time to a stopped vServer. Deletion of a volume does not influence any snapshot that has been created previously based on that volume. Snapshots exist independently of the volume.

    A snapshot has the following attributes visible to Cloud Users:

    Name, Description, Max Size (GB), Usage Size (GB), Attached To, Share Status, Use Status, Root Volume, R/W, Created By, Status, and Tags

7.2.4 Distribution Groups

You can place your vServers in a distribution group to ensure that no two vServers in the distribution group run on the same Oracle VM Server. Distribution groups are bound to a specific account. vServers can be assigned to a distribution group only at vServer creation time. Cloud users can create, update, or delete their distribution groups.

For more information, see the Oracle Enterprise Manager Ops Center Feature Reference Guide at:


7.2.5 vServers

A vServer is an entity that provides the outward interface of a standalone operating system. This is a Virtual Machine. It consumes CPU and memory resources. It can be a member of one or multiple vNets. A vServer has its own identity, local storage, interfaces, and configuration that exist for the full lifetime of the vServer.

Cloud Users can create a single or multiple vServers at a time. When creating multiple vServers, only automatic IP address assignment is possible, and a suffix is added to the vServer name for each vServer. When you create a single vServer, you can assign a static IP address. In this case, a suffix is not added to the name of the vServer.

A Cloud User should make sure the following required resources exist before creating a vServer:

  • A server template

  • A vServer type

    Cloud users can only select a vServer type from the existing vServer types for the account. They are visible to Cloud Users during the vServer creation process. Only Cloud Admin users can create new vServer types. For more information about vServer types, see Section 7.1.3, "vServer Types".

  • One or more virtual networks

    For more information, see Section 7.2.1, "Virtual Network Resources".

Depending on their specific requirements, Cloud Users can also define in advance the following resources to be used during the vServer creation process:

  • Reserved IP addresses

  • Distribution groups

  • Volumes

  • Public key

A vServer has the following attributes visible to cloud users:

Name, Description, Created By, Creation Date, Memory Size (GB), #CPUs, OS, Status, and Tags

After creating vServers, Cloud Users can manage the life cycle of vServers. For example, they can create, start, stop, and destroy vServers.