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

Re: [libvirt] [PATCH 1/3] Add public API for setting migration speed on the fly



On Mon, Mar 21, 2011 at 11:55:58AM -0600, Eric Blake wrote:
> On 03/21/2011 10:13 AM, Daniel P. Berrange wrote:
> > It is possible to set a migration speed limit when starting
> > migration. This new API allows the speed limit to be changed
> > on the fly to adjust to changing conditions
> > 
> > * src/driver.h, src/libvirt.c, src/libvirt_public.syms,
> >   include/libvirt/libvirt.h.in: Add virDomainMigrateSetMaxSpeed
> > * src/esx/esx_driver.c, src/lxc/lxc_driver.c,
> >   src/opennebula/one_driver.c, src/openvz/openvz_driver.c,
> >   src/phyp/phyp_driver.c, src/qemu/qemu_driver.c,
> >   src/remote/remote_driver.c, src/test/test_driver.c,
> >   src/uml/uml_driver.c, src/vbox/vbox_tmpl.c,
> >   src/vmware/vmware_driver.c, src/xen/xen_driver.c: Stub new
> >   API
> 
> Missing mention of the new libxl driver...
> 
> > ---
> >  include/libvirt/libvirt.h.in |    4 +++
> >  src/driver.h                 |    5 ++++
> >  src/esx/esx_driver.c         |    1 +
> >  src/libvirt.c                |   47 ++++++++++++++++++++++++++++++++++++++++++
> >  src/libvirt_public.syms      |    1 +
> >  src/libxl/libxl_driver.c     |    1 +
> 
> but the diffstat shows you picked it up :)
> 
> > +++ b/include/libvirt/libvirt.h.in
> > @@ -436,6 +436,10 @@ int virDomainMigrateSetMaxDowntime (virDomainPtr domain,
> >                                      unsigned long long downtime,
> >                                      unsigned int flags);
> >  
> > +int virDomainMigrateSetMaxSpeed(virDomainPtr domain,
> > +                                unsigned long bandwidth,
> > +                                unsigned int flags);
> 
> Hmm - SetMaxDowntime and SetMaxSpeed; this looks like we might be
> running into scalability issues.  Are there likely to ever be other
> migration parameters worth setting on the fly?  If so, is it better to
> come up with an all-inclusive API, more like the memory and blkio
> parameters have recently done (where you pass in a
> string-name/union-value mapping for each parameter of interest through a
> single API)?

I think that would be overkill here.

> > +++ b/src/libvirt_public.syms
> > @@ -431,6 +431,7 @@ LIBVIRT_0.9.0 {
> >          virDomainSetMemoryFlags;
> >          virEventRegisterDefaultImpl;
> >          virEventRunDefaultImpl;
> > +        virDomainMigrateSetMaxSpeed;
> 
> Should this list stay sorted?

It could do

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 :|


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