[libvirt] [PATCH] migration: remove direct migration dependency on version1 of driver

Nikolay Shirokovskiy nshirokovskiy at parallels.com
Fri Aug 28 09:29:04 UTC 2015



On 28.08.2015 08:54, Michal Privoznik wrote:
> On 27.08.2015 12:23, Nikolay Shirokovskiy wrote:
>> From: Nikolay Shirokovskiy <Nikolay Shirokovskiy nshirokovskiy at virtuozzo.com>
>>
>> Direct migration should work if *perform3 is present but *perform
>> is not. This is situation when driver migration is implemented
>> after new version of driver function is introduced. We should not
>> be forced to support old version too as its parameter space is
>> subspace of newer one.
>>
>> Signed-off-by: Nikolay Shirokovskiy <nshirokovskiy at virtuozzo.com>
>> ---
>>  src/libvirt-domain.c |    3 ++-
>>  1 files changed, 2 insertions(+), 1 deletions(-)
>>
>> diff --git a/src/libvirt-domain.c b/src/libvirt-domain.c
>> index 6ab50ba..c89775b 100644
>> --- a/src/libvirt-domain.c
>> +++ b/src/libvirt-domain.c
>> @@ -3427,7 +3427,8 @@ virDomainMigrateDirect(virDomainPtr domain,
>>                       NULLSTR(xmlin), flags, NULLSTR(dname), NULLSTR(dconnuri),
>>                       NULLSTR(miguri), bandwidth);
>>  
>> -    if (!domain->conn->driver->domainMigratePerform) {
>> +    if (!domain->conn->driver->domainMigratePerform &&
>> +        !domain->conn->driver->domainMigratePerform3) {
>>          virReportUnsupportedError();
>>          return -1;
>>      }
>>
> 
> 
> Hm.. domainMigratePerform3 will be used iff connection driver has
> VIR_DRV_FEATURE_MIGRATION_V3 feature. But this check will require that
> regardless. What if we check the presence of implementation with respect
> to that?
I see you mean actual driver could be behind remote one and checking
for perform3 always gives true so we need to check for feature instead?
> 

> Moreover, can you please send patches rebased to current HEAD?
Sorry, most time i rebase.
> 
> Michal
> 




More information about the libvir-list mailing list