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 -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
