Bug 1030795

Summary: storage: libvirt doesn't handle vmdk images with some subformats
Product: [Community] Virtualization Tools Reporter: chhu
Component: libvirtAssignee: Libvirt Maintainers <libvirt-maint>
Status: CLOSED DEFERRED QA Contact: Virtualization Bugs <virt-bugs>
Severity: medium Docs Contact:
Priority: medium    
Version: unspecifiedCC: crobinso, dyuan, libvirt-maint, mkletzan, mzhan
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2020-11-03 16:38:46 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description chhu 2013-11-15 07:16:46 UTC
Description of problem:
libvirt doesn't handle vmdk images with the following subformats:
    - monolithicFlat
    - twoGbMaxExtentSparse
    - twoGbMaxExtentFlat

Version-Release number of selected component (if applicable):
libvirt-1.1.1-12.el7.x86_64
qemu-kvm-1.5.3-19.el7.x86_64

How reproducible:
100%

Steps to Reproduce:

1. Use the qemu-img create the vmdk images:

# qemu-img create -f vmdk test1.vmdk -o subformat=monolithicFlat 2G
Formatting 'test1.vmdk', fmt=vmdk size=2147483648 compat6=off subformat='monolithicFlat' zeroed_grain=off 

# qemu-img create -f vmdk test3.vmdk -o subformat=twoGbMaxExtentSparse 2G
Formatting 'test3.vmdk', fmt=vmdk size=2147483648 compat6=off subformat='twoGbMaxExtentSparse' zeroed_grain=off 

# qemu-img create -f vmdk test4.vmdk -o subformat=twoGbMaxExtentFlat 2G
Formatting 'test4.vmdk', fmt=vmdk size=2147483648 compat6=off subformat='twoGbMaxExtentFlat' zeroed_grain=off 

2. Check the format in qemu-img info, the files' format are vmdk, and the size are 2.0G

3. Check these disks' info in libvirt. The format are raw, and the capacity are not 2G.

# virsh vol-dumpxml /var/lib/libvirt/images/test1.vmdk 
<volume>
  <name>test1.vmdk</name>
  <key>/var/lib/libvirt/images/test1.vmdk</key>
  <source>
  </source>
  <capacity unit='bytes'>315</capacity>
  <allocation unit='bytes'>4096</allocation>
  <target>
    <path>/var/lib/libvirt/images/test1.vmdk</path>
    <format type='raw'/>
......

# virsh vol-dumpxml /var/lib/libvirt/images/test3.vmdk 
<volume>
  <name>test3.vmdk</name>
  <key>/var/lib/libvirt/images/test3.vmdk</key>
  <source>
  </source>
  <capacity unit='bytes'>321</capacity>
  <allocation unit='bytes'>4096</allocation>
  <target>
    <path>/var/lib/libvirt/images/test3.vmdk</path>
    <format type='raw'/>
......

# virsh vol-dumpxml /var/lib/libvirt/images/test4.vmdk 
<volume>
  <name>test4.vmdk</name>
  <key>/var/lib/libvirt/images/test4.vmdk</key>
  <source>
  </source>
  <capacity unit='bytes'>319</capacity>
  <allocation unit='bytes'>4096</allocation>
  <target>
    <path>/var/lib/libvirt/images/test4.vmdk</path>
    <format type='raw'/>
......

Current results:
In step3 the format are raw, and the capacity are not 2G.

Expect results:
In step3 the format are vmdk, and the capacity are 2G.

Comment 8 Martin Kletzander 2016-06-22 16:37:13 UTC
Moving to upstream tracker as there seems to be no real need for that.  Feel free to add more information in case that changes.

Comment 9 Daniel Berrangé 2020-11-03 16:38:46 UTC
Thank you for reporting this issue to the libvirt project. Unfortunately we have been unable to resolve this issue due to insufficient maintainer capacity and it will now be closed. This is not a reflection on the possible validity of the issue, merely the lack of resources to investigate and address it, for which we apologise. If you none the less feel the issue is still important, you may choose to report it again at the new project issue tracker https://gitlab.com/libvirt/libvirt/-/issues The project also welcomes contribution from anyone who believes they can provide a solution.