Design proposal for supported image formats (v3) #6360
Conversation
| storage, we need a way to specify which format should be used. To achieve this, | ||
| we propose adding a preferred image format for a given SR. When the SR is created, | ||
| based on the list retrieved using `supported_image_formats` from the SM, we can | ||
| pass `preferred-image-format=qcow2` to the `sm_config` parameter of the SR. If no |
There was a problem hiding this comment.
This is a very roundabout way of selecting the type, and if there's migrations happening at the same time, a format for each of them doesn't seem possible.
Why can 't the VDI migration have an additional parameter selecting the type?
Also, which drivers gets to pick the format, the one that's exportting, the one that's importing, both?
There was a problem hiding this comment.
In fact it is a simple way to specify a format without modifying the API but I completely agree on both points.
- With this modification all migrations will have the same format and
- it would be better to be able to choose the destination format per VDI.
And if the user doesn't make a choice the driver that manages the destination SR makes the choice.
I will add a proposition for a new parameter for VDI pool migrate. But about VM migrate? Because the user migrate a VM that has a VDI that is not on shared storage it will call the VDI pool migrate no? As I'm not sure here what to do that's why I proposed as first approach to fix the destination format using the preferred-image-format=qcow2.
gthvn1
force-pushed
the
feature/supported-image-formats-v3
branch
from
1c0c7c8 to
abee315
Compare
| be used (e.g., due to size limitations), an error will be generated. | ||
| If a driver does not provide this information (as is currently the case with | ||
| existing drivers), the default value will be an empty array. This signifies that | ||
| the driver determines which format to use when creating or migrating a VDI. |
There was a problem hiding this comment.
On migration, which of the sides decides what format to use? The receiving end? Or is there a negotiation between both sides needed?
There was a problem hiding this comment.
As I see it, if no extra information is provided, it is up to the receiving end to decide the default format. Since the supported formats are not exposed, the client cannot make any assumptions. Therefore, only the receiving side can determine its default format, and there is no negotiation between both sides.
There was a problem hiding this comment.
The other solution is to check in XAPI that the same format is available for both side and if it is the case keep the same format. Otherwise we use the destination format. It is not clear yet how to check that in XAPI so that's why using the default format of the destination is maybe easier as a first approach...
There was a problem hiding this comment.
Can the fact that it's the receiving side that decides be written here?
There was a problem hiding this comment.
Yes sure. I'm not sure which solution is better. So I'm waiting for other opinions if any and will update the PR accordingly 👍
| a string. The string specifies a preferred format (e.g., qcow2), ensuring that the | ||
| VDI is migrated in the correct format. If the chosen or default format cannot be | ||
| used (e.g., due to size limitations), an error will be generated. |
There was a problem hiding this comment.
Can this error be calculated before the mgiration happens, and not when the limit is reached? I'd like to have the time the check is done written down in the design
There was a problem hiding this comment.
Ok sure. I will check that.
gthvn1
force-pushed
the
feature/supported-image-formats-v3
branch
2 times, most recently
from
e3bf586 to
d237624
Compare
|
Closed by mistake. |
In this version we added explanation about how to choose the format when the VDI is created but also the destination format during migration. We also fix some typos. Signed-off-by: Guillaume <[email protected]>
gthvn1
force-pushed
the
feature/supported-image-formats-v3
branch
from
d237624 to
c81e182
Compare
In the previous version of the design some questions were always raised. In this version we added explanations about how to choose the format when the VDI is created but also the destination format during migration.
We no longer rely on the order of the parameters passed by the driver because it is not guaranteed. Instead we propose to use some existing parameters to choose the format of the VDI when it is created and the format that should be used during migration. If no parameters are specified it will be up to the driver to do what he wants.