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