On 04/21/14 10:32, Jiri Denemark wrote: > 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@xxxxxxxxxx> > --- > 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, s/driver/disk/ ? > + 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 Maybe we should also document that user-specified backing chains aren't currently supported. ACK with the two issues above addressed. Peter
Attachment:
signature.asc
Description: OpenPGP digital signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list