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

Re: [libvirt] [PATCH 02/13] conf: Introduce migrate_tls_x509_cert_dir



On Mon, Feb 20, 2017 at 10:26:16AM -0500, John Ferlan wrote:
> 
> 
> On 02/20/2017 10:13 AM, Jiri Denemark wrote:
> > On Fri, Feb 17, 2017 at 14:39:19 -0500, John Ferlan wrote:
> >> Add a new TLS X.509 certificate type - "migrate". This will handle the
> >> creation of a TLS certificate capability (and possibly repository) to
> >> be used for migrations. Similar to chardev's, credentials will be handled
> >> via a libvirt secrets.
> >>
> >> Signed-off-by: John Ferlan <jferlan redhat com>
> >> ---
> >>  src/qemu/libvirtd_qemu.aug         |  6 ++++++
> >>  src/qemu/qemu.conf                 | 39 ++++++++++++++++++++++++++++++++++++++
> >>  src/qemu/qemu_conf.c               |  2 ++
> >>  src/qemu/qemu_conf.h               |  5 +++++
> >>  src/qemu/test_libvirtd_qemu.aug.in |  4 ++++
> >>  5 files changed, 56 insertions(+)
> > 
> > I'm not a big fan of setting up two sets of X.509 environments, but I
> > guess it could be useful to someone a we could always set both to the
> > same values, right?
> > 
> > Jirka
> > 
> 
> Cannot disagree... setting up one is daunting enough ;-)!
> 
> With this there's going to be 4 and could be 5 if NBD needed it's own
> (the other 3 being VNC, Spice, and Chardev)...  I do have a patch beyond
> this series "in process" which would do the same for NBD (but I keep
> thinking it'd be overkill).
> 
> For those that want just one, they would just define "migrate_tls=1" and
> then use the "default" environment (default_tls_x509_cert_dir).
> 
> Perhaps Daniel has more information about multi configured environments
> and what use they'd be.

I don't think you'd really set up different certs for every QEMU service.
In practice I think you'll see either 1 set of certs, or 2 sets of certs.
The former if every QEMU network service is only used inside the mgmt
LAN, and the latter if you have some network services you need to expose
directly to the end user (eg VNC).  I think even the latter case is
becoming less common though, as I see increasing preference for running
a websockets proxy in between the end user & vnc/spice server, at least
in the case of cloud - internal only data center virt may still expose
the consoles services dirctly to the end user.

Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://entangle-photo.org       -o-    http://search.cpan.org/~danberr/ :|


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