osc compute server create21

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 create21 [OPTIONS] --flavor-ref <FLAVOR_REF> --name <NAME>

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

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

  • --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

  • --networks <JSON> — A list of network object. Required parameter when there are multiple networks defined for the tenant. When you do not specify the networks parameter, the server attaches to the only network created for the current tenant. Optionally, you can create one or more NICs on the server. To provision the server instance with a NIC for a network, specify the UUID of the network in the uuid attribute in a networks object. To provision the server instance with a NIC for an already existing port, specify the port-id in the port attribute in a networks object.

    If multiple networks are defined, the order in which they appear in the guest operating system will not necessarily reflect the order in which they are given in the server boot request. Guests should therefore not depend on device order to deduce any information about their network devices. Instead, device role tags should be used: introduced in 2.32, broken in 2.37, and re-introduced and fixed in 2.42, the tag is an optional, string attribute that can be used to assign a tag to a virtual network interface. This tag is then exposed to the guest in the metadata API and the config drive and is associated to hardware metadata for that network interface, such as bus (ex: PCI), bus address (ex: 0000:00:02.0), and MAC address.

    A bug has caused the tag attribute to no longer be accepted starting with version 2.37. Therefore, network interfaces could only be tagged in versions 2.32 to 2.36 inclusively. Version 2.42 has restored the tag attribute.

    Starting with microversion 2.37, this field is required and the special string values auto and none can be specified for networks. auto tells the Compute service to use a network that is available to the project, if one exists. If one does not exist, the Compute service will attempt to automatically allocate a network for the project (if possible). none tells the Compute service to not allocate a network for the instance. The auto and none values cannot be used with any other network values, including other network uuids, ports, fixed IPs or device tags. These are requested as strings for the networks value, not in a list. See the associated example.

  • --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

  • --personality <JSON> — The file path and contents, text only, to inject into the server at launch. The maximum size of the file path data is 255 bytes. The maximum limit is the number of allowed bytes in the decoded, rather than encoded, data.

    Available until version 2.56

  • --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

  • --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.