On 10/06/2012 12:52 AM, Kashyap Chamarthy wrote: > 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) (of-course with relevant changes to the 'emulator' attribute to the domain's libvirt xml file) > > 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. > >> > > -- /kashyap -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list