Re: [PATCH v3 2/3] libxl: move begin phase job handling

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Joao Martins wrote:
> 
> On 02/02/2016 01:23 AM, Jim Fehlig wrote:
>> On 01/20/2016 12:00 PM, Joao Martins wrote:
>>> . From libxlMigrationBegin to libxlDomainMigrateBegin3Params().
>>> This is a preparatory patch to be able to begin a job in the
>>> perform phase.
>>>
>>> Signed-off-by: Joao Martins <joao.m.martins@xxxxxxxxxx>
>>> ---
>>>  src/libxl/libxl_driver.c    | 18 +++++++++++++++++-
>>>  src/libxl/libxl_migration.c | 16 +++-------------
>>>  2 files changed, 20 insertions(+), 14 deletions(-)
>>>
>>> diff --git a/src/libxl/libxl_driver.c b/src/libxl/libxl_driver.c
>>> index d34f843..28220b2 100644
>>> --- a/src/libxl/libxl_driver.c
>>> +++ b/src/libxl/libxl_driver.c
>>> @@ -5187,6 +5187,8 @@ libxlDomainMigrateBegin3Params(virDomainPtr domain,
>>>  {
>>>      const char *xmlin = NULL;
>>>      virDomainObjPtr vm = NULL;
>>> +    libxlDriverPrivatePtr driver;
>>> +    char *ret;
>>>  
>>>  #ifdef LIBXL_HAVE_NO_SUSPEND_RESUME
>>>      virReportUnsupportedError();
>>> @@ -5223,7 +5225,21 @@ libxlDomainMigrateBegin3Params(virDomainPtr domain,
>>>          return NULL;
>>>      }
>>>  
>>> -    return libxlDomainMigrationBegin(domain->conn, vm, xmlin);
>>> +    driver = domain->conn->privateData;
>>> +    if (libxlDomainObjBeginJob(driver, vm, LIBXL_JOB_MODIFY) < 0) {
>>> +        virObjectUnlock(vm);
>>> +        return NULL;
>>> +    }
>>> +
>>> +    ret = libxlDomainMigrationBegin(domain->conn, vm, xmlin);
>>> +
>>> +    if (!libxlDomainObjEndJob(driver, vm))
>>> +        vm = NULL;
>> IIRC the qemu driver handles this a bit differently, and probably more
>> correctly. On the sender, a job is started during the begin phase and ended in
>> the confirm phase. On the receiver, a job is started in the prepare phase and
>> ended in the finish phase. This prevents modifying the virDomainObj between
>> phases, e.g. the begin and perform phases on the sender. Is it possible to
>> change the job handling similarly in the libxl migration phases?
>>
> Yeah, IIUC I believe this is the behavior depicted by
> VIR_MIGRATE_CHANGE_PROTECTION flag in which is set by default if the driver
> support it. So since we're going this way, we should adversite it too in
> libxlConnectSupportsFeature() ?

Yep, sounds good.

> Btw, the P2P patch keeps the original behavior wrt to jobs, and these two
> patches meant solely for improving job handling in migration in general. What do
> you think in making it a separate patch from this series? (with the changes
> suggested above)

Agreed. I'll take another look at the P2P patch and push it (after fixing the
nits) if there are no further comments. Implementing the CHANGE_PROTECTION
behavior and improving job handling should be done separately.

Regards,
Jim

--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list



[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]