Bug 1030795 - storage: libvirt doesn't handle vmdk images with some subformats
storage: libvirt doesn't handle vmdk images with some subformats
Status: NEW
Product: Virtualization Tools
Classification: Community
Component: libvirt (Show other bugs)
unspecified
x86_64 Linux
medium Severity medium
: ---
: ---
Assigned To: Libvirt Maintainers
Virtualization Bugs
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-11-15 02:16 EST by chhu
Modified: 2016-06-22 12:49 EDT (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed:
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description chhu 2013-11-15 02:16:46 EST
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 12:37:13 EDT
Moving to upstream tracker as there seems to be no real need for that.  Feel free to add more information in case that changes.

Note You need to log in before you can comment on or make changes to this bug.