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

On 28.08.2015 08:54, Michal Privoznik wrote: > On 27.08.2015 12:23, Nikolay Shirokovskiy wrote: >> From: Nikolay Shirokovskiy <Nikolay Shirokovskiy nshirokovskiy(a)virtuozzo.com&gt; >> >> 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(a)virtuozzo.com&gt; >> --- >> 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?