On 28.08.2015 11:29, Nikolay Shirokovskiy wrote:
>
>
> On 28.08.2015 08:54, Michal Privoznik wrote:
>> On 27.08.2015 12:23, Nikolay Shirokovskiy wrote:
>>> From: Nikolay Shirokovskiy <Nikolay Shirokovskiy nshirokovskiy@xxxxxxxxxxxxx>
>>>
>>> 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@xxxxxxxxxxxxx>
>>> ---
>>> 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?
Sort of. domainMigratePerform3 is used only if the feature is present.
But after your patch, the function implementation would be needed
always, even if the feature is not present.
Michal
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list