Supported image formats #6712
Supported image formats #6712
Conversation
When running `xe sm-list params=all` you will now have the info of supported image formats if the SM plugin specified it in its DRIVER_INFO. The field is called `supported-image-formats`. If the plugin doesn't provide the info the field will be empty. This patch modifies the datamodel and add a new field to store this information into the SM object. Signed-off-by: Guillaume <[email protected]>
This patch allows specifying the destination format for individual VDIs mapped to a destination SR. It adds a new parameter to `VM.migrate_send` and `VM.assert_can_migrate` API. It also adds a new parameter to XE CLI. The format to specify the image format is `image-format:<source VDI UUID>=<destination image format>`. If the given image format cannot be validated, an error is returned. It also adds a new parameter to `VDI.pool-migrate`. This new parameter allows to provide a string that is the destination format. This string is used to check whether the destination SR supports the expected format. If the check fails or cannot be performed due to missing information on the destination SR, an error is returned. Signed-off-by: Guillaume <[email protected]>
A new field supported_image_format and new parameters have been added for: - VM.migrate_send - VM.assert_can_migrate - VDI.pool_migrate Signed-off-by: Guillaume <[email protected]>
| ?(host_pending_features = []) ?(configuration = []) ?(other_config = []) | ||
| ?(driver_filename = "/dev/null") ?(required_cluster_stack = []) () = | ||
| ?(driver_filename = "/dev/null") ?(required_cluster_stack = []) | ||
| ?(supported_image_formats = []) () = |
There was a problem hiding this comment.
Is this a sensible default? Does this not force to set this parameter? Or is the empty list a special value?
There was a problem hiding this comment.
Yes empty list is a special value because current SM plugins don't provide any information. So in this case, the list is empty and the behavior remains as it is today. We will attempt the migration, and it is up to the SM plugin to check whether it can perform the migration and raise an exception if something goes wrong. So empty list is the value with existing SM plugins.
|
I would like to see more explicitly documented and checked the supported image formats. These appear to be some mysterious strings but the user of neither API or CLI should have to guess them, |
Yes, in my mind the user should first check using |
ocaml/idl/datamodel_vm.ml
Outdated
| param_type= Map (Ref _vdi, String) | ||
| ; param_name= "vdi_format_map" | ||
| ; param_doc= "Map of source VDI to it's expected type on destination" | ||
| ; param_release= numbered_release "25.24.0-next" |
There was a problem hiding this comment.
This needs to be bumped before integrating with master
ocaml/idl/datamodel_vm.ml
Outdated
| param_type= Map (Ref _vdi, String) | ||
| ; param_name= "vdi_format_map" | ||
| ; param_doc= "Map of source VDI to it's expected type on destination" | ||
| ; param_release= numbered_release "25.24.0-next" |
There was a problem hiding this comment.
This needs to be bumped before integrating with master
gthvn1
force-pushed
the
gtn-image-formats
branch
from
63a9fe1 to
173e37b
Compare
3 participants
This PR implements the supported image format mechanism proposed in this design document: https://xapi-project.github.io/new-docs/design/sm-supported-image-formats/index.html
DRIVER_INFO.This feature is particularly useful because XCP-ng is adding support for the Qcow2 format in SMAPI to allow VDIs larger than 2TB. So in the near future (we're currently releasing the beta version), some SRs will support multiple formats such as VHD, RAW, and Qcow2.
With this patch, it becomes possible to migrate a VM with VHD disks on one SR to another SR with Qcow2 disks. If an SM plugin does not provide information about the supported image formats, the behavior remains unchanged.
For more details see the specification.