1022565 – client_migrate_info fails when r-v connects through vv file over SSL encryption

Bug 1022565 - client_migrate_info fails when r-v connects through vv file over SSL encryption

Summary: client_migrate_info fails when r-v connects through vv file over SSL encryption

Keywords:
Status:	CLOSED ERRATA
Alias:	None
Product:	Red Hat Enterprise Linux 6
Classification:	Red Hat
Component:	spice-gtk
Sub Component:
Version:	6.5
Hardware:	Unspecified
OS:	Unspecified
Priority:	unspecified
Severity:	high
Target Milestone:	rc
Target Release:	---
Assignee:	Marc-Andre Lureau
QA Contact:	Desktop QE
Docs Contact:
URL:
Whiteboard:
Depends On:
Blocks:	1036833
TreeView+	depends on / blocked

Reported:	2013-10-23 14:31 UTC by Marian Krcmarik
Modified:	2017-02-07 12:24 UTC (History)
CC List:	6 users (show)
Fixed In Version:	spice-gtk-0.22-1.el6
Doc Type:	Bug Fix
Doc Text:	Cause: Migration of a VM with a client connected via mime connection file and SSL. Consequence: The migration falls back to non-seamless, because the CA isn't correctly copied form memory. Fix: Copy the CA on destination session. Result: The seamless migration can be realized with success.
Clone Of:
Clones:	1036833 (view as bug list)
Environment:
Last Closed:	2014-10-14 06:46:34 UTC
Target Upstream Version:

Attachments	(Terms of Use)
Add an attachment (proposed patch, testcase, etc.)

Links
System	ID	Private	Priority	Status	Summary	Last Updated
Red Hat Product Errata	RHBA-2014:1487	0	normal	SHIPPED_LIVE	spice-gtk bug fix and enhancement update	2014-10-14 01:28:31 UTC

Description Marian Krcmarik 2013-10-23 14:31:55 UTC

Description of problem:
client_migrate_info qemu monitor command fails - "main_channel_client_handle_migrate_connected: client 0x7f9090cddc90 connected: 0 seamless 0" when remote-viewer is connected to the source qemu instance with using vv file. The destination qemu instance throws a SSL error:
(/usr/libexec/qemu-kvm:16261): Spice-Warning **: reds.c:2800:reds_handle_ssl_accept: SSL_accept failed, error=5.
Interesting thing is that migration when remote-viewer is connect through xpi plugin or calling remote-viewer from cli with command line options works correctly.
It has undesired impact for RHEVM users using native-client launch for remote-viewer since migration falls back to SWITCH HOST mode with all the disadvantages which this mode has.

Version-Release number of selected component (if applicable):
spice-gtk-0.20-9.el6.x86_64
virt-viewer-0.5.6-8.el6.x86_64
qemu-kvm-0.12.1.2-2.410
spice-server-0.12.4-3.el6.x86_64

How reproducible:
Always

Steps to Reproduce:
1. Connect to a qemu instance with SSL encryption using vv file.
2. Start destination qemu instance and send client_migrate_info to the client.

Actual results:
An error on destination qemu:
(/usr/libexec/qemu-kvm:16261): Spice-Warning **: reds.c:2800:reds_handle_ssl_accept: SSL_accept failed, error=5

Expected results:
Successful client_migrate_info:
main_channel_client_handle_migrate_connected: client 0x7f86659290f0 connected: 1 seamless 1

Additional info:
Sample of qemu cli:
SRC:
/usr/libexec/qemu-kvm -name 'virt-tests-vm1' -M pc -nodefaults -vga qxl -chardev socket,id=serial_id_serial1,path=/tmp/serial-serial1-20131023-015743-DxWUjdKZ,server,nowait -device isa-serial,chardev=serial_id_serial1 -chardev socket,id=seabioslog_id_20131023-015743-DxWUjdKZ,path=/tmp/seabios-20131023-015743-DxWUjdKZ,server,nowait -device isa-debugcon,chardev=seabioslog_id_20131023-015743-DxWUjdKZ,iobase=0x402 -device ich9-usb-uhci1,id=usb1 -drive id=drive_image1,if=none,cache=none,aio=native,file=/usr/local/autotest/client/tests/virt/shared/data/images/rhel6devel-64_client.qcow2 -device ide-drive,id=image1,drive=drive_image1 -m 1024 -smp 1,maxcpus=1,cores=1,threads=1,sockets=1 -cpu 'Nehalem' -drive aio=native,media=cdrom,file=/usr/local/autotest/client/tests/virt/shared/data/isos/linux/RHEL6-devel-x86_64.iso -drive aio=native,media=cdrom,file=/usr/local/autotest/client/tests/virt/shared/data/images/rhel6devel-64/ks.iso -device usb-tablet,id=usb-tablet1,bus=usb1.0,port=1 -kernel '/usr/local/autotest/client/tests/virt/shared/data/images/rhel6devel-64/vmlinuz' -append 'ks=cdrom nicdelay=60 console=ttyS0,115200 console=tty0' -initrd '/usr/local/autotest/client/tests/virt/shared/data/images/rhel6devel-64/initrd.img' -spice port=3000,password=12456,tls-port=3200,x509-dir=/tmp/spice_x509d,x509-key-password=testPassPhrase,tls-channel=main,tls-channel=inputs,seamless-migration=on,image-compression=auto_glz,jpeg-wan-compression=auto,zlib-glz-wan-compression=auto,streaming-video=filter,playback-compression=on -rtc base=utc,clock=host,driftfix=none -enable-kvm -monitor stdio
DST:
/usr/libexec/qemu-kvm -name 'virt-tests-vm1' -M pc -nodefaults -vga qxl -chardev socket,id=serial_id_serial1,path=/tmp/serial-serial1-20131023-015743-DxWUjdKZ,server,nowait -device isa-serial,chardev=serial_id_serial1 -chardev socket,id=seabioslog_id_20131023-015743-DxWUjdKZ,path=/tmp/seabios-20131023-015743-DxWUjdKZ,server,nowait -device isa-debugcon,chardev=seabioslog_id_20131023-015743-DxWUjdKZ,iobase=0x402 -device ich9-usb-uhci1,id=usb1 -drive id=drive_image1,if=none,cache=none,aio=native,file=/usr/local/autotest/client/tests/virt/shared/data/images/rhel6devel-64_client.qcow2 -device ide-drive,id=image1,drive=drive_image1 -m 1024 -smp 1,maxcpus=1,cores=1,threads=1,sockets=1 -cpu 'Nehalem' -drive aio=native,media=cdrom,file=/usr/local/autotest/client/tests/virt/shared/data/isos/linux/RHEL6-devel-x86_64.iso -drive aio=native,media=cdrom,file=/usr/local/autotest/client/tests/virt/shared/data/images/rhel6devel-64/ks.iso -device usb-tablet,id=usb-tablet1,bus=usb1.0,port=1 -kernel '/usr/local/autotest/client/tests/virt/shared/data/images/rhel6devel-64/vmlinuz' -append 'ks=cdrom nicdelay=60 console=ttyS0,115200 console=tty0' -initrd '/usr/local/autotest/client/tests/virt/shared/data/images/rhel6devel-64/initrd.img' -spice port=3001,password=12456,tls-port=3201,x509-dir=/tmp/spice_x509d,x509-key-password=testPassPhrase,tls-channel=main,tls-channel=inputs,seamless-migration=on,image-compression=auto_glz,jpeg-wan-compression=auto,zlib-glz-wan-compression=auto,streaming-video=filter,playback-compression=on -rtc base=utc,clock=host,driftfix=none -enable-kvm -monitor stdio -incoming tcp:127.0.0.1:5200

vv file:
[virt-viewer]
type=spice
host=10.34.131.171
port=3000
password=12456
tls-port=3200
tls-ciphers=DEFAULT
host-subject=C=CZ,L=BRNO,O=SPICE,CN=10.34.131.171
ca=-----BEGIN CERTIFICATE-----\nMIICRjCCAa+gAwIBAgIJAL8c6+ZqtQPVMA0GCSqGSIb3DQEBBQUAMDwxCzAJBgNV\nBAYTAkNaMQ0wCwYDVQQHDARCUk5PMQ4wDAYDVQQKDAVTUElDRTEOMAwGA1UEAwwF\nbXkgQ0EwHhcNMTMxMDIzMDA1ODEwWhcNMTYxMDIyMDA1ODEwWjA8MQswCQYDVQQG\nEwJDWjENMAsGA1UEBwwEQlJOTzEOMAwGA1UECgwFU1BJQ0UxDjAMBgNVBAMMBW15\nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCz6LViyTX7lSmNDPBuR/rV\nqstSH/nFWhP3MDH35nDRsNmVV7hAynkK+waGVeI7BH1DHfMTfHNDhycubKWwz7cV\nnRRSxAdZQN7SM3zTZfEzoEeWyu1fDuqVNktFMwyPhB8M0EW9RexRWeckAoGfw9fM\nr5vMkgj+ISytDaOUK9rD4wIDAQABo1AwTjAdBgNVHQ4EFgQUrUlm/TY2zR+I++H1\nvtV2N1+TInowHwYDVR0jBBgwFoAUrUlm/TY2zR+I++H1vtV2N1+TInowDAYDVR0T\nBAUwAwEB/zANBgkqhkiG9w0BAQUFAAOBgQAQVQQvCqUgJIOEPvMZ3ESdMsELigjo\n2uXlBRIyuiC85PU/WkpfJ1UBrjDiXUySKz9YVvk8ewcRiA8bvIj+k82YuyCzOnG2\nSlxq0vAlRfnBuQPrA1cZ5QijKZp2TgFVuZ6HSqjTZhLv+wvWtScw86rGKkK8CJgp\nOQuTHTYUYmz6Lg==\n-----END CERTIFICATE-----\n

qemu monitor call:
client_migrate_info spice 10.34.131.171 3001 3201 "C=CZ,L=BRNO,O=SPICE,CN=10.34.131.171"

Comment 2 Marc-Andre Lureau 2013-10-26 14:25:22 UTC

Is the client receiving  a new ca-file when migrating with xpi?

Do you know if the servers share the same CA?

Could you get the log of G_MESSAGES_DEBUG=GSpiceController?

Comment 3 RHEL Program Management 2013-10-29 14:37:20 UTC

This request was not resolved in time for the current release.
Red Hat invites you to ask your support representative to
propose this request, if still desired, for consideration in
the next release of Red Hat Enterprise Linux.

Comment 4 Marian Krcmarik 2013-10-29 14:49:37 UTC

(In reply to Marc-Andre Lureau from comment #2)
> Is the client receiving  a new ca-file when migrating with xpi?
receiving from where? from portal? I do not think so.
> 
> Do you know if the servers share the same CA?
Yes, They do.
> 
> Could you get the log of G_MESSAGES_DEBUG=GSpiceController?
I do not know how can that help, probably I could, but nothing happens in the log when migrating a VM which was connected through xpi.

Comment 5 Marc-Andre Lureau 2013-10-29 14:57:18 UTC

Ok, I guess that was fixed a while ago with..

commit 647344fa7513ef3c428cfbc4fc841d8bf29a0310
Author: Marc-André Lureau <marcandre.lureau>
Date:   Mon Jul 22 15:07:55 2013 +0200

    session: copy "ca" property in copy ctor
    
    This fixes the GSpice-WARNING **: no cert loaded, when doing a seamless
    migration (when using the "ca" property).

Comment 6 Marian Krcmarik 2013-10-29 14:59:55 UTC

(In reply to Marc-Andre Lureau from comment #5)
> Ok, I guess that was fixed a while ago with..
> 
> commit 647344fa7513ef3c428cfbc4fc841d8bf29a0310
> Author: Marc-André Lureau <marcandre.lureau>
> Date:   Mon Jul 22 15:07:55 2013 +0200
> 
>     session: copy "ca" property in copy ctor
>     
>     This fixes the GSpice-WARNING **: no cert loaded, when doing a seamless
>     migration (when using the "ca" property).

Why didn't it get into any build? you probably fixed it like 3 months ago?

Comment 7 Marc-Andre Lureau 2013-10-29 17:57:11 UTC

(In reply to Marian Krcmarik from comment #6)
> >     This fixes the GSpice-WARNING **: no cert loaded, when doing a seamless
> >     migration (when using the "ca" property).
> 
> Why didn't it get into any build? you probably fixed it like 3 months ago?

No idea, I guess I thought that was just a minor warning.

Comment 8 Michal Skrivanek 2013-11-11 08:30:01 UTC

will the fix take care of https://bugzilla.redhat.com/show_bug.cgi?id=1026474#c6 ?
We cannot differentiate between disconnect and "hand over with a delay"

Comment 9 Marc-Andre Lureau 2013-11-11 12:33:18 UTC

(In reply to Michal Skrivanek from comment #8)
> will the fix take care of
> https://bugzilla.redhat.com/show_bug.cgi?id=1026474#c6 ?
> We cannot differentiate between disconnect and "hand over with a delay"

That's what I understand from David comment. I do not understand what's happening in guest in bug 1026474, but I read "switch host" method will cause an additional delay that triggers desktop lock-in.

Comment 13 errata-xmlrpc 2014-10-14 06:46:34 UTC

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHBA-2014-1487.html

Note You need to log in before you can comment on or make changes to this bug.