[libvirt] [PATCH 1/4] conf: Output disk backing store details in domain XML
Peter Krempa
pkrempa at redhat.com
Tue Apr 22 11:02:17 UTC 2014
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 at redhat.com>
> ---
> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 901 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20140422/f0af3058/attachment-0001.sig>
More information about the libvir-list
mailing list