[libvirt] Domain XML isn't dumping full backing chain

Deepak Shetty dpkshetty at gmail.com
Wed Mar 18 13:03:15 UTC 2015


Hmm interesting, so without adding backing_fmt, if i enable the below in
/etc/libvirt/qemu.conf, will it work ?

# If allow_disk_format_probing is enabled, libvirt will probe disk
# images to attempt to identify their format, when not otherwise
# specified in the XML. This is disabled by default.
#
# WARNING: Enabling probing is a security hole in almost all
# deployments. It is strongly recommended that users update their
# guest XML <disk> elements to include  <driver type='XXXX'/>
# elements instead of enabling this option.
#
#allow_disk_format_probing = 1


On Wed, Mar 18, 2015 at 5:33 PM, Shanzhi Yu <shyu at redhat.com> wrote:

>
>
> ------------------------------
>
> *From: *"Deepak Shetty" <dpkshetty at gmail.com>
> *To: *libvir-list at redhat.com
> *Sent: *Wednesday, March 18, 2015 7:19:05 PM
> *Subject: *[libvirt] Domain XML isn't dumping full backing chain
>
>
> Hi,
> I am using libvirt version 1.2.9.2 on F21 and i am unable to get the
> complete backing chain info in the virsh dumpxml output. Details below :
>
> *My backing chain per qemu-img :*
>
> [stack at devstack-f21 test]$ qemu-img info --backing-chain snap4.qcow2
> image: snap4.qcow2
> file format: qcow2
> virtual size: 1.0G (1073741824 bytes)
> disk size: 196K
> cluster_size: 65536
> backing file: ./snap3.qcow2
> Format specific information:
>     compat: 1.1
>     lazy refcounts: false
>
> image: ./snap3.qcow2
> file format: qcow2
> virtual size: 1.0G (1073741824 bytes)
> disk size: 196K
> cluster_size: 65536
> backing file: ./snap2.qcow2 (actual path: ././snap2.qcow2)
> Format specific information:
>     compat: 1.1
>     lazy refcounts: false
>
> image: ././snap2.qcow2
> file format: qcow2
> virtual size: 1.0G (1073741824 bytes)
> disk size: 196K
> cluster_size: 65536
> backing file: ./snap1.qcow2 (actual path: ./././snap1.qcow2)
> Format specific information:
>     compat: 1.1
>     lazy refcounts: false
>
> image: ./././snap1.qcow2
> file format: qcow2
> virtual size: 1.0G (1073741824 bytes)
> disk size: 196K
> cluster_size: 65536
> backing file: ./base.qcow2 (actual path: ././././base.qcow2)
> Format specific information:
>     compat: 1.1
>     lazy refcounts: false
>
> image: ././././base.qcow2
> file format: qcow2
> virtual size: 1.0G (1073741824 bytes)
> disk size: 196K
> cluster_size: 65536
> Format specific information:
>     compat: 1.1
>     lazy refcounts: false
>
> If you want prepare the backing chain yourself, you should  add "-o
> backing_fmt=$farmat" options,
> like "qemu-img create -f qcow2 base.s1 -b base.qcow2 -o backing_fmt=qcow2"
>
> I created 4 snapshots using commands (similar to the below, just dumping
> the last one here ):
>
> [stack at devstack-f21 test]$ virsh snapshot-create-as test-domain
> on-test-snap4  --disk-only --reuse-external --diskspec
> hda,snapshot=external,file=/home/stack/test/snap4.qcow2
> Domain snapshot on-test-snap4 created
>
> [stack at devstack-f21 test]$ virsh domblklist test-domain
> Target     Source
> ------------------------------------------------
> hda        /home/stack/test/snap4.qcow2
>
>
>
> virsh dumpxml test-domain|more
> ....
>
>     <disk type='file' device='disk'>
>       <driver name='qemu' type='qcow2' cache='none'/>
>       <source file='/home/stack/test/snap4.qcow2'/>
>       <backingStore type='file' index='1'>
>         <format type='raw'/>
>
> If you don't add "-o backing_fmt=qcow2", it will treat backing file format
> as raw format.
> Since a raw format file doesn't have a backing file, so you only see
> snap4.qcow2 and
> snap3.qcow2
>
>
>         <source file='/home/stack/test/./snap3.qcow2'/>
>         <backingStore/>
>       </backingStore>
>       <target dev='hda' bus='ide'/>
>       <alias name='ide0-0-0'/>
>       <address type='drive' controller='0' bus='0' target='0' unit='0'/>
>     </disk>
>
>
> .....
>
> I think thats happening beccause the backingStore format is coming as 'raw'
> What am i missing ?
>
> thanx,
> deepak
>
>
> --
> libvir-list mailing list
> libvir-list at redhat.com
> https://www.redhat.com/mailman/listinfo/libvir-list
>
>
>
>
> --
> Regards
> shyu
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20150318/6aa53a76/attachment-0001.htm>


More information about the libvir-list mailing list