Description of problem: When an OVF file under it's DiskSection defines any disk without the ovf:capacityAllocationUnits, import will fail with Unexpected ovf:capacityAllocationUnits: at /usr/share/perl5/vendor_perl/Sys/VirtConvert/Connection/VMwareOVASource.pm line 345. However, according to spec, the default is bytes and the property is optional. Version-Release number of selected component (if applicable): Fedora 20 / virt-v2v 0.9.0 How reproducible: Import an OVA/OVF with a DiskSection and a Disk in it without the ovf:capacityAllocationUnits but with the ovf:capacity property Actual results: Import fails. Expected results: Import succeeds with ovf:capacity interpreted as bytes Additional info: The OVF standard (http://www.dmtf.org/sites/default/files/standards/documents/DSP0243_1.0.0.pdf) defines: "The capacity of a virtual disk shall be specified by the ovf:capacity attribute with an xs:long integer value. The default unit of allocation shall be bytes. The optional string attribute ovf:capacityAllocationUnits may be used to specify a particular unit of allocation"
Created attachment 853937 [details] Proposed patch to solve a few disk sizing issues Proposed patch for resolution of issue. * ovf:capacityAllocationUnits becomes optional * ovf:capacityAllocationUnits is now interpreted the same way as the patch for https://bugzilla.redhat.com/show_bug.cgi?id=1056126 proposes, with OVF-compliant parsing of the value, collapsing it into a bytes value.
Hi, thanks for the bug report. Unfortunately it is filed against a very old version of virt-v2v (0.9) which we don't support at all. Luckily there is a newer version which almost certainly fixes your bug already. It's available starting in Fedora 21. If you still experience this bug, please try with the new version, and reopen if it still happens.
(In reply to Richard W.M. Jones from comment #1) > Unfortunately it is filed against a > very old version of virt-v2v (0.9) Well, that tends to happen if you wait 16 months with a reply to a ready2commit submitted patch.