[libvirt] RFC: storage migration via pre-copy and streaming mirrors

[Eric Blake]

On 03/26/2012 09:59 PM, Eric Blake wrote:
> This is the counter-proposal to my earlier RFC for storage migration via
> snapshot mirrors[1], resulting from a NACK on the code review for that
> earlier proposal[2].  In particular, this proposal fleshes out some of
> Paolo's design overview on the qemu wiki[3].
> 

> 
> Under //domain/drivers/disk, next to <source file='...'/>, add <mirror
> file='...'/>

I'm debating on the best way to lay this out.  Right now, we have:

<domain ...>...
  <devices>
    <disk type='file' device='disk'>
      <driver name='qemu' type='raw'/>
      <source file='/var/lib/libvirt/images/fedora-local.img'/>
      <target dev='vda' bus='virtio'/>
    </disk>

But with the new virDomainBlockCopy, you can specify a different file
format for the mirror.  I'm also thinking towards a future day where we
can have the <domain> list the entire backing chain, rather than probing
qcow2 headers.  One idea is to have <driver> and <source> repeated for
each layer of the chain, where <mirror> specifies a parallel chain, and
<backingFile> nests.  For example, suppose I create a mirror with the
following layout (this could be created via virDomainBlockCopy(dom,
"top", "base", "mirror", "qed", 0, 0), as a way to convert file types
and collapse the chain on the fly but without changing the raw base file):

base[raw] <- middle[qcow2] <- top[qcow2]
          \-------- mirror[qed]

    <disk ...>
      <driver name='qemu' type='qcow2'/>
      <source file='/path/to/top'/>
      <mirror>
        <driver name='qemu' type='qed'/>
        <source file='/path/to/mirror'/>
        <backingFile>
          <driver name='qemu' type='raw'/>
          <source file='/path/to/base'/>
        </backingFile>
      </mirror>
      <backingFile>
        <driver name='qemu' type='qcow2'/>
        <source file='/path/to/middle'/>
        <backingFile>
          <driver name='qemu' type='raw'/>
          <source file='/path/to/base'/>
        </backingFile>
      </backingFile>
    </disk>

On the other hand, while the top-level <driver> holds items like caching
and error policy, it can be assumed that the mirror and backing file
chain share that policy, so the only unique thing for mirrors and
backing files is the file type.  Also, instead of nesting, you can rely
on ordering of repetitive elements.  Perhaps the same relationship could
be shown as:

    <disk ...>
      <driver name='qemu' type='qcow2'/>
      <source file='/path/to/top'/>
      <mirror>
        <source file='/path/to/mirror' format='qed'/>
        <backing file='/path/to/base' format='raw'/>
      </mirror>
      <backing file='/path/to/middle' format='qcow2'/>
      <backing file='/path/to/base' format='raw'/>
    </disk>

Preferences?

-- 
Eric Blake   eblake at redhat.com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 620 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20120327/dfaa04ff/attachment-0001.sig>