Re: [libvirt] [PATCH v3 0/5] Next round of active commit support
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