On Mon, Jun 23, 2014 at 09:39:08AM -0600, Eric Blake wrote: > On 06/21/2014 04:34 AM, Kashyap Chamarthy wrote: > > I just tried to test this series built from Eric's libvirt git repo, and > > QEMU built from its git. > > > > On a live (or offline guest) I see the below: > > > > $ virsh blockcommit f20vm1 vda --shallow --wait \ > > --verbose --pivot --active > > error: unsupported flags (0x4) in function qemuDomainBlockCommit > > > > I also tried: > > > > $ virsh blockcommit --domain f20vm1 vda \ > > --base /home/kashyap/vmimages/snap3-f20vm1.qcow2 \ > > --top /home/kashyap/vmimages/snap4-f20vm1.qcow2 \ > > --wait --verbose --pivot --active > > error: unsupported flags (0x4) in function qemuDomainBlockCommit > > > > Is that expected? > > Unfortunately, yes, unless you have also applied Jeff's pending patches > for qemu that actually enable optional 'top': > > https://lists.gnu.org/archive/html/qemu-devel/2014-06/msg04060.html Yep, I just applied the above patch to today's QEMU git and tested with same libvirt (from your repos.or.cz instance) commit ID that I pointed to in my earlier email in this thread, and active blockcommit w/ 'virsh' works for me. Following are details of a simple test I did. Before active blockcommit ------------------------- - I had a chain like that: [base] <-- [snap1] <-- [snap2] <-- [snap3] <-- [snap4] (current-active) - Current active block device in use: $ virsh domblklist f20vm1 Target Source ------------------------------------------------ vda /home/kashyap/vmimages/snap4.qcow2 Perform active blockcommit -------------------------- The below commmand will commit contents of [snap4] into [snap3] and makes [snap3] as the current active image invalidating [snap4]: $ virsh blockcommit f20vm1 vda --shallow --wait \ --verbose --pivot --active Block Commit: [100 %] Successfully pivoted After active blockcommit ------------------------ The chain has reduced to below (shortened by one image): [base] <-- [snap1] <-- [snap2] <-- [snap3] (current-active) Again, check what's the current active block device via 'virsh' (it should reflect 'snap3'): $ virsh domblklist f20vm1 Target Source ------------------------------------------------ vda /home/kashyap/vmimages/snap3.qcow2 Also, it updated the 'virsh dumpxml' output just fine. Lastly, I ran active blockcommit again (w/ --shallow), so the chain is now reduced to [base] <-- [snap1] <-- [snap2] (current-active) And, here's its associated 'virsh dumpxml' output showing the uppdated backing store (chain reduced by two): $ virsh dumpxml f20vm1 | grep "snap2.qcow2" -A10 -B2 <disk type='file' device='disk'> <driver name='qemu' type='qcow2'/> <source file='/home/kashyap/vmimages/snap2.qcow2'/> <backingStore type='file' index='1'> <format type='qcow2'/> <source file='/home/kashyap/vmimages/snap1.qcow2'/> <backingStore type='file' index='2'> <format type='qcow2'/> <source file='/home/kashyap/vmimages/f20vm1.qcow2'/> <backingStore/> </backingStore> </backingStore> <target dev='vda' bus='virtio'/> So, works as described in the patch titled "blockcommit: turn on active commit" (on libvir-list). Will test more once patches are committed to git. > You're very bleeding edge; I won't push my patches to libvirt.git until > qemu.git also has matching patches, so in the meantime, you have to > carry patches on both repos. Peter has been doing some rpm builds of > the bits and pieces for integration testing, but I'm not sure if he is > planning on publishing them for public consumption yet. No worries, I can test manually apply patches ('git am -3') from the list to test. -- /kashyap -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list