This Epic is created based on the RFE bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2240544

Problem description

For image booted VMs nova already creates a snapshot during shelve offload operation.

With the createImage instance action on a volume booted VM nova creates volume snapshots and an empty image snapshot with metadata pointing to the volume snapshots.

There is a use case to create a snapshot of the VM during or after the shelve offload operation for volume booted VMs:
The customer wants to duplicate a shelve offloaded volume booted VM by using a snapshot image from glance to boot a new VM. However only image booted VMs are snapshotted when offloaded and offloaded VMs cannot be snapshotted.

Proposed solution:

In a new API microversion allow creating a snapshot of a volume booted VM in shelve offloaded state.
This requires a new cinder API microversion to allow volume snapshot for a volume in reserved state.

Alternatives:

Automatically create a snapshot of a volume booted VM during shelve offloading. However the original customer request has additional requirement about defining which VM needs snapshot during offload and also when to delete such snapshot. Solving all these requests is easier via allowing snaphost in SHELVED_OFFLOADED state.
Also volume booted VM snapshot is handled by the nova-api (with optional quiesce on the compute) while image based snapshot during shelving is done fully on the compute side using the virt driver's snapshot() functionality. So the technical solution of this alternative would also be more complicated.

Technical solution:

Cinder:

In a new microversion the API

POST /v3/{project_id}/snapshots

will allow creating a volume snapshot for a volume in reserved state.
NOTE: the force flag is already deprecated in the API so we don't need to differentiate between a force and a normal snapshot.

Nova:

The createImage instance action behaves differently for image booted and volume booted VMs.
The nova API documentation states:

In the image-backed server case, volume snapshots of attached volumes will not be created. In the volume-backed server case, volume snapshots will be created for all volumes attached to the server and then those will be represented with a block_device_mapping image property in the resulting snapshot image in the Image service. If that snapshot image is used later to create a new server, it will result in a volume-backed server where the root volume is created from the snapshot of the original root volume. The volumes created from the snapshots of the original other volumes will be attached to the server.

In a new microversion API

POST /servers/{server_id}/action
createImage Action

will be accepted even if the VM is in SHELVED_OFFLOADED.

For image booted VMs nova already creates an image snapshot during shelve offloading. Nova will create duplicated snapshots for subsequent createImage request when the VM is in SHELVED_OFFLOADED state.

For volume booted VMs nova does not create volume snapshots during shelve offloading, just creates a glance image referring to the original volumes. This will not change. But any subsequent createImage request, while the VM is in SHELVED_OFFLOADED state, will result in a volume snapshot and a glance image pointing to that snapshot.

Note that quiescening if requested can be ignored for VMs in SHELVE_OFFLOADED state as the guest is not running.

Also a new all_volumes boolean field will be added to the createImage request payload defaulted to False.

• When all_volumes is true then nova will create a volume snapshot of each attached volume. This is the legacy behavior for the volume booted VMs.
• When all_volumes is false then nova will not create a volume snapshot of each attached volume. This is the legacy behavior for image booted VMs.