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

[Kashyap Chamarthy]

On 10/05/2012 08:33 PM, Eric Blake wrote:
> On 10/05/2012 08:00 AM, Michal Privoznik wrote:
>> On 04.10.2012 16:44, Eric Blake wrote:
>>> This is the bare minimum to kick off a block commit.  In particular,
>>> flags support is missing (shallow requires us to crawl the backing
>>> chain to determine the file name to pass to the qemu monitor command;
>>> delete requires us to track what needs to be deleted at the time
>>> the completion event fires), and top must be non-NULL (matching the
>>> fact that the current qemu code does not support committing the
>>> active layer, although it is still planned to add that before 1.3).
>>> Since the active layer won't change, we have it easy and do not have
>>> to alter the domain XML.  We are also relying on qemu to do some
>>> error detection on our behalf (such as validating 'top' and 'base'
>>> as being members of the backing chain).  Additionally, this will
>>> fail if SELinux is enforcing, because we fail to grant qemu proper
>>> read/write access to the files it will be modifying.
>>>
> 
>>> +
>>> +static int
>>> +qemuDomainBlockCommit(virDomainPtr dom, const char *path, const char *base,
>>> +                      const char *top, unsigned long bandwidth,
>>> +                      unsigned int flags)
>>> +{
>>> +    struct qemud_driver *driver = dom->conn->privateData;
>>> +    qemuDomainObjPrivatePtr priv;
>>> +    virDomainObjPtr vm = NULL;
>>> +    char *device = NULL;
>>> +    int ret = -1;
>>> +    virDomainEventPtr event = NULL;
>>
>> Not used yet. But since this is a stub only it doesn't really matter.
> 
> I'll scrub it out before pushing (it's leftover from my other
> unsubmitted branch for doing offline block commit, where we have to
> synthesize the event because qemu is not running).
> 
>>
>> Looks good.
> 
> 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.

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]

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)

[or]

Case-2/  [base] <--- [snap-1] <--- [active-layer]   # where data from snap2 & snap3 are
committed into 'snap1' (and thus, rightfully invalidating snap2 & snap3)

[or]

Case-3/  [base] <--- [snap-3] <--- [active-layer], # where data from snap1 & snap2 are
committed into the 'base' image (and thus, invalidating snap1 & snap2)


(All of the above, while the guest is live and running)

Please let me know if the above understanding is correct.

> 
> 
> 
> --
> libvir-list mailing list
> libvir-list at redhat.com
> https://www.redhat.com/mailman/listinfo/libvir-list
> 


-- 
/kashyap