osc block-storage volume create347

Creates a new volume.

| param req: | the request | | --- | --- | | param body: | the request body | | returns: | dict -- the new volume dictionary | | raises HTTPNotFound, HTTPBadRequest: | | | | |

Usage: osc block-storage volume create347 [OPTIONS]

Options:

  • --os-sch-hnt-scheduler-hints <key=value> — The dictionary of data to send to the scheduler

  • --availability-zone <AVAILABILITY_ZONE> — The name of the availability zone

  • --backup-id <BACKUP_ID> — The UUID of the backup.

    New in version 3.47

  • --consistencygroup-id <CONSISTENCYGROUP_ID> — The UUID of the consistency group

  • --description <DESCRIPTION> — The volume description

  • --display-description <DISPLAY_DESCRIPTION>

  • --display-name <DISPLAY_NAME>

  • --group-id <GROUP_ID>

  • --image-id <IMAGE_ID>

  • --image-ref <IMAGE_REF> — The UUID of the image from which you want to create the volume. Required to create a bootable volume

  • --metadata <key=value> — One or more metadata key and value pairs to be associated with the new volume

  • --multiattach <MULTIATTACH>

    Possible values: true, false

  • --name <NAME> — The volume name

  • --size <SIZE> — The size of the volume, in gibibytes (GiB)

  • --snapshot-id <SNAPSHOT_ID> — The UUID of the consistency group

  • --source-volid <SOURCE_VOLID> — The UUID of the consistency group

  • --volume-type <VOLUME_TYPE> — The volume type (either name or ID). To create an environment with multiple-storage back ends, you must specify a volume type. Block Storage volume back ends are spawned as children to cinder- volume, and they are keyed from a unique queue. They are named cinder- volume.HOST.BACKEND. For example, cinder- volume.ubuntu.lvmdriver. When a volume is created, the scheduler chooses an appropriate back end to handle the request based on the volume type. Default is None. For information about how to use volume types to create multiple- storage back ends, see Configure multiple-storage back ends