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.
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.
Jirka