[libvirt] [RFCv2 PoCv1 PATCH 00/15] Just Admin API

Lee Schermerhorn lee.schermerhorn at hp.com
Fri Apr 17 13:31:58 UTC 2015

On Fri, 2015-04-17 at 11:30 +0100, Daniel P. Berrange wrote:
> On Thu, Apr 16, 2015 at 04:46:10PM +0200, Martin Kletzander wrote:
> > *** BLURB ***
> > 
> > ...
> > 
> > Just kidding :)
> > 
> > Sooo...  After very very VERY long time, here's a draft of an admin
> > interface that is supposed to open up new possibilities to be done on
> > a live daemon.  The aim here is to create some first inches of that
> > API in order to open up the possibility of new API function creation
> > to more people.
> > 
> > I already spent so much time explaining so much of that that I don't
> > know what else to point at in here.  Maybe the fact that last three
> > patches are just an example on how this might work.  Of course there
> > won't be any functions like listClientIDs with the need of getting
> > each client info by another API.  There's going to be
> > e.g. virAdmClientInfo and virAdmGetClients() will return the list of
> > them, etc.  Long story short, let's not repeat past mistakes ;)
> > 
> > With all that said, feel free to hate, love, comment or just try out
> > compiling this series and let me know how many things I've missed and
> > screwed up (hopefully zero).
> Broadly speaking I think this all looks like pretty good approach
> to me. We should probably think about exactly which API we want
> to target for inclusion in the first release.
> Perhaps the ability to change the logging filters & outputs would
> be the most useful one, as its something people often want to have
> in the production deployments where restarting libvirtd is not an
> option.

How about reloading the server TLS certificates?

virNetTLSContextNew() contains the comment:

    /* Generate Diffie Hellman parameters - for use with DHE
     * kx algorithms. These should be discarded and regenerated
     * once a day, once a week or once a month. Depending on the
     * security requirements.

If I understand correctly, currently one must restart libvirtd to pickup
new certificates?  I wondered whether Martin's patch 4/15 -- multiple
NetSubServers -- would allow introduction of a new cert on a new
SubServer w/o restarting libvirtd?  E.g., to allow long running
migration, blockcopy or other jobs to complete on existing connections
before destroying them.

If that would be possible, I think would would also be useful for early
inclusion for people considering ephemeral certificates.


> Regards,
> Daniel

More information about the libvir-list mailing list