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

On 10/06/2012 12:34 AM, Eric Blake wrote: > 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): Yes, I can do that. I'll be testing this over the weekend. I have the latest qemu.git(with the above commit from Anthony ed61fc10), compiled for arch x86_64. So, just to clarify, so I don't mess up, on libvirt's latest git, I'm applying only these two patches as below: [PATCH 1/2] blockjob: manage qemu block-commit monitor command [PATCH 2/2] blockjob: wire up online qemu block-commit # git am -3 /path-to-patch1 # git am -3 /path-to-patch2 # ./autogen.sh # make # make check Then run the below (while using the qemu binary from it's git # ./x86_64-softmmu/qemu-system-x86_64 --enable-kvm -smp 2 -m 1024 /home/kashyap/vmimages/f17vm2.qcow2)

And use the 'virsh' to do the testing from the fresh compile: # ./run ./tools/virsh ... > >> >> 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). Thanks, that's clear. >