Re: [libvirt] [PATCH v2 00/14] Add TLS support for migration
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/ :|