Description of problem: When trying to import an OVA file, the disk size is mismatched when not using gigabytes as unit. I downloaded the following ova (which works in VMWare 6.5u1): http://cdn.watchguard.com/SoftwareCenter/Files/XTM/12_1_3/xtmv_12_1_3.ova In the ova file, the ovf definition file contains the following info about the disks: <DiskSection> <Info>List of the virtual disks and partitions needed</Info> <Disk ovf:capacity="4520" ovf:capacityAllocationUnits="byte * 2^20" ovf:diskId="system" ovf:fileRef="rootfs_id" ovf:format="http://www.vmware.com/interfaces/specifications/vmdk.html#streamOptimized" ovf:populatedSize="271646720"/> </DiskSection> The capacityAllocationUnits value is 1MB, but when trying to import the OVA, ovirt shows me a disk capacity of 4520GB. I have played with other files, it seems that oVirt does not honor ovf:capacityAllocationUnits="byte * 2^20" and uses "byte * 2^30" in all cases, which would explain the problem. Version-Release number of selected component (if applicable): ovirt-engine-4.2.5.3-1.el7.noarch vdsm-4.20.35-1.el7.x86_64 How reproducible: Steps to Reproduce: 1. Download the following ova http://cdn.watchguard.com/SoftwareCenter/Files/XTM/12_1_3/xtmv_12_1_3.ova 2. In the GUI in VM list, use the import function and select Source OVA 3. Select the ova file on local disk 4. Check disk size before actual import Actual results: Disk size is 4520GB (4520 * 2^30) Expected results: Dis size should be 4520GB (4520 * 2^20) Additional info:
Arik, any idea?
(In reply to Tal Nisan from comment #1) > Arik, any idea? Yes, that's a known gap (see the comment on [1]) that got low priority because we never saw an OVF that uses capacity units other than bytes or gigabytes. [1] https://github.com/oVirt/ovirt-engine/blob/master/backend/manager/modules/utils/src/main/java/org/ovirt/engine/core/utils/ovf/OvfOvaReader.java#L205
Thanks, in my case I just rewrote the ovf and mf files. I've created a quick PR in order to improve the default behavior, see https://github.com/oVirt/ovirt-engine/pull/13
(In reply to Orsiris de Jong from comment #3) > Thanks, in my case I just rewrote the ovf and mf files. > > I've created a quick PR in order to improve the default behavior, see > https://github.com/oVirt/ovirt-engine/pull/13 Thanks! Would you be kind enough to submit it through gerrit [1] (the github repository is just a mirror of the one in gerrit)? [1] https://www.ovirt.org/develop/dev-process/working-with-gerrit/
Created https://gerrit.ovirt.org/#/c/93830/ Thanks for your help.
External Bug ID: ovirt gerrit 93844 (updated earlier PR).
Verified on 4.2.7-0.1.el7ev. Used same scenario & ova file: 1. Download the following ova http://cdn.watchguard.com/SoftwareCenter/Files/XTM/12_1_3/xtmv_12_1_3.ova to vdsm_host1:/tmp/xtmv_12_1_3.ova 2. In the GUI in VM list, use the import function and select Source OVA 3. Select the ova file on the local disk (vdsm_host1:/tmp/xtmv_12_1_3.ova ) 4. Check disk size before actual import -> this time checking UI before import, disk virtual size seen was 4G(4520MB = 4520 * 2^20 bytes) as expected and not as seen in the original bug size(4520GB).
This bugzilla is included in oVirt 4.2.7 release, published on November 2nd 2018. Since the problem described in this bug report should be resolved in oVirt 4.2.7 release, it has been closed with a resolution of CURRENT RELEASE. If the solution does not work for you, please open a new bug report.