[libvirt-users] Looks like blockpull does not accept a subset of the entire chain of backing files

[Richard Gomes]

Hello Eric,

Absolutely enlightening!

Thanks a lot :)

Richard Gomes
http://rgomes.info
http://www.linkedin.com/in/rgomes
mobile: +44(77)9955-6813
inum <http://www.inum.net/>: +883(5100)0800-9804
sip:rgomes at ippi.fr

On 29/01/14 16:46, Eric Blake wrote:
> On 01/29/2014 07:51 AM, Richard Gomes wrote:
>> Hello
>>
>> If I'm not terribly mistaken, looks like libvirt 1.2.1 does not provide
>> ability of merging only a subset of the entire chain of backing files.
> Correct - qemu doesn't provide full functionality for merging in all
> directions.  And even though upstream qemu has been adding more pieces
> (for example, they recently added the ability to commit the active
> image), libvirt still has to be taught to exercise that.
>
>> So, if I have a chain like this:
>>
>>                  root <- a <-b <- c <- d <- active
>>
>> ... and  I'd like to obtain a chain like this:
>>
>>                   root <-  c <- d <- active
> Are you trying to squash a and b into root (commit direction, in which
> case, the existing block-commit command works just fine for this
> scenario) or into c (pull direction, in which case, qemu doesn't support
> it yet)?
>
>> The point is: How could I obtain the results I'm trying to achieve via
>> command (1) ?
> In the current blockpull implementation, qemu refuses to pull into
> anything but the active image (true even for your use of qemu 1.7).
> I've been asking for the ability to pull into intermediate images, but
> it isn't there yet.
>
>> I'm new to libvirt, but the article below made me think that what I'm
>> trying to do would be possible:
> That said, it IS possible to fake the same effect, using a series of
> block-rebase and raw qemu-img commands (not heavily tested, so you may
> still have to tweak the actions you use).  Also, block mirroring doesn't
> yet work with persistent disks (because qemu doesn't yet have a way to
> resume an operation across restarts), so you temporarily have to make
> your domain transient (virsh undefine $dom); you can redefine it at the
> end of the sequence.
>
> Start from root <- a <- b <- c <- d <- active
>
> Create c1 with 'cp c c1' for this tree:
> root <- a <- b \- c <- d <- active
>                 - c1
>
> Merge a and b into c1 with 'qemu-img rebase -b base c1' for this tree:
> root \- a <- b <- c <- d <- active
>       ------------c1
>
> Create d1 with 'cp d d1' for this tree:
> root \- a <- b <- c \- d <- active
>       ------------c1 - d1
>
> Use 'qemu-img rebase -u -b c1 d1' for this tree:
> root \- a <- b <- c <- d <- active
>       ------------c1 <- d1
>
> Create a blank destination active file wrapping d1, with 'qemu-img
> create -f qcow2 -o backing_file=d1,backing_fmt=qcow2 active1' for this tree:
> root \- a <- b <- c <- d <- active
>       ------------c1 <- d1 <- active1
>
> Set up a block mirroring, and pivot over to the new chain once it is
> stable, with 'virsh blockcopy $dom active --dest active1 --shallow
> --reuse-external --wait --pivot', for this tree:
> root \------------c1 <- d1 <- active1
>       - a <- b <- c <- d <- active
>
> Clean up - a, b, c, d, and active are now no longer in use, and both
> qemu and libvirt see the shorter chain (albeit with new file names),
> with virtually no guest downtime.
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/libvirt-users/attachments/20140129/f6720f30/attachment.htm>