osc compute server create294

Creates a server.

The progress of this operation depends on the location of the requested image, network I/O, host load, selected flavor, and other factors.

To check the progress of the request, make a GET /servers/{id} request. This call returns a progress attribute, which is a percentage value from 0 to 100.

The Location header returns the full URL to the newly created server and is available as a self and bookmark link in the server representation.

When you create a server, the response shows only the server ID, its links, and the admin password. You can get additional attributes through subsequent GET requests on the server.

Include the block_device_mapping_v2 parameter in the create request body to boot a server from a volume.

Include the key_name parameter in the create request body to add a keypair to the server when you create it. To create a keypair, make a create keypair request.

Preconditions

Asynchronous postconditions

Troubleshooting

Normal response codes: 202

Error response codes: badRequest(400), unauthorized(401), forbidden(403), itemNotFound(404), conflict(409)

Usage: osc compute server create294 [OPTIONS] --flavor-ref <FLAVOR_REF> --name <NAME> <--auto-networks|--networks <JSON>|--none-networks>

Options:

  • --build-near-host-ip <BUILD_NEAR_HOST_IP> — Schedule the server on a host in the network specified with this parameter and a cidr (os:scheduler_hints.cidr). It is available when SimpleCIDRAffinityFilter is available on cloud side

  • --cidr <CIDR> — Schedule the server on a host in the network specified with an IP address (os:scheduler_hints:build_near_host_ip) and this parameter. If os:scheduler_hints:build_near_host_ip is specified and this parameter is omitted, /24 is used. It is available when SimpleCIDRAffinityFilter is available on cloud side

  • --different-cell <DIFFERENT_CELL> — A list of cell routes or a cell route (string). Schedule the server in a cell that is not specified. It is available when DifferentCellFilter is available on cloud side that is cell v1 environment

  • --different-host <DIFFERENT_HOST> — A list of server UUIDs or a server UUID. Schedule the server on a different host from a set of servers. It is available when DifferentHostFilter is available on cloud side

  • --group <GROUP> — The server group UUID. Schedule the server according to a policy of the server group (anti-affinity, affinity, soft-anti-affinity or soft-affinity). It is available when ServerGroupAffinityFilter, ServerGroupAntiAffinityFilter, ServerGroupSoftAntiAffinityWeigher, ServerGroupSoftAffinityWeigher are available on cloud side

  • --query <JSON> — Schedule the server by using a custom filter in JSON format. For example:

    It is available when JsonFilter is available on cloud side.

  • --same-host <SAME_HOST> — A list of server UUIDs or a server UUID. Schedule the server on the same host as another server in a set of servers. It is available when SameHostFilter is available on cloud side

  • --target-cell <TARGET_CELL> — A target cell name. Schedule the server in a host in the cell specified. It is available when TargetCellFilter is available on cloud side that is cell v1 environment

  • --access-ipv4 <ACCESS_IPV4> — IPv4 address that should be used to access this server

  • --access-ipv6 <ACCESS_IPV6> — IPv6 address that should be used to access this server

  • --admin-pass <ADMIN_PASS> — The administrative password of the server. If you omit this parameter, the operation generates a new password

  • --availability-zone <AVAILABILITY_ZONE> — A target cell name. Schedule the server in a host in the cell specified. It is available when TargetCellFilter is available on cloud side that is cell v1 environment

  • --block-device-mapping <JSON>

  • --block-device-mapping-v2 <JSON> — Enables fine grained control of the block device mapping for an instance. This is typically used for booting servers from volumes. An example format would look as follows:

    text > "block_device_mapping_v2": [{ > "boot_index": "0", > "uuid": "ac408821-c95a-448f-9292-73986c790911", > "source_type": "image", > "volume_size": "25", > "destination_type": "volume", > "delete_on_termination": true, > "tag": "disk1", > "disk_bus": "scsi"}] > >

    In microversion 2.32, tag is an optional string attribute that can be used to assign a tag to the block device. This tag is then exposed to the guest in the metadata API and the config drive and is associated to hardware metadata for that block device, such as bus (ex: SCSI), bus address (ex: 1:0:2:0), and serial.

    A bug has caused the tag attribute to no longer be accepted starting with version 2.33. It has been restored in version 2.42.

  • --config-drive <CONFIG_DRIVE> — Indicates whether a config drive enables metadata injection. The config_drive setting provides information about a drive that the instance can mount at boot time. The instance reads files from the drive to get information that is normally available through the metadata service. This metadata is different from the user data. Not all cloud providers enable the config_drive. Read more in the OpenStack End User Guide

    Possible values: true, false

  • --description <DESCRIPTION> — A free form description of the server. Limited to 255 characters in length. Before microversion 2.19 this was set to the server name.

    New in version 2.19

  • --flavor-ref <FLAVOR_REF> — The flavor reference, as an ID (including a UUID) or full URL, for the flavor for your server instance

  • --host <HOST> — The hostname of the hypervisor on which the server is to be created. The API will return 400 if no hypervisors are found with the given hostname. By default, it can be specified by administrators only.

    New in version 2.74

  • --hostname <HOSTNAME> — The hostname to configure for the instance in the metadata service.

    Starting with microversion 2.94, this can be a Fully Qualified Domain Name (FQDN) of up to 255 characters in length.

    Note

    This information is published via the metadata service and requires application such as cloud-init to propagate it through to the instance.

    New in version 2.90

  • --hypervisor-hostname <HYPERVISOR_HOSTNAME> — The hostname of the hypervisor on which the server is to be created. The API will return 400 if no hypervisors are found with the given hostname. By default, it can be specified by administrators only.

    New in version 2.74

  • --image-ref <IMAGE_REF> — The UUID of the image to use for your server instance. This is not required in case of boot from volume. In all other cases it is required and must be a valid UUID otherwise API will return 400

  • --key-name <KEY_NAME> — A target cell name. Schedule the server in a host in the cell specified. It is available when TargetCellFilter is available on cloud side that is cell v1 environment

  • --max-count <MAX_COUNT>

  • --metadata <key=value> — Metadata key and value pairs. The maximum size of the metadata key and value is 255 bytes each

  • --min-count <MIN_COUNT>

  • --name <NAME> — A target cell name. Schedule the server in a host in the cell specified. It is available when TargetCellFilter is available on cloud side that is cell v1 environment

  • --auto-networks

  • --networks <JSON>

  • --none-networks

  • --os-dcf-disk-config <OS_DCF_DISK_CONFIG> — Controls how the API partitions the disk when you create, rebuild, or resize servers. A server inherits the OS-DCF:diskConfig value from the image from which it was created, and an image inherits the OS-DCF:diskConfig value from the server from which it was created. To override the inherited setting, you can include this attribute in the request body of a server create, rebuild, or resize request. If the OS-DCF:diskConfig value for an image is MANUAL, you cannot create a server from that image and set its OS-DCF:diskConfig value to AUTO. A valid value is:

    • AUTO. The API builds the server with a single partition the size of the target flavor disk. The API automatically adjusts the file system to fit the entire partition. - MANUAL. The API builds the server by using whatever partition scheme and file system is in the source image. If the target flavor disk is larger, the API does not partition the remaining disk space.

    Possible values: auto, manual

  • --return-reservation-id <RETURN_RESERVATION_ID> — Indicates whether a config drive enables metadata injection. The config_drive setting provides information about a drive that the instance can mount at boot time. The instance reads files from the drive to get information that is normally available through the metadata service. This metadata is different from the user data. Not all cloud providers enable the config_drive. Read more in the OpenStack End User Guide

    Possible values: true, false

  • --security-groups <SECURITY_GROUPS> — One or more security groups. Specify the name of the security group in the name attribute. If you omit this attribute, the API creates the server in the default security group. Requested security groups are not applied to pre-existing ports

  • --tags <TAGS> — A list of tags. Tags have the following restrictions:

    • Tag is a Unicode bytestring no longer than 60 characters. - Tag is a non-empty string. - ‘/’ is not allowed to be in a tag name - Comma is not allowed to be in a tag name in order to simplify requests that specify lists of tags - All other characters are allowed to be in a tag name - Each server can have up to 50 tags.

    New in version 2.52

  • --trusted-image-certificates <TRUSTED_IMAGE_CERTIFICATES> — A list of trusted certificate IDs, which are used during image signature verification to verify the signing certificate. The list is restricted to a maximum of 50 IDs. This parameter is optional in server create requests if allowed by policy, and is not supported for volume-backed instances.

    New in version 2.63

  • --user-data <USER_DATA> — Configuration information or scripts to use upon launch. Must be Base64 encoded. Restricted to 65535 bytes.

    Note

    The null value allowed in Nova legacy v2 API, but due to the strict input validation, it isn’t allowed in Nova v2.1 API.