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

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?