[libvirt] [PATCH v4 2/6] vz: add migration backbone code

Daniel P. Berrange berrange at redhat.com
Fri Sep 4 08:40:26 UTC 2015


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.


Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|




More information about the libvir-list mailing list