Hi, > Absolutely not. This is hideously ugly and affects a bunch of code. > > Spice is *not* getting a hook in migration where it gets to add > arbitrary amounts of downtime to the migration traffic. That's a > terrible idea. > > I'd like to be more constructive in my response, but you aren't > explaining the problem well enough for me to offer an alternative > solution. You need to find another way to solve this problem.
Very short version: The requirement is simply to not kill qemu on the source side until the source spice-server has finished session handover to the target spice-server. Long version: spice-client connects automatically to the target machine, so the user ideally doesn't notice that his virtual machine was just migrated over to another host. Today this happens via "switch-host", which is a simple message asking the spice client to connect to the new host. We want move to "seamless migration" model where we don't start over from scratch, but hand over the session from the source to the target. Advantage is that various state cached in spice-client will stay valid and doesn't need to be retransmitted. It also requires a handshake between spice-servers on source and target. libvirt killing qemu on the source host before the handshake is done isn't exactly helpful. [ Side note: In theory this issue exists even today: in case the data pipe to the client is full spice-server will queue up the switch-host message and qemu might be killed before it is sent out. In practice it doesn't happen though because it goes through the low-traffic main channel so the socket buffers usually have enougth space. ] So, the big question is how to tackle the issue? Option (1): Wait until spice-server is done before signaling completion to libvirt. This is what this patch series implements. Advantage is that it is completely transparent for libvirt, thats why I like it. Disadvantage is that it indeed adds a small delay for the spice-server handshake. The target qemu doesn't process main loop events while the incoming migration is running, and because of that the spice-server handshake doesn't run in parallel with the final stage of vm migration, which it could in theory. BTW: There will be no "arbitrary amounts of downtime". Seamless spice client migration is pretty pointless if it doesn't finish within a fraction of a second, so we can go with a very short timeout there. Option (2): Add a new QMP event which is emmitted when spice-server is done, then make libvirt wait for it before killing qemu. Obvious disadvantage is that it requires libvirt changes. Option (3): Your suggestion? thanks, Gerd
