On Tue, Feb 28, 2017 at 11:07:21AM -0500, John Ferlan wrote:
As I mentioned in my v1 review, we should always set the parameters if QEMU supports them to make sure they don't contain any leftovers from a previous migration.
I see from a quick scan of the qemu code though that it appears as if the code checks for a non null value being passed:
params->has_tls_creds = !!s->parameters.tls_creds; params->has_tls_hostname = !!s->parameters.tls_hostname;
That code is in the function for querying whether tls parameters are currently set.
So in order to "allow" clearing the tls_creds and tls_hostname, what would one do? The clearing would be necessary since a target of a migration will become a source for a migration and the tls-creds object would be different (using endpoint={server|client}).
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. 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. 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/ :|