libvirt users - Jan 2014 - Re: Looks like blockpull does not accept a subset of the entire chain of backing files

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@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.
>

On 01/31/2014 10:56 AM, Richard Gomes wrote:
> hello,
> 
> I'm trying to use macvtap on Debian Wheezy.
> Actually, I've installed a recent version of libvirt and qemu from
> wheezy-backports.
Your mail has nothing to do with your subject line.  It would have been
better to start a new thread instead of hijacking an unrelated one.

I don't personally know enough about building on Debian to be able to
answer your question.

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