Bug 1069407

This has been on my wishlist for a while, for several reasons.  Some thoughts on the matter:

Several times, people have opened bugs stating 'blockpull' (or some other chain manipulation command) doesn't work; but at the end of the day, it turns out they weren't using qemu-img -o backing_fmt=qcow2 when creating their backing chain, so libvirt was treating the backing file as raw to avoid a CVE while the user thought it was qcow2 and pointed to yet another backing file.  Having the full list of files as libvirt understands it would make it blatantly obvious when there are differences in expectations between the user and what libvirt is willing to probe without a format hint.

We also just recently hit a thread on the mailing list about how to support block rebase to a gluster volume, where having the full backing chain information available would make life much easier:
https://www.redhat.com/archives/libvir-list/2014-February/msg01226.html

It might be possible to provide this information without requiring a rebase, by expanding the <domain> XML to output the entire backing chain.  And this is a good move for multiple reasons as well.  Still, I can't help but wonder if a new API that returns just the chain information will be easier to use than the existing virDomainGetXMLDesc expanded to output full chain information.

I have heard mentioning a couple of times that libvirt would keep its own (cached) internal representation of the image chain. I am obviously fine with that but I am worried that we will hit some problems keeping it in sync in some corner cases (e.g. a block job ending when libvirt is down).

Eventually as phase 1 we could just have libvirt returning what query-block returns (without any caching). Anyway in this case it would be harder to go with the virDomainGetXMLDesc implementation (as you would need every time to loop with query-block calls over all the disks).

If libvirt starts tracking full backing chain in the <domain>, then libvirt is responsible to update the chain for every action initiated through libvirt, as well as flagging (perhaps by log messages and tainting the domain) any case where the chain reported by qemu differs from the chain that libvirt had recorded should be in effect.  If libvirtd is restarted across a long-running operation that is modifying the backing chain, then on restart, it should clean up its notion of the state to match the reality of the state reported by qemu.

Upstream implementation proposal:
https://www.redhat.com/archives/libvir-list/2014-March/msg00804.html

Upstream as of 1.2.4 release.  However, backporting may prove to be more pain than it is worth, since there are a LOT of prerequisite refactoring patches.

commit a2e369bc000126b6b0048ce1256c8cea00976f16
Author: Jiri Denemark <jdenemar>
Date:   Wed Apr 16 15:28:10 2014 +0200

    conf: Output disk backing store details in domain XML
    
    The XML for quite a longish backing chain is shown below:
    
      <disk type='network' device='disk'>
        <driver name='qemu' type='qcow2'/>
        <source protocol='nbd' name='bar'>
          <host transport='unix' socket='/var/run/nbdsock'/>
        </source>
        <backingStore type='block' index='1'>
          <format type='qcow2'/>
          <source dev='/dev/HostVG/QEMUGuest1'/>
          <backingStore type='file' index='2'>
            <format type='qcow2'/>
            <source file='/tmp/image2.qcow'/>
            <backingStore type='file' index='3'>
              <format type='qcow2'/>
              <source file='/tmp/image3.qcow'/>
              <backingStore type='file' index='4'>
                <format type='qcow2'/>
                <source file='/tmp/image4.qcow'/>
                <backingStore type='file' index='5'>
                  <format type='qcow2'/>
                  <source file='/tmp/image5.qcow'/>
                  <backingStore type='file' index='6'>
                    <format type='raw'/>
                    <source file='/tmp/Fedora-17-x86_64-Live-KDE.iso'/>
                    <backingStore/>
                  </backingStore>
                </backingStore>
              </backingStore>
            </backingStore>
          </backingStore>
        </backingStore>
        <target dev='vdb' bus='virtio'/>
      </disk>
    
    Various disk types and formats can be mixed in one chain. The
    <backingStore/> empty element marks the end of the backing chain and it
    is there mostly for future support of parsing the chain provided by a
    user. If it's missing, we are supposed to probe for the rest of the
    chain ourselves, otherwise complete chain was provided by the user. The
    index attributes of backingStore elements can be used to unambiguously
    identify a specific part of the image chain.
    
    Signed-off-by: Jiri Denemark <jdenemar>

(In reply to Eric Blake from comment #9)
> Upstream as of 1.2.4 release.  However, backporting may prove to be more
> pain than it is worth, since there are a LOT of prerequisite refactoring
> patches.

By "a LOT of prerequisite refactoring patches", I'm talking easily over 100 patches (not a trivial task).  Basically, the new XML depends on the virStorageSource struct, which itself touches a lot of the tree to consolidate four similar but previously distinct types.