nova/api-guide/source/server_concepts.rst

Server concepts

For the OpenStack Compute API, a server is a virtual machine (VM) instance, a physical machine or a container.

Server status

You can filter the list of servers by image, flavor, name, and status through the respective query parameters.

Server contains a status attribute that indicates the current server state. You can filter on the server status when you complete a list servers request. The server status is returned in the response body. The server status is one of the following values:

Server status values

• ACTIVE: The server is active.
• BUILD: The server has not yet finished the original build process.
• DELETED: The server is deleted.
• ERROR: The server is in error.
• HARD_REBOOT: The server is hard rebooting. This is equivalent to pulling the power plug on a physical server, plugging it back in, and rebooting it.
• MIGRATING: The server is migrating. This is caused by a live migration (moving a server that is active) action.
• PASSWORD: The password is being reset on the server.
• PAUSED: The server is paused.
• REBOOT: The server is in a soft reboot state. A reboot command was passed to the operating system.
• REBUILD: The server is currently being rebuilt from an image.
• RESCUE: The server is in rescue mode.
• RESIZE: Server is performing the differential copy of data that changed during its initial copy. Server is down for this stage.
• REVERT_RESIZE: The resize or migration of a server failed for some reason. The destination server is being cleaned up and the original source server is restarting.
• SHELVED: The server is in shelved state. Depends on the shelve offload time, the server will be automatically shelved off loaded.
• SHELVED_OFFLOADED: The shelved server is offloaded (removed from the compute host) and it needs unshelved action to be used again.
• SHUTOFF: The server was powered down by the user, either through the OpenStack Compute API or from within the server. For example, the user issued a shutdown -h command from within the server. If the OpenStack Compute manager detects that the VM was powered down, it transitions the server to the SHUTOFF status.
• SOFT_DELETED: The server is marked as deleted but will remain in the cloud for some configurable amount of time. While soft-deleted, an authorized user can restore the server back to normal state. When the time expires, the server will be deleted permanently.
• SUSPENDED: The server is suspended, either by request or necessity. See the feature support matrix <user/support-matrix.html#operation_suspend> for supported compute drivers. When you suspend a server, its state is stored on disk, all memory is written to disk, and the server is stopped. Suspending a server is similar to placing a device in hibernation and its occupied resource will not be freed but rather kept for when the server is resumed. If an instance is infrequently used and the occupied resource needs to be freed to create other servers, it should be shelved.
• UNKNOWN: The state of the server is unknown. It could be because a part of the infrastructure is temporarily down (see down_cells for more information). Contact your cloud provider.
• VERIFY_RESIZE: System is awaiting confirmation that the server is operational after a move or resize.

Server status is calculated from vm_state and task_state, which are exposed to administrators:

• vm_state describes a VM's current stable (not transition) state. That is, if there is no ongoing compute API calls (running tasks), vm_state should reflect what the customer expect the VM to be. When combined with task states, a better picture can be formed regarding the server's health and progress. Refer to VM States <reference/vm-states.html>.
• task_state represents what is happening to the instance at the current moment. These tasks can be generic, such as spawning, or specific, such as block_device_mapping. These task states allow for a better view into what a server is doing.

Server creation

Status Transition:

• BUILD

  While the server is building there are several task state transitions that can occur:

  • scheduling: The request is being scheduled to a compute node.
  • networking: Setting up network interfaces asynchronously.
  • block_device_mapping: Preparing block devices (local disks, volumes).
  • spawning: Creating the guest in the hypervisor.

• ACTIVE

  The terminal state for a successfully built and running server.

• ERROR (on error)

  When you create a server, the operation asynchronously provisions a new server. The progress of this operation depends on several factors including location of the requested image, network I/O, host load, and the selected flavor. The progress of the request can be checked by performing a GET on /servers/{server_id}, which returns a progress attribute (from 0% to 100% complete). The full URL to the newly created server is returned through the Location header and is available as a self and bookmark link in the server representation. Note that when creating a server, only the server ID, its links, and the administrative password are guaranteed to be returned in the request. You can retrieve additional attributes by performing subsequent GET operations on the server.

Server query

There are two APIs for querying servers GET /servers and GET /servers/detail. Both of those APIs support filtering the query result by using query options.

For different user roles, the user has different query options set:

• For general user, there is limited set of attributes of the servers can be used as query option. The supported options are:

  • changes-since
  • flavor
  • image
  • ip
  • ip6 (New in version 2.5)
  • name
  • not-tags (New in version 2.26)
  • not-tags-any (New in version 2.26)
  • reservation_id
  • status
  • tags (New in version 2.26)
  • tags-any (New in version 2.26)
  • changes-before (New in version 2.66)
  • locked (New in version 2.73)
  • availability_zone (New in version 2.83)
  • config_drive (New in version 2.83)
  • key_name (New in version 2.83)
  • created_at (New in version 2.83)
  • launched_at (New in version 2.83)
  • terminated_at (New in version 2.83)
  • power_state (New in version 2.83)
  • task_state (New in version 2.83)
  • vm_state (New in version 2.83)
  • progress (New in version 2.83)
  • user_id (New in version 2.83)

  Other options will be ignored by nova silently.

• For administrator, most of the server attributes can be used as query options. Before the Ocata release, the fields in the database schema of server are exposed as query options, which may lead to unexpected API change. After the Ocata release, the definition of the query options and the database schema are decoupled. That is also the reason why the naming of the query options are different from the attribute naming in the servers API response.

Precondition: there are 2 servers existing in cloud with following info:

{
    "servers": [
        {
            "name": "t1",
            "OS-EXT-SRV-ATTR:host": "devstack1",
            ...
        },
        {
            "name": "t2",
            "OS-EXT-SRV-ATTR:host": "devstack2",
            ...
        }
    ]
}

Example: General user query server with administrator only options

Request with non-administrator context: GET /servers/detail?host=devstack1

Note

The host query parameter is only for administrator users and the query parameter is ignored if specified by non-administrator users. Thus the API returns servers of both devstack1 and devstack2 in this example.

Response:

{
    "servers": [
        {
            "name": "t1",
            ...
        },
        {
            "name": "t2",
            ...
        }
    ]
}

Example: Administrator query server with administrator only options

Request with administrator context: GET /servers/detail?host=devstack1

Response:

{
    "servers": [
        {
            "name": "t1",
            ...
        }
    ]
}

There are also some special query options:

• changes-since returns the servers updated after the given time. Please see: polling_changes
• changes-before returns the servers updated before the given time. Please see: polling_changes
• deleted returns (or excludes) deleted servers
• soft_deleted modifies behavior of 'deleted' to either include or exclude instances whose vm_state is SOFT_DELETED
• all_tenants is an administrator query option, which allows the administrator to query the servers in any tenant.

Example: User query server with special keys changes-since or changes-before

Request: GET /servers/detail

Response:

{
    "servers": [
        {
            "name": "t1",
            "updated": "2015-12-15T15:55:52Z",
            ...
        },
        {
            "name": "t2",
            "updated": "2015-12-17T15:55:52Z",
            ...
        }
    ]
}

Request: GET /servers/detail?changes-since='2015-12-16T15:55:52Z'

Response:

{
    {
        "name": "t2",
        "updated": "2015-12-17T15:55:52Z",
        ...
    }
}

Request: GET /servers/detail?changes-before='2015-12-16T15:55:52Z'

Response:

{
    {
        "name": "t1",
        "updated": "2015-12-15T15:55:52Z",
        ...
    }
}

Request: GET /servers/detail?changes-since='2015-12-10T15:55:52Z'&changes-before='2015-12-28T15:55:52Z'

Response:

{
    "servers": [
        {
            "name": "t1",
            "updated": "2015-12-15T15:55:52Z",
            ...
        },
        {
            "name": "t2",
            "updated": "2015-12-17T15:55:52Z",
            ...
        }
    ]
}

There are two kinds of matching in query options: Exact matching and regex matching.

Example: User query server using exact matching on host

Request with administrator context: GET /servers/detail

Response:

{
    "servers": [
        {
            "name": "t1",
            "OS-EXT-SRV-ATTR:host": "devstack"
            ...
        },
        {
            "name": "t2",
            "OS-EXT-SRV-ATTR:host": "devstack1"
            ...
        }
    ]
}

Request with administrator context: GET /servers/detail?host=devstack

Response:

{
    "servers": [
        {
            "name": "t1",
            "OS-EXT-SRV-ATTR:host": "devstack"
            ...
        }
    ]
}

Example: Query server using regex matching on name

Request with administrator context: GET /servers/detail

Response:

{
    "servers": [
        {
            "name": "test11",
            ...
        },
        {
            "name": "test21",
            ...
        },
        {
            "name": "t1",
            ...
        },
        {
            "name": "t14",
            ...
        }
    ]
}

Request with administrator context: GET /servers/detail?name=t1

Response:

{
    "servers": [
        {
            "name": "test11",
            ...
        },
        {
            "name": "t1",
            ...
        },
        {
            "name": "t14",
            ...
        }
    ]
}

Example: User query server using exact matching on host and regex matching on name

Request with administrator context: GET /servers/detail

Response:

{
    "servers": [
        {
            "name": "test1",
            "OS-EXT-SRV-ATTR:host": "devstack"
            ...
        },
        {
            "name": "t2",
            "OS-EXT-SRV-ATTR:host": "devstack1"
            ...
        },
        {
            "name": "test3",
            "OS-EXT-SRV-ATTR:host": "devstack1"
            ...
        }
    ]
}

Request with administrator context: GET /servers/detail?host=devstack1&name=test

Response:

{
    "servers": [
        {
            "name": "test3",
            "OS-EXT-SRV-ATTR:host": "devstack1"
            ...
        }
    ]
}

Request: GET /servers/detail?changes-since='2015-12-16T15:55:52Z'

Response:

{
    {
        "name": "t2",
        "updated": "2015-12-17T15:55:52Z"
        ...
    }
}

Server actions

• Reboot

  Use this function to perform either a soft or hard reboot of a server. With a soft reboot, the operating system is signaled to restart, which allows for a graceful shutdown of all processes. A hard reboot is the equivalent of power cycling the server. The virtualization platform should ensure that the reboot action has completed successfully even in cases in which the underlying domain/VM is paused or halted/stopped.

• Rebuild

  Use this function to remove all data on the server and replaces it with the specified image. Server ID, flavor and IP addresses remain the same.

• Evacuate

  Should a nova-compute service actually go offline, it can no longer report status about any of the servers on it. This means they'll be listed in an 'ACTIVE' state forever.

  Evacuate is a work around for this that lets an administrator forcibly rebuild these servers on another node. It makes no guarantees that the host was actually down, so fencing is left as an exercise to the deployer.

• Resize (including Confirm resize, Revert resize)

  Use this function to convert an existing server to a different flavor, in essence, scaling the server up or down. The original server is saved for a period of time to allow rollback if there is a problem. All resizes should be tested and explicitly confirmed, at which time the original server is removed. The resized server may be automatically confirmed based on the administrator's configuration of the deployment.

  Confirm resize action will delete the old server in the virt layer. The spawned server in the virt layer will be used from then on. On the contrary, Revert resize action will delete the new server spawned in the virt layer and revert all changes. The original server will be used from then on.

• Pause, Unpause

  You can pause a server by making a pause request. This request stores the state of the VM in RAM. A paused server continues to run in a frozen state.

  Unpause returns a paused server back to an active state.

• Suspend, Resume

  Administrative users might want to suspend a server if it is infrequently used or to perform system maintenance. When you suspend a server, its VM state is stored on disk, all memory is written to disk, and the virtual machine is stopped. Suspending a server is similar to placing a device in hibernation; memory and vCPUs become available to create other servers.

  Resume will resume a suspended server to an active state.

• Snapshot

  You can store the current state of the server root disk to be saved and uploaded back into the glance image repository. Then a server can later be booted again using this saved image.

• Backup

  You can use backup method to store server's current state in the glance repository, in the mean time, old snapshots will be removed based on the given 'daily' or 'weekly' type.

• Start

  Power on the server.

• Stop

  Power off the server.

• Delete, Restore

  Power off the given server first then detach all the resources associated to the server such as network and volumes, then delete the server.

  The configuration option 'reclaim_instance_interval' (in seconds) decides whether the server to be deleted will still be in the system. If this value is greater than 0, the deleted server will not be deleted immediately, instead it will be put into a queue until it's too old (deleted time greater than the value of reclaim_instance_interval). Administrator is able to use Restore action to recover the server from the delete queue. If the deleted server remains longer than the value of reclaim_instance_interval, it will be deleted by compute service automatically.

• Shelve, Shelve offload, Unshelve

  Shelving a server indicates it will not be needed for some time and may be temporarily removed from the hypervisors. This allows its resources to be freed up for use by someone else.

  By default the configuration option 'shelved_offload_time' is 0 and the shelved server will be removed from the hypervisor immediately after shelve operation; Otherwise, the resource will be kept for the value of 'shelved_offload_time' (in seconds) so that during the time period the unshelve action will be faster, then the periodic task will remove the server from hypervisor after 'shelved_offload_time' time passes. Set the option 'shelved_offload_time' to -1 make it never offload.

  Shelve will power off the given server and take a snapshot if it is booted from image. The server can then be offloaded from the compute host and its resources deallocated. Offloading is done immediately if booted from volume, but if booted from image the offload can be delayed for some time or infinitely, leaving the image on disk and the resources still allocated.

  Shelve offload is used to explicitly remove a shelved server that has been left on a host. This action can only be used on a shelved server and is usually performed by an administrator.

  Unshelve is the reverse operation of Shelve. It builds and boots the server again, on a new scheduled host if it was offloaded, using the shelved image in the glance repository if booted from image.

• Lock, Unlock

  Lock a server so the following actions by non-admin users are not allowed to the server.

  • Delete Server
  • Change Administrative Password (changePassword Action)
  • Confirm Resized Server (confirmResize Action)
  • Force-Delete Server (forceDelete Action)
  • Pause Server (pause Action)
  • Reboot Server (reboot Action)
  • Rebuild Server (rebuild Action)
  • Rescue Server (rescue Action)
  • Resize Server (resize Action)
  • Restore Soft-Deleted Instance (restore Action)
  • Resume Suspended Server (resume Action)
  • Revert Resized Server (revertResize Action)
  • Shelve-Offload (Remove) Server (shelveOffload Action)
  • Shelve Server (shelve Action)
  • Start Server (os-start Action)
  • Stop Server (os-stop Action)
  • Suspend Server (suspend Action)
  • Trigger Crash Dump In Server
  • Unpause Server (unpause Action)
  • Unrescue Server (unrescue Action)
  • Unshelve (Restore) Shelved Server (unshelve Action)
  • Attach a volume to an instance
  • Update a volume attachment
  • Detach a volume from an instance
  • Create Interface
  • Detach Interface
  • Create Or Update Metadata Item
  • Create or Update Metadata Items
  • Delete Metadata Item
  • Replace Metadata Items
  • Add (Associate) Fixed Ip (addFixedIp Action) (DEPRECATED)
  • Remove (Disassociate) Fixed Ip (removeFixedIp Action) (DEPRECATED)

  But administrators can perform the actions on the server even though the server is locked. By default, only owner or administrator can lock the sever, and administrator can overwrite owner's lock along with the locked_reason if it is specified.

  Unlock will unlock a server in locked state so additional operations can be performed on the server by non-admin users. By default, only owner or administrator can unlock the server.

• Rescue, Unrescue

  The rescue operation starts a server in a special configuration whereby it is booted from a special root disk image. This enables the tenant to try and restore a broken guest system.

  Unrescue is the reverse action of Rescue. The server spawned from the special root image will be deleted.

• Set administrator password

  Sets the root/administrator password for the given server. It uses an optionally installed agent to set the administrator password.

• Migrate, Live migrate

  Migrate is usually utilized by administrator, it will move a server to another host; it utilizes the 'resize' action but with same flavor, so during migration, the server will be powered off and rebuilt on another host.

  Live migrate also moves a server from one host to another, but it won't power off the server in general so the server will not suffer a down time. Administrators may use this to evacuate servers from a host that needs to undergo maintenance tasks.

• Trigger crash dump

  Trigger crash dump usually utilized by either administrator or the server's owner, it will dump the memory image as dump file into the given server, and then reboot the kernel again. And this feature depends on the setting about the trigger (e.g. NMI) in the server.

Server passwords

You can specify a password when you create the server through the optional adminPass attribute. The specified password must meet the complexity requirements set by your OpenStack Compute provider. The server might enter an ERROR state if the complexity requirements are not met. In this case, a client can issue a change password action to reset the server password.

If a password is not specified, a randomly generated password is assigned and returned in the response object. This password is guaranteed to meet the security requirements set by the compute provider. For security reasons, the password is not returned in subsequent GET calls.

Server metadata

Custom server metadata can also be supplied at launch time. The maximum size of the metadata key and value is 255 bytes each. The maximum number of key-value pairs that can be supplied per server is determined by the compute provider and may be queried via the maxServerMeta absolute limit.

Block Device Mapping

Simply speaking, Block Device Mapping describes how block devices are exposed to the server.

For some historical reasons, nova has two ways to mention the block device mapping in server creation request body:

• block_device_mapping: This is the legacy way and supports backward compatibility for EC2 API.
• block_device_mapping_v2: This is the recommended format to specify Block Device Mapping information in server creation request body.

Users cannot mix the two formats in the same request.

For more information, refer to Block Device Mapping.

For the full list of block_device_mapping_v2 parameters available when creating a server, see the API reference.

Example for block_device_mapping_v2

This will create a 100GB size volume type block device from an image with UUID of bb02b1a3-bc77-4d17-ab5b-421d89850fca. It will be used as the first order boot device (boot_index=0), and this block device will not be deleted after we terminate the server. Note that the imageRef parameter is not required in this case since we are creating a volume-backed server.

{
    "server": {
        "name": "volume-backed-server-test",
        "flavorRef": "52415800-8b69-11e0-9b19-734f1195ff37",
        "block_device_mapping_v2": [
            {
                "boot_index": 0,
                "uuid": "bb02b1a3-bc77-4d17-ab5b-421d89850fca",
                "volume_size": "100",
                "source_type": "image",
                "destination_type": "volume",
                "delete_on_termination": false
            }
        ]
    }
}

Scheduler Hints

Scheduler hints are a way for the user to influence on which host the scheduler places a server. They are pre-determined key-value pairs specified as a dictionary separate from the main server dictionary in the server create request. Available scheduler hints vary from cloud to cloud, depending on the cloud's configuration.

{
    "server": {
        "name": "server-in-group",
        "imageRef": "52415800-8b69-11e0-9b19-734f6f006e54",
        "flavorRef": "52415800-8b69-11e0-9b19-734f1195ff37"
    },
    "os:scheduler_hints": {
        "group": "05a81485-010f-4df1-bbec-7821c85686e8"
    }
}

For more information on how to specify scheduler hints refer to the create-server-detail Request section in the Compute API reference.

For more information on how scheduler hints are different from flavor extra specs, refer to this document.

Server Consoles

Server Consoles can also be supplied after server launched. There are several server console services available. First, users can get the console output from the specified server and can limit the lines of console text by setting the length. Secondly, users can access multiple types of remote consoles. The user can use novnc, rdp-html5, spice-html5, serial, and webmks (starting from microversion 2.8) through either the OpenStack dashboard or the command line. Refer to Configure remote console access <admin/remote-console-access.html>.

Server networks

Networks to which the server connects can also be supplied at launch time. One or more networks can be specified. User can also specify a specific port on the network or the fixed IP address to assign to the server interface.

Server access addresses

In a hybrid environment, the IP address of a server might not be controlled by the underlying implementation. Instead, the access IP address might be part of the dedicated hardware; for example, a router/NAT device. In this case, the addresses provided by the implementation cannot actually be used to access the server (from outside the local LAN). Here, a separate access address may be assigned at creation time to provide access to the server. This address may not be directly bound to a network interface on the server and may not necessarily appear when a server's addresses are queried. Nonetheless, clients that must access the server directly are encouraged to do so via an access address. In the example below, an IPv4 address is assigned at creation time.

Example: Create server with access IP: JSON request

{
    "server": {
        "name": "new-server-test",
        "imageRef": "52415800-8b69-11e0-9b19-734f6f006e54",
        "flavorRef": "52415800-8b69-11e0-9b19-734f1195ff37",
        "accessIPv4": "67.23.10.132"
    }
}

Note

Both IPv4 and IPv6 addresses may be used as access addresses and both addresses may be assigned simultaneously as illustrated below. Access addresses may be updated after a server has been created.

Example: Create server with multiple access IPs: JSON request

{
    "server": {
        "name": "new-server-test",
        "imageRef": "52415800-8b69-11e0-9b19-734f6f006e54",
        "flavorRef": "52415800-8b69-11e0-9b19-734f1195ff37",
        "accessIPv4": "67.23.10.132",
        "accessIPv6": "::babe:67.23.10.132"
    }
}

Moving servers

There are several actions that may result in a server moving from one compute host to another including shelve, resize, migrations and evacuate. The following use cases demonstrate the intention of the actions and the consequence for operational procedures.

Cloud operator needs to move a server

Sometimes a cloud operator may need to redistribute work loads for operational purposes. For example, the operator may need to remove a compute host for maintenance or deploy a kernel security patch that requires the host to be rebooted.

The operator has two actions available for deliberately moving work loads: cold migration (moving a server that is not active) and live migration (moving a server that is active).

Cold migration moves a server from one host to another by copying its state, local storage and network configuration to new resources allocated on a new host selected by scheduling policies. The operation is relatively quick as the server is not changing its state during the copy process. The user does not have access to the server during the operation.

Live migration moves a server from one host to another while it is active, so it is constantly changing its state during the action. As a result it can take considerably longer than cold migration. During the action the server is online and accessible, but only a limited set of management actions are available to the user.

The following are common patterns for employing migrations in a cloud:

• Host maintenance

  If a compute host is to be removed from the cloud all its servers will need to be moved to other hosts. In this case it is normal for the rest of the cloud to absorb the work load, redistributing the servers by rescheduling them.

  To prepare the host it will be disabled so it does not receive any further servers. Then each server will be migrated to a new host by cold or live migration, depending on the state of the server. When complete, the host is ready to be removed.

• Rolling updates

  Often it is necessary to perform an update on all compute hosts which requires them to be rebooted. In this case it is not strictly necessary to move inactive servers because they will be available after the reboot. However, active servers would be impacted by the reboot. Live migration will allow them to continue operation.

  In this case a rolling approach can be taken by starting with an empty compute host that has been updated and rebooted. Another host that has not yet been updated is disabled and all its servers are migrated to the new host. When the migrations are complete the new host continues normal operation. The old host will be empty and can be updated and rebooted. It then becomes the new target for another round of migrations.

  This process can be repeated until the whole cloud has been updated, usually using a pool of empty hosts instead of just one.

• Resource Optimization

  To reduce energy usage, some cloud operators will try and move servers so they fit into the minimum number of hosts, allowing some servers to be turned off.

  Sometimes higher performance might be wanted, so servers are spread out between the hosts to minimize resource contention.

Migrating a server is not normally a choice that is available to the cloud user because the user is not normally aware of compute hosts. Management of the cloud and how servers are provisioned in it is the responsibility of the cloud operator.

Recover from a failed compute host

Sometimes a compute host may fail. This is a rare occurrence, but when it happens during normal operation the servers running on the host may be lost. In this case the operator may recreate the servers on the remaining compute hosts using the evacuate action.

Failure detection can be proved to be impossible in compute systems with asynchronous communication, so true failure detection cannot be achieved. Usually when a host is considered to have failed it should be excluded from the cloud and any virtual networking or storage associated with servers on the failed host should be isolated from it. These steps are called fencing the host. Initiating these action is outside the scope of Nova.

Once the host has been fenced its servers can be recreated on other hosts without worry of the old incarnations reappearing and trying to access shared resources. It is usual to redistribute the servers from a failed host by rescheduling them.

Please note, this operation can result in data loss for the user's server. As there is no access to the original server, if there were any disks stored on local storage, that data will be lost. Evacuate does the same operation as a rebuild. It downloads any images from glance and creates new blank ephemeral disks. Any disks that were volumes, or on shared storage, are reconnected. There should be no data loss for those disks. This is why fencing the host is important, to ensure volumes and shared storage are not corrupted by two servers writing simultaneously.

Evacuating a server is solely in the domain of the cloud operator because it must be performed in coordination with other operational procedures to be safe. A user is not normally aware of compute hosts but is adversely affected by their failure.

User resizes server to get more resources

Sometimes a user may want to change the flavor of a server, e.g. change the quantity of cpus, disk, memory or any other resource. This is done by restarting the server with a new flavor. As the server is being moved, it is normal to reschedule the server to another host (although resize to the same host is an option for the operator).

Resize involves shutting down the server, finding a host that has the correct resources for the new flavor size, moving the current server (including all storage) to the new host. Once the server has been given the appropriate resources to match the new flavor, the server is started again.

After the resize operation, when the user is happy their server is working correctly after the resize, the user calls Confirm Resize. This deletes the 'before-the-resize' server that was kept on the source host. Alternatively, the user can call Revert Resize to delete the new resized server and restore the old that was stored on the source host. If the user does not manually confirm the resize within a configured time period, the resize is automatically confirmed, to free up the space the old is using on the source host.

As with shelving, resize provides the cloud operator with an opportunity to redistribute work loads across the cloud according to the operators scheduling policy, providing the same benefits as above.

Resizing a server is not normally a choice that is available to the cloud operator because it changes the nature of the server being provided to the user.

User doesn't want to be charged when not using a server

Sometimes a user does not require a server to be active for a while, perhaps over a weekend or at certain times of day. Ideally they don't want to be billed for those resources. Just powering down a server does not free up any resources, but shelving a server does free up resources to be used by other users. This makes it feasible for a cloud operator to offer a discount when a server is shelved.

When the user shelves a server the operator can choose to remove it from the compute hosts, i.e. the operator can offload the shelved server. When the user's server is unshelved, it is scheduled to a new host according to the operators policies for distributing work loads across the compute hosts, including taking disabled hosts into account. This will contribute to increased overall capacity, freeing hosts that are ear-marked for maintenance and providing contiguous blocks of resources on single hosts due to moving out old servers.

Shelving a server is not normally a choice that is available to the cloud operator because it affects the availability of the server being provided to the user.

Configure Guest OS

Metadata API

Nova provides a metadata API for servers to retrieve server specific metadata. Neutron ensures this metadata API can be accessed through a predefined IP address, 169.254.169.254. For more details, refer to the user guide <user/metadata.html>.

Config Drive

Nova is able to write metadata to a special configuration drive that attaches to the server when it boots. The server can mount this drive and read files from it to get information that is normally available through the metadata service. For more details, refer to the user guide <user/metadata.html>.

User data

A user data file is a special key in the metadata service that holds a file that cloud-aware applications in the server can access.

This information can be accessed via the metadata API or a config drive. The latter allows the deployed server to consume it by active engines such as cloud-init during its boot process, where network connectivity may not be an option.

Server personality

You can customize the personality of a server by injecting data into its file system. For example, you might want to insert ssh keys, set configuration files, or store data that you want to retrieve from inside the server. This feature provides a minimal amount of launch-time personalization. If you require significant customization, create a custom image.

Follow these guidelines when you inject files:

• The maximum size of the file path data is 255 bytes.
• Encode the file contents as a Base64 string. The maximum size of the file contents is determined by the compute provider and may vary based on the image that is used to create the server.

Considerations:

• The maximum limit refers to the number of bytes in the decoded data and not the number of characters in the encoded data.
• The maximum number of file path/content pairs that you can supply is also determined by the compute provider and is defined by the maxPersonality absolute limit.
• The absolute limit, maxPersonalitySize, is a byte limit that is guaranteed to apply to all images in the deployment. Providers can set additional per-image personality limits.
• The file injection might not occur until after the server is built and booted.
• After file injection, personality files are accessible by only system administrators. For example, on Linux, all files have root and the root group as the owner and group owner, respectively, and allow user and group read access only (octal 440).