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:
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.
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.
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
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:
http://docs.oracle.com/cd/E27363_01/doc.121/e27511/ftr_vdc_mgmt.htm
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 vServer Types.
One or more virtual networks
For more information, see 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.