On 04.09.2015 11:40, Daniel P. Berrange wrote:
> On Fri, Sep 04, 2015 at 10:56:52AM +0300, Nikolay Shirokovskiy wrote:
>>>> @@ -1396,6 +1585,9 @@ static virHypervisorDriver vzDriver = {
>>>> .domainBlockStatsFlags = vzDomainBlockStatsFlags, /* 1.2.17 */
>>>> .domainInterfaceStats = vzDomainInterfaceStats, /* 1.2.17 */
>>>> .domainMemoryStats = vzDomainMemoryStats, /* 1.2.17 */
>>>> + .connectSupportsFeature = vzConnectSupportsFeature, /* 1.2.20 */
>>>> + .domainMigratePrepare3Params = vzDomainMigratePrepare3Params, /* 1.2.20 */
>>>> + .domainMigratePerform3Params = vzDomainMigratePerform3Params, /* 1.2.20 */
>>>
>>> Somewhat annoyingly you also need to implement the callbacks for
>>> .domainMigratePrepare3 and .domainMigratePerform3, as we don't
>>> automatically convert non-params usage to the params based
>>> method AFAICT.
>>>
>>> Your impl of .domainMigratePerform3 could pack the values into a
>>> virTypedParams array and then call .domainMigratePerform3Params,
>>> or do the reverse.
>> Yes, without plain(non-params) callbacks we get working only toURI3
>> API function and I create a patch not included in this patchset
>> to make toURI{1,2} work too. I take this approach of converting
>> parameters and use one common worker function but patch a different
>> place - API implementaion itself. So I'll include this patch
>> in next version of the set.
>>
>> As in this case I need to patch 2 different sets of API implementation
>> *migrate{N} and *migrateURI{N} I'd rather put direct managed support
>> to a different patchset. Is it ok?
>
> Yeah, that'd be fine as long as we still compile at each step it isn't
> a problem if the impl is not final.
Ok. Then I'll send patch supporting toURI{1, 2} in a different patchset as it will
be a new thing that could lead to meaningless ping-ponging of parts
already areed upon.
>
>
> Regards,
> Daniel
>
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list