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

[Kashyap Chamarthy]

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