On Fri, Feb 22, 2013 at 09:06:42AM +0100, Peter Krempa wrote: > On 02/19/13 13:35, Jiri Denemark wrote: > >Introduce virDomainMigrateGetCompressionCache and > >virDomainMigrateSetCompressionCache APIs. > >--- > > include/libvirt/libvirt.h.in | 7 +++ > > python/generator.py | 1 + > > src/driver.h | 11 +++++ > > src/libvirt.c | 100 +++++++++++++++++++++++++++++++++++++++++++ > > src/libvirt_public.syms | 2 + > > 5 files changed, 121 insertions(+) > > > >diff --git a/include/libvirt/libvirt.h.in b/include/libvirt/libvirt.h.in > >index 9d1c6ea..7e89e2e 100644 > >--- a/include/libvirt/libvirt.h.in > >+++ b/include/libvirt/libvirt.h.in > >@@ -1215,6 +1215,13 @@ int virDomainMigrateSetMaxDowntime (virDomainPtr domain, > > unsigned long long downtime, > > unsigned int flags); > > > >+int virDomainMigrateGetCompressionCache(virDomainPtr domain, > >+ unsigned long long *cacheSize, > >+ unsigned int flags); > >+int virDomainMigrateSetCompressionCache(virDomainPtr domain, > >+ unsigned long long cacheSize, > >+ unsigned int flags); > > Hm, again those seem to me a bit too qemucentric. As we now have > APIs to set migration speed and this would introduce another set for > cache size, I'm wondering if we couldn't go for something more > universal. For example the flag would control which parameter of > migration gets set. > > As this would introduce increased complexity, I'm not insisting on > this. A second opinion is welcome. I both agree & disagree. Given our existing approach to migration, I'm fine with this patch as is. Long term I do think we need todo something different. Our approach to migration has clearly failed, as witnessed by the many many versions of APIs we've created. I think we need to create a standalone virDomainMigrateParams object, and have methods to read/write params on that. Then we just need virDomainMigrateWithParmas() and virDomainMigrateUpdateParams() to change them on the fly. This will avoid us having to crate new v2/v3/v4 migration APIs longer term. 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 :| -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list