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@xxxxxxxxxx
> https://www.redhat.com/mailman/listinfo/libvir-list
>
--
/kashyap
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list