[libvirt] [PATCH v2 00/14] Add TLS support for migration

[Jiri Denemark]

On Wed, Mar 01, 2017 at 12:51:32 +0000, Daniel P. Berrange wrote:
> On Wed, Mar 01, 2017 at 01:39:18PM +0100, Jiri Denemark wrote:
> > On Wed, Mar 01, 2017 at 12:18:23 +0000, Daniel P. Berrange wrote:
> > > Hmm, I see this is a limitation of the migrate-set-parameters method. You
> > > can set new parameters for tls_creds / tls_hostname, but you can't fully
> > > delete the old parameters.
> > > 
> > > The tls_hostname is only set on the source host of the migration and that
> > > VM will be killed off upon successful migration. The problem only arises
> > > if you have a migration that fails, and you then try to migrate that same
> > > VM again later, *and* you don't have tls_hostname set. I don't think that'd
> > > hit libvirt, since libvirt will always need to set tls-hostname as it uses
> > > fd: migrate method. IOW, I don't see any need to be able to clear
> > > tls-hostname when used with libvirt.
> > 
> > But we will only set it if TLS is turned on. We certainly don't want to
> > use this parameter when saving a domain to a file, making a snapshot, or
> > migrating without TLS.
> 
> If you don't have TLS enabled, then whether tls-hostname is set or not
> is irrelevant - it'll never be used. So the fact that tls-hostname may
> be still mistakenly set, when you later save to a file is harmless, as
> long as tls-creds is unset.

OK, makes sense. Although it also makes sense for the two parameters to
provide the same behavior.

> > > For TLS creds it would be a problem if we do a TLS migration and then need
> > > to migrate the target QEMU again later, but don't want TLS used, as that
> > > would require us to fully clear the tls_creds parameter. At best we can
> > > set it to empty string, which is not good enough. So seems we need a QEMU
> > > fix here.
> > 
> > Another problem (I mentioned in another email in this series) is
> > query-migrate-parameters does not show the tls parameters unless they
> > are set. So it looks like we need to invent a special value which can be
> > reported when they are unset and we could use the same special value to
> > reset them. An empty string sounds like an obvious candidate.

As Pavel mentioned offline, JSON supports null value. So it could be an
option too.

Jirka