Re: [PATCH 10/14] Introduce virDomainMigrate*CompressionCache APIs

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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


[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]