On 02/21/2017 04:25 PM, Jiri Denemark wrote:
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
I flipped a coin and it landed on heads which said, add it to the command line. I can add the objects to the server prior to usage and setting of the parameters just like is done for the client. My "experience" with libvirt migration is limited - so thanks for the extra details about -incoming... The original thoughts I had on this were very different, but thankfully I found Daniel's blog... John