[libvirt] [PATCH 2/2] blockjob: wire up online qemu block-commit

[Eric Blake]

On 10/05/2012 12:53 PM, Kashyap Chamarthy wrote:

>>
>> And Anthony just merged Jeff's patches into qemu.git today (now commit
>> ed61fc10), so I'll push this as soon as I complete another round of
>> testing, as well as work towards proper SELinux behavior.
> 
> Eric, Let me know how I can help you test here.

With qemu.git and with my patches applied (they are not yet in
libvirt.git, so you'll have to apply them yourself to test):

> 
> I'm trying to test the below scenario(based on Jcody's email to qemu-devel) for Block Commit :
> 
> Original state: [base] <-- [snap-1] <-- [snap-2] <-- [snap-3] <-- [active-layer]

Assuming that you have a domain with just one disk, labeled 'vda'
according to 'virsh domblklist', then...

> 
> Try to turn the into:
> 
> Case-1/   [base] <-- [active-layer]   # where snap1, snap2, snap3 are committed into
> the 'base' image (and thus, rightfully invalidating snap1 & snap2)

virsh blockcommit $dom vda --wait --base /path/to/base --top /path/to/snap-3

Note that your chain has to use absolute backing file names in the
current state of qemu.git (Jeff is working on a patch to work with
chains that used relative backing file names).

Also, note that the patches I have posted so far do not interact with
existing libvirt snapshots, so while you can verify that the disk images
have been properly modified (for example, after the commit completes,
stop the domain, then use qemu-img info active-layer to see that
active-layer's backing image is now base instead of snap-3), the fact
that you did a commit may make it harder to use any snapshots you
created via 'virsh snapshot-create --disk-only' to create the long chain
in the first place.

> 
> [or]
> 
> Case-2/  [base] <--- [snap-1] <--- [active-layer]   # where data from snap2 & snap3 are
> committed into 'snap1' (and thus, rightfully invalidating snap2 & snap3)

Similar to case-1, except that now you use --base snap-1.

> 
> [or]
> 
> Case-3/  [base] <--- [snap-3] <--- [active-layer], # where data from snap1 & snap2 are
> committed into the 'base' image (and thus, invalidating snap1 & snap2)

Similar to case-1, except that now you use --top snap-2.

> 
> 
> (All of the above, while the guest is live and running)

Yep - requires a running guest at the moment (I'm still trying to get
patches to support offline guest commits, using qemu-img, but it's
taking a while to iron out the design work necessary to track a child
qemu-img across libvirtd restarts).

-- 
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: 617 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20121005/396ddbed/attachment-0001.sig>