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

[Daniel Veillard]

On Tue, Mar 22, 2011 at 11:01:31AM +0000, Daniel P. Berrange wrote:
> 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.

  Agreed in this case too,

Daniel

-- 
Daniel Veillard      | libxml Gnome XML XSLT toolkit  http://xmlsoft.org/
daniel at veillard.com  | Rpmfind RPM search engine http://rpmfind.net/
http://veillard.com/ | virtualization library  http://libvirt.org/