On 02/20/2017 11:03 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(a)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(+)
>
> diff --git a/src/qemu/libvirtd_qemu.aug b/src/qemu/libvirtd_qemu.aug
> index 82bae9e..18679c1 100644
> --- a/src/qemu/libvirtd_qemu.aug
> +++ b/src/qemu/libvirtd_qemu.aug
> @@ -54,6 +54,11 @@ module Libvirtd_qemu =
> | bool_entry "chardev_tls_x509_verify"
> | str_entry "chardev_tls_x509_secret_uuid"
>
> + let migrate_entry = bool_entry "migrate_tls"
> + | str_entry "migrate_tls_x509_cert_dir"
> + | bool_entry "migrate_tls_x509_verify"
> + | str_entry "migrate_tls_x509_secret_uuid"
> +
> let nogfx_entry = bool_entry "nographics_allow_host_audio"
>
> let remote_display_entry = int_entry "remote_display_port_min"
> @@ -116,6 +121,7 @@ module Libvirtd_qemu =
> | vnc_entry
> | spice_entry
> | chardev_entry
> + | migrate_entry
> | nogfx_entry
> | remote_display_entry
> | security_entry
> diff --git a/src/qemu/qemu.conf b/src/qemu/qemu.conf
> index 97d769d..83d91b6 100644
> --- a/src/qemu/qemu.conf
> +++ b/src/qemu/qemu.conf
> @@ -238,6 +238,45 @@
> #chardev_tls_x509_secret_uuid = "00000000-0000-0000-0000-000000000000"
>
>
> +# Enable use of TLS encryption for migration
> +#
> +# It is necessary to setup CA and issue a server certificate
> +# before enabling this.
> +#
> +#migrate_tls = 1
Actually what is this option supposed to do? It seems it doesn't do
anything but saying "yes, I configured TLS for migration". The TLS usage
for migration is turned on by VIR_MIGRATE_TLS flag which suggests the
configuration option here is useless.
Jirka
It more or less follows the same logic for chardev's which got an
additional 'tls="yes"' to allow one to enable/disable an object in a
domain on a case by case basis if chardev tls was enabled for the host.
See:
http://libvirt.org/formatdomain.html#elementsConsole
and search down for 'tls'
So my feeling while coding was - if I don't supply some sort of way to
have an option to allow someone to choose to use the configured TLS
environment for the migration, I'd end up being asked to add one since
chardev has it.
IIRC using 'haveTLS' for chardev's was debated during reviews... Between
Pavel and I the code was added and 'massaged' to deal with release
differences (that's all a blur in memory though).
Regardless, based on Daniel's comment - if this does remain a conf
parameter - perhaps the "default" description needs to be adjusted to
indicate the usage model described, while the 'chardev' and 'migrate'
(if added) specific descriptions would be altered to describe usage for
exposure to some end user.
I'm not opposed to dropping this and letting the "default" credentials
to be used. Makes things easier. Perhaps in the future it could be
resurrected if requested.
John