[libvirt] [PATCH 10/14] Introduce virDomainMigrate*CompressionCache APIs
Daniel P. Berrange
berrange at redhat.com
Fri Feb 22 13:52:41 UTC 2013
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 :|
More information about the libvir-list
mailing list