RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1529663 - No backing file info in the output of 'virsh vol-dumpxml' for images created by qemu-img
Summary: No backing file info in the output of 'virsh vol-dumpxml' for images created...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: libvirt
Version: 7.5
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Peter Krempa
QA Contact: Han Han
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-12-29 08:31 UTC by yafu
Modified: 2018-05-24 03:24 UTC (History)
10 users (show)

Fixed In Version: libvirt-3.9.0-7.el7
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-04-10 11:04:21 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHEA-2018:0704 0 None None None 2018-04-10 11:05:38 UTC

Description yafu 2017-12-29 08:31:57 UTC 
Description of problem:
No backing file info in the output of 'virsh vol-dumpxml' for images created by qemu-img.

Version-Release number of selected component:
libvirt-3.9.0-6.el7.x86_64
qemu-img-rhev-2.10.0-13.el7.x86_64

Steps to reproduce:
1.Create a image based on base image:
# qemu-img create -f qcow2 -o backing_file=/var/lib/libvirt/images/s1.img -F qcow2 /var/lib/libvirt/images/s2.img
Formatting '/var/lib/libvirt/images/s2.img', fmt=qcow2 size=9663676416 backing_file=/var/lib/libvirt/images/rhel7.4.qcow2 backing_fmt=qcow2 cluster_size=65536 lazy_refcounts=off refcount_bits=16

2.Check the image info with qemu-img:
#qemu-img info /var/lib/libvirt/images/s2.img --backing-chain
image: /var/lib/libvirt/images/s2.img
file format: qcow2
virtual size: 100M (104857600 bytes)
disk size: 196K
cluster_size: 65536
***backing file: /var/lib/libvirt/images/s1.img*****
backing file format: qcow2
Format specific information:
compat: 1.1
lazy refcounts: false
refcount bits: 16
corrupt: false

image: /var/lib/libvirt/images/s1.img
file format: qcow2
virtual size: 100M (104857600 bytes)
disk size: 196K
cluster_size: 65536
Format specific information:
compat: 1.1
lazy refcounts: false
refcount bits: 16
corrupt: false


3.Refresh the pool:
#virsh pool-refresh default

4.List the vol in the pool:
#virsh vol-list default
Name Path
------------------------------------------------------------------------------
s1.img /var/lib/libvirt/images/s1.img
s2.img /var/lib/libvirt/images/s2.img

5.Use 'virsh vol-dumpxml' to get the image info:
#virsh vol-dumpxml s2.img default
<volume type='file'>
<name>s2.img</name>
<key>/var/lib/libvirt/images/s2.img</key>
<source>
</source>
<capacity unit='bytes'>104857600</capacity>
<allocation unit='bytes'>200704</allocation>
<physical unit='bytes'>196616</physical>
<target>
<path>/var/lib/libvirt/images/s2.img</path>
<format type='qcow2'/>
<permissions>
<mode>0644</mode>
<owner>0</owner>
<group>0</group>
<label>unconfined_u:object_r:virt_image_t:s0</label>
</permissions>
<timestamps>
<atime>1513765094.968345180</atime>
<mtime>1513765094.967345167</mtime>
<ctime>1513765094.967345167</ctime>
</timestamps>
<compat>1.1</compat>
<features/>
</target>
</volume>

Actual results:
No backing file info in the output of 'virsh vol-dumpxml'

Expected results:
'virsh vol-dumpxml' can show the backing file info correctly.

Additional info:
It works well with libvirt-3.2.0-14.el7_4.5.x86_64.
Comment 3 Peter Krempa 2018-01-03 15:05:37 UTC 
Fixed upstream:

commit d0307a9a766f1eb0f24ad2cc7c7ae730f1bde966 
Author: Julio Faracco <jcfaracco>
Date:   Tue Jan 2 16:52:20 2018 -0200

    storage: Fixing missing 'backingStore' tag from volume XML dumps.
    
    After commit a693fdb 'vol-dumpxml' missed the ability to show backingStore
    information. This commit adds a volume type for files that fixes this
    problem.
Comment 6 Han Han 2018-01-09 09:32:58 UTC 
Hi, Peter,
I tried as comment0 and find it works on libvirt-3.9.0-7.el7.x86_64
qemu-kvm-rhev-2.10.0-15.el7.x86_64. But for block volume type, it doesn't works:
1. Prepare a logical pool named HostVG and create 1 LV
# virsh vol-list HostVG
 Name                 Path                                    
------------------------------------------------------------------------------
 aa                   /dev/HostVG/aa                          

2. Create backing chain and refresh pool
# lvcreate -n cc HostVG -L 1G                                                                                                          
  Logical volume "cc" created.

# qemu-img create -b /dev/HostVG/aa /dev/HostVG/cc -f qcow2 -o backing_fmt=raw
Formatting '/dev/HostVG/cc', fmt=qcow2 size=1073741824 backing_file=/dev/HostVG/aa backing_fmt=raw cluster_size=65536 lazy_refcounts=off refcount_bits=16

# virsh pool-refresh HostVG                                                   
Pool HostVG refreshed

3. Show volume xml
# virsh vol-list HostVG             
 Name                 Path                                    
------------------------------------------------------------------------------
 aa                   /dev/HostVG/aa                          
 cc                   /dev/HostVG/cc  

# qemu-img info /dev/HostVG/cc                                                
image: /dev/HostVG/cc
file format: qcow2
virtual size: 1.0G (1073741824 bytes)
disk size: 0
cluster_size: 65536
backing file: /dev/HostVG/aa
backing file format: raw
Format specific information:
    compat: 1.1
    lazy refcounts: false
    refcount bits: 16
    corrupt: false


# virsh vol-dumpxml cc --pool HostVG                                        
<volume type='block'>
  <name>cc</name>
  <key>CWTAtL-HYEL-tLPt-zy8J-1OKl-bxgk-IatDEz</key>
  <source>
    <device path='/dev/sdg'>
      <extent start='1073741824' end='2147483648'/>
    </device>
  </source>
  <capacity unit='bytes'>1073741824</capacity>
  <allocation unit='bytes'>1073741824</allocation>
  <physical unit='bytes'>1073741824</physical>
  <target>
    <path>/dev/HostVG/cc</path>
    <permissions>
      <mode>0660</mode>
      <owner>0</owner>
      <group>6</group>
      <label>system_u:object_r:fixed_disk_device_t:s0</label>
    </permissions>
    <timestamps>
      <atime>1515490120.980453780</atime>
      <mtime>1515490120.980453780</mtime>
      <ctime>1515490120.980453780</ctime>
    </timestamps>
  </target>
</volume>

No backingStore element in volume xml. Since the patch only contains changes on file type, I think block/dir/network/netdir have the similar problem.
Comment 7 Han Han 2018-01-31 08:57:56 UTC 
Verified on qemu-kvm-rhev-2.10.0-18.el7.x86_64 libvirt-3.9.0-9.el7.x86_64:
1. Create a backing file in a dir pool:
# qemu-img create /var/lib/libvirt/images/a 100M
Formatting '/var/lib/libvirt/images/a', fmt=raw size=104857600

# qemu-img create -b /var/lib/libvirt/images/a /var/lib/libvirt/images/b -o backing_fmt=raw -f qcow2
Formatting '/var/lib/libvirt/images/b', fmt=qcow2 size=104857600 backing_file=/var/lib/libvirt/images/a backing_fmt=raw cluster_size=65536 lazy_refcounts=off refcount_bits=16

2. Refresh the dir pool and dump the volume xml:
# virsh pool-refresh default                                                                        
Pool default refreshed

# virsh vol-dumpxml --pool default b
<volume type='file'>
  <name>b</name>
  <key>/var/lib/libvirt/images/b</key>
  <source>
  </source>
  <capacity unit='bytes'>104857600</capacity>
  <allocation unit='bytes'>200704</allocation>
  <physical unit='bytes'>196616</physical>
  <target>
    <path>/var/lib/libvirt/images/b</path>
    <format type='qcow2'/>
    <permissions>
      <mode>0644</mode>
      <owner>0</owner>
      <group>0</group>
      <label>unconfined_u:object_r:virt_image_t:s0</label>
    </permissions>
    <timestamps>
      <atime>1517388988.033868398</atime>
      <mtime>1517386690.691808870</mtime>
      <ctime>1517386690.691808870</ctime>
    </timestamps>
    <compat>1.1</compat>
    <features/>
  </target>
  <backingStore>
    <path>/var/lib/libvirt/images/a</path>
    <format type='raw'/>
    <permissions>
      <mode>0644</mode>
      <owner>0</owner>
      <group>0</group>
      <label>unconfined_u:object_r:virt_image_t:s0</label>
    </permissions>
    <timestamps>
      <atime>1517388988.022868299</atime>
      <mtime>1517386652.359479929</mtime>
      <ctime>1517386652.359479929</ctime>
    </timestamps>
  </backingStore>
</volume>

volume backing image is shown.
Comment 8 Peter Krempa 2018-01-31 15:53:11 UTC 
(In reply to Han Han from comment #6)
> Hi, Peter,
> I tried as comment0 and find it works on libvirt-3.9.0-7.el7.x86_64
> qemu-kvm-rhev-2.10.0-15.el7.x86_64. But for block volume type, it doesn't
> works:
> 1. Prepare a logical pool named HostVG and create 1 LV
> # virsh vol-list HostVG
>  Name                 Path                                    
> -----------------------------------------------------------------------------
> -
>  aa                   /dev/HostVG/aa                          
> 
> 2. Create backing chain and refresh pool
> # lvcreate -n cc HostVG -L 1G                                               
> 
>   Logical volume "cc" created.
> 
> # qemu-img create -b /dev/HostVG/aa /dev/HostVG/cc -f qcow2 -o
> backing_fmt=raw
> Formatting '/dev/HostVG/cc', fmt=qcow2 size=1073741824
> backing_file=/dev/HostVG/aa backing_fmt=raw cluster_size=65536
> lazy_refcounts=off refcount_bits=16
> 
> # virsh pool-refresh HostVG                                                 
> 
> Pool HostVG refreshed
> 
> 3. Show volume xml
> # virsh vol-list HostVG             
>  Name                 Path                                    
> -----------------------------------------------------------------------------
> -
>  aa                   /dev/HostVG/aa                          
>  cc                   /dev/HostVG/cc  
> 
> # qemu-img info /dev/HostVG/cc                                              
> 
> image: /dev/HostVG/cc
> file format: qcow2
> virtual size: 1.0G (1073741824 bytes)
> disk size: 0
> cluster_size: 65536
> backing file: /dev/HostVG/aa
> backing file format: raw
> Format specific information:
>     compat: 1.1
>     lazy refcounts: false
>     refcount bits: 16
>     corrupt: false
> 
> 
> # virsh vol-dumpxml cc --pool HostVG                                        

[...]

> </volume>
> 
> No backingStore element in volume xml. Since the patch only contains changes
> on file type, I think block/dir/network/netdir have the similar problem.

So, looking at the code I have following conclusion:

Libvirt supports following storage pool types:
    VIR_STORAGE_POOL_DIR,      /* Local directory */                            
    VIR_STORAGE_POOL_FS,       /* Local filesystem */                           
    VIR_STORAGE_POOL_NETFS,    /* Networked filesystem - eg NFS, GFS, etc */   

All of the above pools operate on local files and use the common code which I've fixed, so all of them should work fine.

    VIR_STORAGE_POOL_LOGICAL,  /* Logical volume groups / volumes */            

The logical pool has a different idea of using <backingStore>. The element is populated for sparse LVs and not by the contents of the qcow2 image.

    VIR_STORAGE_POOL_DISK,     /* Disk partitions */                            
    VIR_STORAGE_POOL_ISCSI,    /* iSCSI targets */                              
    VIR_STORAGE_POOL_SCSI,     /* SCSI HBA */                                   
    VIR_STORAGE_POOL_MPATH,    /* Multipath devices */                          
    VIR_STORAGE_POOL_RBD,      /* RADOS Block Device */                         
    VIR_STORAGE_POOL_SHEEPDOG, /* Sheepdog device */                            

These don't ever populate (and didn't even before) the backingStore pointer, so it certainly will never show up for these.

    VIR_STORAGE_POOL_GLUSTER,  /* Gluster device */                             

Gluster sets the backing store type already, so it should work as it used to.

    VIR_STORAGE_POOL_ZFS,      /* ZFS */                                        

This one doesn't ever populate the backingStore.

    VIR_STORAGE_POOL_VSTORAGE, /* Virtuozzo Storage */   

This uses the local file helpers so it should work.


It looks to me as if no other changes are necessary ...
Comment 12 errata-xmlrpc 2018-04-10 11:04:21 UTC 
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:0704
Note You need to log in before you can comment on or make changes to this bug.