Description of problem: When creating a raw disk via API on block storage domain if you don't specify sparse it defaults to true which is not valid. sparse attribute is not listed as mandatory attribute in apidoc Version-Release number of selected component (if applicable): Tested on RHEV3.6 and RHV4 How reproducible: always Steps to Reproduce: Sample curl # curl \ > --cacert '/etc/pki/ovirt-engine/ca.pem' \ > --user 'admin@internal:<password>' \ > --request POST \ > --header 'Version: 4' \ > --header 'Content-Type: application/xml' \ > --header 'Accept: application/xml' \ > --data ' > <disk> > <storage_domains> > <storage_domain id="4661b3b4-43be-42b9-855e-56ddd72bf564"/> > </storage_domains> > <name>testdisk</name> > <provisioned_size>1000</provisioned_size> > <format>raw</format> > </disk> > ' \ > https://<engine>/ovirt-engine/api/disks Actual results: <?xml version="1.0" encoding="UTF-8" standalone="yes"?> <fault> <detail>[Cannot add Virtual Disk. Disk configuration (RAW Sparse) is incompatible with the storage domain type.]</detail> <reason>Operation Failed</reason> </fault> Expected results: not default to sparse true and create disk Additional info: This can be worked around very easily by adding sparse = false in call to api, however as noted sparse is not a mandatory attribute. Either a change in api behaviour is needed or change to apidoc to not that sparse is mandatory attribute in this scenario
This default comes from the DiskImage's consturctor. At the point it's constructed, we don't have enough info (i.e. - don't have the storage type available) to make any smarter decision. We could, of course, change the default regardless of the storage type, but that sounds like a bigger interference with the customers' working script. Juan - can we get your two cents on this? [Tentatively targeting to 4.1.3 to express our willingness to help the customer in case we find a reasonable solution, but in all fairness I'm inclined to close as WONTFIX based on the above]
I'd say that if sparse=true doesn't make sense for that combination of disk format and storage domain type, we could just ignore it, instead of generating an error. If that is well documented in the specification of the API I don't see it as big problem. If we finally decide to not fix this, for whatever the reason, we should anyhow document clearly in the API this limitation, including an example: ---8<--- When creating a `raw` disk in a block storage domain (iSCSI or fibre channel) it is mandatory to specify the also that the disk will not be sparse: .... POST /ovirt-engine/api/disks .... [source,xml] ---- <disk> <storage_domains> <storage_domain id="456"/> </storage_domains> <name>testdisk</name> <provisioned_size>1000</provisioned_size> <format>raw</format> <sparse>false</sparse> </disk> ---- --->8--- This should go in the two locations where disks can be created: the top level disks collection, and the VM disk attachments collection. Also, in the description of the Disk.sparse attribute we should also add a note explaining that it is mandatory in this case, and that it must be 'false'.
INFO: Bug status wasn't changed from MODIFIED to ON_QA due to the following reason: [No relevant external trackers attached] For more info please contact: rhv-devops
Tested, and a note regarding sparse attribute has been added to the documentation: https://<your-engine>/ovirt-engine/apidoc/#/services/disks/methods/add
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHEA-2018:1488
BZ<2>Jira Resync