[Spice-devel] Seamless mode for switch_host migration?

[David Jaša]

Hi,

this email is a wrap-up of in-person discussion with Hans about bug:
https://bugzilla.redhat.com/show_bug.cgi?id=884631

The problem is that if client tries to connect to destination host when
VM is already migrating. The problem can be triggered:
     1. using the steps in bug: start migration, then connect to the VM.
        In this scenario, the client can never get client_migrate_info
        because it is not connected at the time of sending it
     2. by high latency between already connected client and destination
        host (not tested but anticipated by Hans). The cause is that
        libvirt starts qemu migration right after it receives return
        message from client_migrate_info regardless of
        connected/seamless statuses

At this point, client is connected to source qemu but it can not connect
to destination qemu because client_migrate_info was never sent to it in
first case, and because qemu is migrating and has stopped event loop in
second case.
This stage of migration can last varying amouts of time, from just a few
seconds for small-memory VMs migrating over fast unlimited network, to
at least minutes: when migrating large-memory VMs over highly-utilized
or capped network.

When final synchronization happens, all features that require seamless
migration (USB redirection, smartcard, c&p transfer, ...) are
interrupted, some of them temporarily (c&p), some of them sort of
permanently (USB device is unshared and user has to manually share it
again).

Hans's idea to address this issue was to leverage the fact that libvirt
doesn't terminate src qemu till it receives qmp message indicating that
seamless migration is done:
     1. after migration synchronization finishes, src spice-server
        checks client connection status to dst spice-server:
             1. if connected, go on
             2. if not, send client client_migrate_info and wait till
                client connects to dst spice-server
     2. perform actual seamless migration. We can do it because the
        client is now connected to both servers regardless of what
        connection status was at the end of final synchronization

This code path should fix the gap with least amount of effort overall.
It doesn't seem to be suitable to have it as default though because the
several src <--> client <--> dst roundtrips may considerably add to time
when VM console is unresponsive to the user -- but for cases when client
is connected, it's a little price to pay for having all spice features
available.

Yonit, what do you think about all of these? Is it doable to have this
work finished for next release of spice-server?

David

-- 

David Jaša, RHCE

SPICE QE based in Brno
GPG Key:     22C33E24 
Fingerprint: 513A 060B D1B4 2A72 7F0D 0278 B125 CD00 22C3 3E24