[libvirt] [PATCH 1/4] conf: Output disk backing store details in domain XML

[Peter Krempa]

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>