Hi, I've encountered an interesting problem: I did a live migration through libvirt (virsh migrate --live <domain> <dst_libvirt_uri> [<dst_qemu_uri>]) with usb transfer ongoing from qemu guest through usbredir over spice to usb device plugged to the client. The spice client failed to connect to the destination qemu/spice but the migration was conducted anyway, so the data transfer was abruptly terminated. Background ---------- When performing migration with client connected, two monitor commands are issued to the qemu: (qemu) client_migrate_info spice <client connection details> main_channel_client_handle_migrate_connected: client <ID> connected: 1 seamless: 1 (qemu) migrate -d tcp:<dst_qemu_address>:<port> The first command instructs spice client to reconnect to the new machine and the reply says that if connection is successful and if it is seamless (required for migration with USB redirection active). Problem ------- The behaviour should follow "least harm" principle: 1) In "severe" scenarios when the choice is between VM migration causing potential data corruption on redirected USB and stopping of the VM, current behavior is perfectly fine 2) In "regular" scenarios (automatic load balancing, manual migration requests by administrator), refuse to migrate (unless some "I really know what I'm doing" button is pressed) is better thing to do Possible solutions? ------------------- Just one possible way to fix this occured to me: 1. libvirt gets new switch to migrate command to force migration even when client can not connect 2. if this switch is not set and client won't connect after client_migrate_info qemu command is issued, cance migration 3. management application (ovirt-engine through vdsm) or administrator sets the switch to force migration in cases like 1) above I'll file the necessary bugs but it should be IMO first agreed what the correct approach is in such situations. David -- David Jaša, RHCE SPICE QE based in Brno GPG Key: 22C33E24 Fingerprint: 513A 060B D1B4 2A72 7F0D 0278 B125 CD00 22C3 3E24