A volume is a storage device, similar to a block device in Nova. ESC supports both volumes created by ESC and out-of-band
volumes. Further, ESC also supports bootable volumes created by ESC and out-of-band bootable volumes.
Note |
The maximum number of volumes that can be attached to a VM through the nova boot command is only two.
|
Volumes Created by ESC
To create volume as part of the VM group, the <size> and <sizeunits> parameters must be provided in the volumes section of
the deployment request. The volume type is the default volume type in Cinder.
The following example shows how to create an ESC volume in the deployment request.
<volumes>
<volume>
<name>example</name>
<volid>1</volid>
<bus>ide</bus>
<size>1</size>
<sizeunit>GiB</sizeunit>
</volume>
</volumes>
Note |
If a volume is added post-deployment, the Openstack API does not allow the supplied bus tag to be specified and uses the default defined in the OpenStack instance.
|
Bootable Volumes Created by ESC
A bootable volume is one which is used as a root disk. ESC creates bootable volumes using the image reference name or the
UUID in the deployment request. To boot instances from the volume specify the boot_index , otherwise the instance will only
be an attached volume.
For example,
<volumes>
<volume>
<name>cinder-vol1X</name>
<volid>1</volid>
<image>cirrosX1.75</image>
<bus>ide</bus>
<type>lvm</type>
<size>1</size>
<sizeunit>GiB</sizeunit>
<boot_index>0</boot_index>
</volume>
</volumes>
Out-of-band Volumes
The out-of-band (pre-existing) volume can be specified using the <type> attribute in the deployment request. If the <type>
attribute is provided, ESC matches the volume with the type provided.
ESC differentiates an out-of-band volume and volume created by ESC based on the values set in the volumes section of deployment
request. The volume (only if the volume is created by ESC) associated to a VM is deleted when a service is undeployed or the
VM is scaled down.
Note |
The support for scale in/out when using out of band volumes is no longer available.
|
<volumes>
<volume>
<name>pre-existing</name>
<volid>1</volid>
<bus>ide</bus>
<type>lvm</type>
</volume>
</volumes>
If the <type> attribute is not provided, ESC matches a volume with no type.
ESC matches a volume with the same name. If more than one volume has the same name, ESC will fail the request.
<volumes>
<volume>
<name>pre-existing</name>
<volid>1</volid>
<bus>ide</bus>
</volume>
</volumes>
Out-of-band Bootable Volumes
Out-of-band bootable volume (for OpenStack only) is a variation of out-of-band volume, where the specified volume is used
as a root disk. The VM is booted from that volume, instead of the image. The <boot_index> attribute specifies the out-of-band
bootable volumes in the deployment request.
For example,
<volumes>
<volume>
<name>pre-existing</name>
<volid>0</volid>
<bus>ide</bus>
<type>lvm</type>
<boot_index>0</boot_index>
</volume>
</volumes>
The out of band bootable volume can be with or without <type> attribute, similar to out of band volumes.
Swapping Out-of-band Bootable Volume
To swap the out-of-band bootable volume, the update deployment request must remove the old volume and add new volume with
the same volid and boot_index
values. This will swap the bootable volume in OpenStack. Ensure that the VM must be rebooted following the update.
For example,
<volumes>
<volume nc:operation="delete">
<name>pre-existing</name>
<volid>0</volid>
<bus>ide</bus>
<type>lvm</type>
<boot_index>0</boot_index>
</volume>
<volume>
<name>another-pre-existing</name>
<volid>0</volid>
<bus>ide</bus>
<type>lvm</type>
<boot_index>0</boot_index>
</volume>
</volumes>
Parameter description
-
Name—Specifies the display name of the pre-existing volume.
-
Volid—Specifies the order in which volumes are attached. These are consecutive numbers starting from 0 or 1 for every VM
group.
-
Bus—Specifies the bus type of the volumes to be attached.
-
Type—(Optional) If <type> is specified, then ESC matches the volume with the type provided.
-
size and sizeunits—Defines a volume created by ESC
-
boot_index—(Optional) specifies boot order. Set to 0 to boot from a given volume, similarly to how a VM would be booted from
an image. The "bootable" property for that volume in OpenStack must be set to true for this to work.
Multi-attach Volumes
The ability to attach a volume to multiple hosts/servers simultaneously is a use case desired for active/active or active/standby
scenarios (Openstack only). In order to attach a volume to multiple server instances you need to have the multiattach flag set to True in the volume details. Ensure that you have the right role and policy settings before performing the operation.
To create this special type that includes an extra-spec capability setting of multiattach=<is> True
, use the following commands:
$ cinder type-create multiattach
$ cinder type-key multiattach set multiattach="<is> True"
The type-key name could be anything however, the property it references should be multiattach. This guide will reference the
type as multiattach.
Once this type is created, create an out-of-band volume (bootable or otherwise) in Openstack by specifying the type. For example:
$ cinder create <volume_size> --name <volume_name> --volume-type multiattach
To use this volume, when creating a deployment, treat it the same as an out-of-band volume, except that you may specify the
volume UUID or unique name against more than one VM. ESC only attempts to attach correctly typed volumes to more than one
VM. For example:
<vm_group>
<name>c1</name>
...
<volumes>
<volume>
<name>cf-cdr0-volume</name>
<volid>0</volid>
</volume>
</volumes>
...
</vm_group>
<vm_group>
<name>c2</name>
...
<volumes>
<volume>
<name>cf-cdr0-volume</name>
<volid>0</volid>
</volume>
</volumes>
...
</vm_group>
The multiattach volume can be detached like a regular out-of-band volume and also be used to replace a regular out-of-band
volume on a VM by using a service update. This action requires a reboot of the VM to recognize the newly attached volume (multiattach
or otherwise).
Note |
Openstack Requirements
-
The minimum required compute API micro-version for attaching a multiattach-capable volume to more than one server is 2.60.
-
Cinder 12.0.0 (Queens) or latest is required (microversion ‘3.50’ or higher).
-
The nova-compute service must be running at least Queens release level code (17.0.0) and the hypervisor driver must support
attaching block storage devices to more than one guest. Refer to the feature support matrix for details on which compute drivers
support volume multiattach.
-
While using the libvirt compute driver, the following native package versions determine multiattach support:
-
Libvirt must be greater than or equal to 3.10
-
Qemu must be less than 2.10.
-
Swapping an in-use multiattach volume is not supported (this is actually controlled via the block storage volume retype API).
|
Tenant-Volume API
The tenant-volume API allows you to create and delete volumes outside a deployment request. The tenant-volume API creates
the volume directly under the tenant. You must provide the tenant details to create a volume.
A sample tenant-volume NETCONF API request is as follows:
<esc_datamodel xmlns="http://www.cisco.com/esc/esc">
<tenants>
<tenant>
<name>admin</name>
<volumes>
<volume>
<name>some-volume</name>
<type>lvm</type>
<size>1</size>
<sizeunit>GiB</sizeunit>
</volume>
</volumes>
</tenant>
</tenants>
</esc_datamodel>
You can also use the tenant-volume API to create a volume using an existing tenant. For this, the volume name must be unique
for that tenant.
Note |
-
The tenant-volume API is supported by both NETCONF and REST APIs.
-
You cannot use the tenant-volume API to create or delete ephemeral or out-of-band volumes.
-
The volumes that are managed by ESC only can be deleted.
-
You cannot update an existing volume using the tenant-volume API.
|
Deploying with the Volumes Created by the Tenant-Volume API
ESC treats a volume created by the tenant-volume API as an out-of-band volume. To deploy a volume created by the tenant-volume
API, you must provide the <size> and <sizeunit> parameters in the deployment data model. When the <size> and <sizeunit> parameters
are not available, ESC looks for the volume created by the tenant-volume API. If this does not exist, then ESC looks for other
out-of-band volumes created by other ESCs or other users. If out-of-band volumes are not available, then the deployment request
is rejected.
A sample deployment request with a volume created using the tenant-volume API is as follows:
<?xml version="1.0" encoding="UTF-8"?>
<esc_datamodel xmlns:ns2="urn:ietf:params:xml:ns:netconf:notification:1.0" xmlns:ns1="urn:ietf:params:xml:ns:netconf:base:1.0" xmlns:ns3="http://www.cisco.com/esc/esc_notifications" xmlns:ns0="http://www.cisco.com/esc/esc" xmlns="http://www.cisco.com/esc/esc">
<tenants>
<tenant>
<name>admin</name>
<deployments>
<deployment>
<name>admin-with-volume</name>
<vm_group>
<name>cirros</name>
<bootup_time>60</bootup_time>
<recovery_wait_time>0</recovery_wait_time>
<image>Automation-Cirros-Image</image>
<flavor>Automation-Cirros-Flavor</flavor>
<volumes>
<volume>
<name>some-volume</name>
<volid>1</volid>
<bus>ide</bus>
</volume>
</volumes>
<interfaces>
<interface>
<nicid>0</nicid>
<network>mynetwork</network>
</interface>
</interfaces>
<scaling>
<min_active>1</min_active>
<max_active>1</max_active>
<elastic>true</elastic>
</scaling>
<kpi_data>
<kpi>
<event_name>VM_ALIVE</event_name>
<metric_value>1</metric_value>
<metric_cond>GT</metric_cond>
<metric_type>UINT32</metric_type>
<metric_collector>
<type>ICMPPing</type>
<nicid>0</nicid>
<poll_frequency>3</poll_frequency>
<polling_unit>seconds</polling_unit>
<continuous_alarm>false</continuous_alarm>
</metric_collector>
</kpi>
</kpi_data>
<rules>
<admin_rules>
<rule>
<event_name>VM_ALIVE</event_name>
<action>"ALWAYS log"</action>
<action>"TRUE
servicebooted.sh"</action>
<action>"FALSE recover
autohealing"</action>
</rule>
</admin_rules>
</rules>
<config_data />
</vm_group>
</deployment>
</deployments>
</tenant>
</tenants>
</esc_datamodel>
If you provide the <size> and <sizeunit> parameters of a volume, then ESC creates a new volume using these values as part
of the deployment. The new volume is treated as an ephemeral volume.
Note |
For ephemeral volumes, the minimum and maximum scaling value can be more than 1, but for tenants and out-of-band volumes the
value can be 1 only.
|