[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,
Lee
>
> Regards,
> Daniel
More information about the libvir-list
mailing list