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

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