On Fri, Feb 17, 2017 at 14:39:29 -0500, John Ferlan wrote:
Support TLS for a migration is a multistep process. The target guest
must
be started using the "-object tls-creds-x509,endpoint=server,...". If that
TLS object requires a passphrase an addition "-object security..." would
also be created. The alias/id used for the TLS object is "objmigrate_tls0",
while the alias/id used for the security object is "migrate-secret0".
Heh, we should just hotplug the objects similarly to what the source
does. As a bonus we should get a bit better error message when the
destination QEMU does not support TLS. We already use -incoming defer
for quite some time exactly because we want to be able to configure
migration parameters before asking QEMU to listen for the migration
stream. And since -incoming defer was introduced long before TLS
migration, we can unconditionally require it. If you want to be extra
safe, you can report an error if anyone tries to use TLS migration with
QEMU which does not support -incoming defer (QEMU_CAPS_INCOMING_DEFER).
BTW, are the error messages good enough if the destination QEMU does not
support TLS or do we need to probe for TLS support and report the error
ourselves?
Jirka