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