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