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