[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [libvirt] [PATCH 12/13] qemu: Set up the migrate TLS objects for target




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


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]