Re: [libvirt] [PATCH 1/4] 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(a)redhat.com&gt; --- docs/formatdomain.html.in | 59 +++++++++++++++++++ docs/schemas/domaincommon.rng | 48 ++++++++++++++-- tests/domainschemadata/backing-chains.xml | 94 +++++++++++++++++++++++++++++++ 3 files changed, 195 insertions(+), 6 deletions(-) create mode 100644 tests/domainschemadata/backing-chains.xml diff --git a/docs/formatdomain.html.in b/docs/formatdomain.html.in index e851f85..a6fccd9 100644 --- a/docs/formatdomain.html.in +++ b/docs/formatdomain.html.in

@@ -1814,6 +1828,51 @@ This feature doesn't support migration currently. </p> </dd> + <dt><code>backingStore</code></dt> + <dd> + This element describes the backing store used by the disk specified by + sibling <code>source</code> element. <span class="since">Since + 1.2.4</span>. An empty <code>backingStore</code> element means the + sibling source is self-contained and is not based on any backing store. + The following attributes and sub-elements are supported in + <code>backingStore</code>: + <dl> + <dt><code>type</code> attribute</dt> + <dd> + The <code>type</code> attribute represents the type of disk used + by the backing store, see disk type attribute above for more + details and possible values. + </dd> + <dt><code>index</code> attribute</dt> + <dd> + This attribute is only valid in output (and ignored on input) and + it can be used to refer to a specific part of the disk chain when + doing block operations (such as via the + <code>virDomainBlockRebase</code> API). For example, + <code>vda[2]</code> refers to the backing store with + <code>index='2'</code> of the disk with <code>vda</code> target. + </dd> + <dt><code>format</code> sub-element</dt> + <dd> + The <code>format</code> element contains <code>type</code> + attribute which specifies the internal format of the backing + store, such as <code>raw</code> or <code>qcow2</code>. + </dd> + <dt><code>source</code> sub-element</dt> + <dd> + This element has the same structure as the <code>source</code> + element in <code>driver</code>. It specifies which file, device,

+ or network location contains the data of the described backing + store. + </dd> + <dt><code>backingStore</code> sub-element</dt> + <dd> + If the backing store is not self-contained, the next element + in the chain is described by nested <code>backingStore</code> + element. + </dd> + </dl> + </dd> <dt><code>mirror</code></dt> <dd> This element is present if the hypervisor has started a block