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

[Kashyap Chamarthy]

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.

> 


-- 
/kashyap