[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