Hide Forgot
Description of problem: Client closes when client_migrate_info sent by qemu matches the already established connection Version-Release number of selected component (if applicable): virt-viewer-0.5.7-2.el7.x86_64 How reproducible: 100% Steps to Reproduce: 1. Connect to a VM 2. On the VM command line send client_migrate_info where destination and port are the same as the ones you used for connection Actual results: Client closes Expected results: Client should stay connected
I can reproduce this bug with the following packages and steps: # rpm -qa virt-viewer virt-viewer-0.5.7-2.el7.x86_64 Steps 1. boot the guest with following command # /usr/libexec/qemu-kvm -m 4G -cpu SandyBridge -smp 4,sockets=2,cores=2,threads=1 -drive file=/var/lib/libvirt/images/nfs/kvm-rhel6.5-x86_64-raw.img,if=none,id=drive-ide0-0-0,werror=stop,rerror=stop,cache=none -device ide-drive,drive=drive-ide0-0-0,id=ide0-0-0 -boot menu=on -uuid 6d59434d-3f1c-4558-afc3-37e2cc430d6b -rtc-td-hack -no-kvm-pit-reinjection -monitor stdio -name rhel6.1-32 -usb -k en-us -device virtio-serial-pci,id=virtio-serial0,max_ports=16,bus=pci.0,addr=0x7 -chardev socket,id=channel0,host=127.0.0.1,port=12345,server,nowait -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=channel0,id=channel0,name=com.redhat.rhevm.vdsm -chardev spicevmc,id=charchannel1,name=vdagent -device virtserialport,bus=virtio-serial0.0,nr=2,chardev=charchannel1,id=channel1,name=com.redhat.spice.0 -spice port=5900,disable-ticketing -vga qxl -global qxl-vga.vram_size=33554432 Warning: option deprecated, use lost_tick_policy property of kvm-pit instead. QEMU 1.5.3 monitor - type 'help' for more information (qemu) 2. connect to the vm by remote-viewer #remote-viewer spice://127.0.0.1:5900 3. send client_migrate_info where destination and port are the same as the ones used for remote-viewer connection. (qemu) client_migrate_info spice 127.0.0.1 5900 results: the remote-viewer connnection is closed.
The seamless migration protocol works by connecting to destination server upon MAIN_MIGRATE_BEGIN_SEAMLESS. The server will break the current connection for the new incoming connection, the exisiting client will quit. It's not possible to detect this case from client (the same server could have multiple IPs etc) Since it's an invalid operation in the first place to migrate to the same server instance, and the current behaviour is normal in this case (client will quit because of disconnection) I don't think there is anything to fix.