Description of problem: Creating a new disk is too complicated and require knowledge of storage domain internal implementation. This harms application using ovirt API, resulting in bad defaults and disabling certain configurations which are not supported in all storage domains. When creating a new disk we have to specify: disk = disks_service.add( disk=types.Disk( format=?, sparse=?, backup=?, storage_domains=[ types.StorageDomain( name=args.sd_name ) ] ... ) ) These are the allowed combinations: File storage domain: - format="raw", sparse=True - format="raw", sparse=False - format="cow", sparse=True - format="cow", sparse=True - format="cow", sparse=False, backup="incremental" Block storage domains: - format="raw", sparse=False - format="cow", sparse=True - format="cow", sparse=True - format="cow", sparse=False, backup="incremental" Since we don't expose if storage domain is file or block based, programs using this API cannot select valid combinations. The results is using bad default to works in all cases (e.g. raw preallocated), or letting the user select the combination. We need a new API reporting: - available combinations of format, sparse and backup - recommended configuration (the default used in the UI) This API should be used by the UI when creating or uploading disks to display available options. Programs using the API will be able to use it to select good defaults or show the user useful help message. The information can be displayed in: GET /ovirt-enigne/api/storagedomains/sd-id Programs affected that needs this: - virt-v2v - IMS - ovirt-engine-sdk uploda_disk.py example - backup application, for restoring VMs
Richard, can you add more info on how this affects virt-v2v?
Fabian, can you add more info on how this affects IMS?
This affects IMS because we store a static mapping of storage domain types vs. supported/recommended disk format. It would be better if we could request the information from the API and align with what RHV recommends. We could even imagine that a storage policy forbids a normally supported disk format and the migrations will fail.
Sorry for the delay, I somehow missed this. What you're proposing makes perfect sense to me. For virt-v2v, you can see the problems were having here: https://github.com/libguestfs/virt-v2v/blob/dbaf85f0b147400c815ae52bd901befed45c9d9e/v2v/rhv-upload-plugin.py#L469 disk = disks_service.add( disk=types.Disk( # The ID is optional. id=params.get('rhv_disk_uuid'), name=params['disk_name'], description="Uploaded by virt-v2v", format=disk_format, # XXX For qcow2 disk on block storage, we should use the estimated # size, based on qemu-img measure of the overlay. initial_size=params['disk_size'], provisioned_size=params['disk_size'], # XXX Ignores params['output_sparse']. # Handling this properly will be complex, see: # https://www.redhat.com/archives/libguestfs/2018-March/msg00177.html sparse=True, storage_domains=[ types.StorageDomain( name=params['output_storage'], Since virt-v2v isn't interactive we would choose the recommended default.
This request is not currently committed to 4.4.z, moving it to 4.5
This bug/RFE is more than a year old and it didn't get enough attention so far, and is now flagged as pending close. Please review if it is still relevant and provide additional details/justification/patches if you believe it should get more attention for the next oVirt release.
Yes this affects virt-v2v all the time.
We do not plan to work on exposing the combinations in API. We're leaning towards rather implementing automatic selection of valid/default combination based on target storage domain.
We are past 4.5.0 feature freeze, please re-target.
I think that once we have the disk conversion feature (in RHV 4.4 SP1) it becomes less important to pick the "best" (or the most useful) combination because the user can change it afterwards, if needed If I understand comment 4 correctly, then the disk format is configurable and sparse is always true So can we do something really simple on the virt-v2v side - like setting sparse=false for RAW and sparse=true, initial-size=measured-size for QCOW?
Benny raised another point - virt-v2v can be configured with a parameter for incremental backup and if that one is set then set the arguments accordingly (it's the same on block and file storage)
(In reply to Arik from comment #13) > So can we do something really simple on the virt-v2v side - like setting > sparse=false for RAW and sparse=true, initial-size=measured-size for QCOW? It's possible, although it would mean ignoring the user's preference expressed through the -oa sparse|preallocated option (which we do right now, but this bug is about how to fix that). Anyway the code is here and patches are welcome: https://github.com/libguestfs/virt-v2v/blob/8643970f9791b1c90dfd6a2dd1abfc9afef1fb52/output/rhv-upload-transfer.py#L90
I agree that adding backup=incremental as default when creating the disk will solve the issue. This will always create qcow2 images on any kind of storage. Users can still use sparse or preallocated to control the allocation policy regardless of the image format. The disks can be included in incremental backup without any conversion step (requires downtime).
Unfortunately this request was not prioritized and didn't make it into the latest major version of oVirt 4.5 and there is no activity on this request for a while. Closing.