On 08/26/11 12:03, Daniel P. Berrange wrote:
On Fri, Aug 26, 2011 at 11:54:49AM +0200, Gerd Hoffmann wrote:
On 08/19/11 19:08, Alon Levy wrote:
Fix the ticket expiration on target vm for a spice connection without
introducing
a race between the spice server switching the client to the new host itself and
the target libvirt setting the new expiration date, by adding an option to
client_migrate_info to not automatically switch the client on migration
completion,
instead waiting for an explicit client_migrate_switch (new monitor command) from
libvirt.
Hmm. Guess the fundamental issue is that libvirt wants to use the
monitor to set the ticket instead of the command line for security
reasons. The qemu monitor doesn't accept commands while the
incoming migration is running. We also can't kick the incoming
migration via monitor, so first setting the ticket then start
migration doesn't work too. Correct?
There is actually a reliable window where we can use the monitor
before incoming migration starts. Libvirt's migration is a 5 stage
handshake:
1. Begin(src)
- Gets current source VM XML config
2. Prepare(dst)
- Launches QEMU -incoming
- Sets passwords, etc to monitor
3. Perform(src)
Those stages are all serialized, so we can do anything we like
with the QEMU monitor at stage 2, before stage 3 will start
back on the src.
Ok, so I think we should be able to fix the race outlined above without
adding new monitor commands, just by letting libvirt set the spice
ticket in stage 2.
cheers,
Gerd
