Design proposal for supported image formats (v3)

[gthvn1]

Add details on specifying image format for VDI and VM migration. In particular This revision explains how to choose the destination image format during VDI creation and migration, including VM migration scenarios.
Also fixes minor typos in the document.

[gthvn1]

Note: I didn't find how to reopen #6360 so I submitted this one.

[lindig]

Architecturally, the destination format could be a list of formats in order of preference where we currently keep this to one element. But maybe this is overloading this feature and we could do this later as well.

[gthvn1]

I think that we could do it later but I agree that it is a good idea.

[lindig]

If we are talking about lists, sets, and so on: we need to be careful if those exist as a data structure on the API level or are represented as strings somewhere else. For a string representation details matter: is this a space separated or comma separated? The formats by themselves are probably words that must not contain punctuation or spaces.

[gthvn1]

If I understand correctly only the "supported image format" provided by the SM plugin will be stored in the xapi database. And it will be a list of image format like the one find for capabilities
So in DRIVER_INFO you will have a new field supported_image_format with the list of supported image format (that will be a set of strings).

DRIVER_INFO = {
    'name': 'Local EXT3 VHD',
    'description': 'SR plugin which represents disks as VHD files stored on a local EXT3 filesystem, created inside an LVM volume',
    ...
    'supported_image_formats': ['vhd', 'raw']
    }

So yes formats will be words without punctuation or spaces. And I didn't mention it (I should) but it will be case insensitive. "qcow2" is equivalent to "Qcow2".

[psafont]

I think some specifics are still missing, in particular, what are the exact errors that need to be raised and how exactly the VM migration API needs to change.

These can be done in the v4 of the proposal, this is much better than before

[gthvn1]

Agree for the exact error and currently for testing I'm returning "vdi_incompatible_type" but for final upstream version I think a specific error will be better. Will be in v4 :)