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 _______________________________________________ Spice-devel mailing list Spice-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/spice-devel