[libvirt] [PATCH v3 0/5] Next round of active commit support
Kashyap Chamarthy
kchamart at redhat.com
Mon Jun 23 17:58:17 UTC 2014
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
More information about the libvir-list
mailing list