Re: [libvirt] [PATCH v2 00/14] Add TLS support for migration
On 03/01/2017 06:57 AM, Jiri Denemark wrote:
On Tue, Feb 28, 2017 at 11:07:21 -0500, John Ferlan wrote:
> On 02/28/2017 08:48 AM, Jiri Denemark wrote:
>> The code should check whether QEMU actually supports TLS migration,
>> otherwise you will get
>>
>> internal error: unable to execute QEMU command
>> 'migrate-set-parameters': Invalid parameter 'tls-creds'
>>
>
> Hmm... I see tls-creds added to migrate-set-parameters in 2.7 while
> they were added to ChardevSocket in 2.6... Ugh. Have to refresh my
> recollection of how to get the answer I need from capabilities.
query-migrate-parameters used by qemuMonitorJSONGetMigrationParams is
your friend. And that's the reason why I said you actually might need
the *_set variables.
That jiggled a memory strand... It really wasn't clear from reading
QEMU's qapi-schema.json description that the Get would return anything
for tls-{creds,hostname}.
So for determining whether the option exists or not I'm left to other
options it seems. Even if code is added (in 2.9) to provide something
like an empty string - that'd have to be backported to 2.8 and 2.7 and
we'd have to somehow ensure/hope that was applied so that the right
answer could be returned from Get...
>> As I mentioned in my v1 review, we should always set the
parameters if
>> QEMU supports them to make sure they don't contain any leftovers from a
>> previous migration.
>
> I see from a quick scan of the qemu code though that it appears as if
> the code checks for a non null value being passed:
>
> params->has_tls_creds = !!s->parameters.tls_creds;
> params->has_tls_hostname = !!s->parameters.tls_hostname;
>
> So in order to "allow" clearing the tls_creds and tls_hostname, what
> would one do?
I was told Daniel should be the right person to ask.
>> {
>> "execute": "migrate-incoming",
>> "arguments": {
>> "uri": "tcp:[::]:49152"
>> },
>> "id": "libvirt-27"
>> }
>>
>> {
>> "execute": "object-del",
>> "arguments": {
>> "id": "objmigrate_tls0"
>> },
>> "id": "libvirt-28"
>> }
>>
>> The error reported after you deleted the objmigrate_tls0 object doesn't
>> seem to confirm your idea about migration parameters begin unset when
>> the object is removed.
>
> OK - well obviously there's still quite a bit for me to understand about
> the migration model.
I think you had this part correctly in the previous version. The Prepare
phase should only call qemuMigrationDelTLSObjects in case of error. The
Finish phase is where all the cleanup after a migration is done.
I'll look at what I changed - last week was a blur and a wedding with an
open bar over the weekend while the cure for many things has resulted in
a few less brain cells to recall my frame of reference!
>> Please, test your series before you send a new version of
it.
>
> Yep - something I noted in my cover letter - the need for a test
> environment... Hopefully I'll find a kind soul that will allow me to
> have access to an already configured environment to test with...
Setting up migration environment is trivial. You just need two hosts or
two VMs. The easiest way is configuring libvirt to listen on TCP with no
authorization and open the port on both firewalls. Then you only need a
domain to migrate. For most cases it doesn't even need a disk or you
can use a live CD image stored in the same path on both hosts. It's not
required to setup hostnames and make them resolvable from both hosts,
but you can avoid an extra argument to virsh migrate if you do so.
Setting up TLS is not hard either, you can follow
https://kashyapc.fedorapeople.org/gnutls-pki-setup.txt or you can use
easy-rsa.
Jirka
Sounds easy if you've done it before many times... It's not something I
do every day nor have I done once for libvirt before... ;-) I assumed
one really needed two hosts - I assume configuring two guests means
setting up nested virt, but that's something else I haven't done... and
the whole listen, open ports on firewalls makes my head spin.
John