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