Design proposal for supported image formats (v3) #6360
Conversation
gthvn1
force-pushed
the
feature/supported-image-formats-v3
branch
from
1c0c7c8 to
abee315
Compare
| 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.
There was a problem hiding this comment.
Still need to check that ;). I will do it today I think.
gthvn1
force-pushed
the
feature/supported-image-formats-v3
branch
2 times, most recently
from
e3bf586 to
d237624
Compare
|
Closed by mistake. |
gthvn1
force-pushed
the
feature/supported-image-formats-v3
branch
from
d237624 to
c81e182
Compare
| the destination driver will choose the format of the VDI if none is explicitly | ||
| specified. This ensures backward compatibility with both current and future drivers. |
There was a problem hiding this comment.
Doesn't this mean that the origin needs to be able to produce that format? It may mean a new error message needs to be added.
There was a problem hiding this comment.
Oh yes. In fact it looks like the same issue than the one above when format is not supported. Even if we provide a tip with supported image format a client could ask for another one that is not supported. So in all cases we need to detect as early as possible that a format requested by the client is not supported. If supported image format is provided by the SM Driver we can easily check the list but if it is not provided I'm not sure how to detect the error early. Interesting.
There was a problem hiding this comment.
I think that we can probably add checks of the size and of the format supported by destination in the migration_send'. If the information of supported image format is in the database. If the information is not provided I think that the error will be detected during the creation of the mirror+snapshot, so later unfortunately.
There was a problem hiding this comment.
So as I understand it it should be ok to check in migrate_receive or migrate_send' if the supported_image_format passed as an option is valid for the SR because we can from the VDI_ref found its SR and if I'm not mistaken the SR type has a corresponding SM type. And then SM type will have it supported image format list (or empty if not provided). So I think that we can make the check at the same time as we are doing the assert_can_migrate_vdis. If it is ok I will add this information in the specification.
While I'm looking at this it makes me think that also when doing the VM migration we will need to allow to choose the format of the VDI. Because for VM live migration we can pass VDI mappings we need to specify the format as well.
So for VM migration one idea is to add an option to the mapping like vdi:<source vdi uuid>=<dest sr uuid>,vhd or vdi:<source vdi uuid>=<dest sr uuid>,qcow2 and of course you can still use vdi:<source vdi uuid>=<dest sr uuid>.
Or we can add a separate option to specify for a given VDI (selected by its source) what format should be used when moving it. Something like vdi_format:<source vdi uuid>=vhd.
Finally there are more cases than I thought :)
There was a problem hiding this comment.
If it is ok I will add this information in the specification.
Yeah, go ahead
I'd prefer the separate option for the migration, if possible
gthvn1
force-pushed
the
feature/supported-image-formats-v3
branch
3 times, most recently
from
3ec5291 to
4bf6d5c
Compare
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
4bf6d5c to
322f4bc
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.