Description of problem: if port (tls-port) number is zero, treat it as no port number given. This gives unnecessary network roundtrips to migration when only secure port is used on the destination. Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 0. have a x509_DIR 1. run source qemu: qemu-kvm -monitor stdio -spice tls-port=SPORT1,x509_dir=DIR,disable-ticketing 2. run destination qemu: qemu-kvm -monitor stdio -spice tls-port=SPORT2,x509_dir=DIR,disable-ticketing 3. connect to the source qemu: remote-viewer --spice-ca-file DIR/ca-cert.pem spice://my-laptop.example.com/?tls-port=SPORT1 4. instruct source qemu to migrate the client with zero port: __com.redhat_spice_migrate_info my-laptop.example.com 0 SPORT2 "host subject" Actual results: spice-gtk tries to connect to port 0: channel-main.c:1717 migrate_begin 25 my-laptop.example.com 0 SPORT2 channel-main.c:1578 migrate_channel_connect 1:0 spice-channel.c:126 main-1:0: spice_channel_constructed spice-session.c:1628 new main channel, switching spice-channel.c:2255 Open coroutine starting 0x2103460 spice-channel.c:2098 Started background coroutine 0x21034e8 for main-1:0 spice-channel.c:2122 connection failed, trying with TLS port Expected results: spice-gtk skips port and goes to TLS port right away Additional info:
I don't think it attempts an non-SSL connection actually, the message comes from spice-channel.c: reconnect: c->sock = spice_session_channel_open_host(c->session, channel, c->tls); if (c->sock == NULL) { if (!c->tls) { CHANNEL_DEBUG(channel, "connection failed, trying with TLS port"); c->tls = true; /* FIXME: does that really work with provided fd */ goto reconnect; } else { CHANNEL_DEBUG(channel, "Connect error"); emit_main_context(channel, SPICE_CHANNEL_EVENT, SPICE_CHANNEL_ERROR_CONNECT); goto cleanup; } } The actual connection is done in spice_session_channel_open_host from spice-session.c which starts with if ((use_tls && !s->tls_port) || (!use_tls && !s->port)) return NULL; c->tls and use_tls are FALSE or "connection failed, trying with TLS port" wouldn't appear, and s->port is null as well, so NULL is returned before any connection is attempted.
sent to ML channel: improve debugging message The open_host() can return FALSE when the connection is discarded or skipped. Improve the message to not indicate a failure. https://bugzilla.redhat.com/show_bug.cgi?id=858232
in spice-gtk-0.14-5.el6
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-2013-0343.html