Bug 790421

Summary: exit with error when tls-port is not specified but tls is enabled by tls-channel or x509* options
Product: Red Hat Enterprise Linux 6 Reporter: David Jaša <djasa>
Component: qemu-kvmAssignee: Christophe Fergeau <cfergeau>
Status: CLOSED ERRATA QA Contact: Virtualization Bugs <virt-bugs>
Severity: high Docs Contact:
Priority: high    
Version: 6.3CC: acathrow, bsarathy, cfergeau, dblechte, desktop-qa-list, ehabkost, juzhang, minovotn, mkenneth, mkrcmari, virt-maint, wdai
Target Milestone: beta   
Target Release: 6.3   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: qemu-kvm-0.12.1.2-2.261.el6 Doc Type: Bug Fix
Doc Text:
Cause: it's possible to specify SPICE TLS channels on qemu command line without specifying a TLS port for SPICE to use Consequence: when qemu is started this way, it's not possible to connect to the VM using SPICE Result: qemu now exits with an error in this situation
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-06-20 11:43:28 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
my take on this none

Description David Jaša 2012-02-14 13:42:02 UTC
Description of problem:
SSIA. 

Version-Release number of selected component (if applicable):
qemu-kvm-0.12.1.2-2.222.el6.x86_64
spice-server-0.10.1-1.el6.x86_64

How reproducible:
always

Steps to Reproduce:
run all of these (<dir> and <file> are pointing to valid SSL certs/keys):
qemu-kvm -spice port=<port>,tls-channel=main,tls-channel=inputs
qemu-kvm -spice port=5900,x509-dir=<dir>
qemu-kvm -spice port=5900,x509-cert-file=<file>,x509-cacert-file=<file>,x509-key-file=<file>
  
Actual results:
qemu-kvm happily runs

Expected results:
qemu-kvm should exit with non-zero error code and message like "spice: SSL/TLS options set but no tls-port specified"

Additional info:
High/High Priority/Severity set because this bug hides bugs that are in other components (RHEV/oVirt)

Comment 1 Christophe Fergeau 2012-02-14 17:32:30 UTC
Created attachment 561980 [details]
my take on this

Comment 2 Alon Levy 2012-02-14 21:12:03 UTC
Great, take it! :)

Comment 4 Christophe Fergeau 2012-02-24 16:30:36 UTC
I've sent the patch upstream for review, but it's a qemu patch, I assume this should be moved to a different component?

Comment 5 Alon Levy 2012-02-26 09:56:00 UTC
Christophe, thanks a lot. I'm moving the bug to you, switching component like you suggested, note that it will require regetting acks, and moving to POST. The patch is slated for next pull by Gerd:

 http://patchwork.ozlabs.org/patch/142956/

Alon

Comment 8 Christophe Fergeau 2012-03-22 09:59:53 UTC
It has now been sent to rhvirt-patches, thanks for the reminder.

Comment 11 daiwei 2012-04-05 07:44:43 UTC
Reproduced this issue with steps and environment as follows: 
# uname -r;rpm -q qemu-kvm
2.6.32-220.el6.x86_64
qemu-kvm-0.12.1.2-2.209.el6.x86_64

1.run all of these
/usr/libexec/qemu-kvm -spice port=5900,tls-channel=main,tls-channel=inputs
/usr/libexec/qemu-kvm -spice port=5900,x509-dir=/home/spice_x509-Pa5
/usr/libexec/qemu-kvm -spice port=5900,x509-cert-file=/home/spice_x509-a5/server-cert.pem,x509-cacert-file=/home/spice_x509-Pa5/ca-cert.pem,x509-key-file=/home/spice_x509-Pa5/server-key.pem

qemu-kvm happily runs

Verified this issue with steps and environment as follows: 
# uname -r;rpm -q qemu-kvm
 2.6.32-220.el6.x86_64
 qemu-kvm-0.12.1.2-2.269.el6.x86_64

redo above steps :

1. /usr/libexec/qemu-kvm -spice port=5900,tls-channel=main,tls-channel=inputs

qemu reports:
qemu-kvm: spice: tried to setup tls-channel without specifying a TLS port
Program exited with code 01.

2. /usr/libexec/qemu-kvm -spice port=5900,x509-dir=/home/spice_x509-Pa5

qemu-kvm happily runs

3. /usr/libexec/qemu-kvm -spice port=5900,x509-cert-file=/home/spice_x509-a5/server-cert.pem,x509-cacert-file=/home/spice_x509-Pa5/ca-cert.pem,x509-key-file=/home/spice_x509-Pa5/server-key.pem

qemu-kvm happily runs


Hi Christophe,

Is this consistent with the expected results ?

daiwei

Comment 12 David Jaša 2012-04-05 07:54:31 UTC
Hi Wei, please could you look if qemu-kvm opens only plaintext port in 2. and 3. and if you can connect to it with a client? If yes (spice console is accessible as a result), then you can mark it as verified.

Comment 13 daiwei 2012-04-05 13:44:57 UTC
Verified this issue with steps and environment as follows: 
# uname -r;rpm -q qemu-kvm
 2.6.32-220.el6.x86_64
 qemu-kvm-0.12.1.2-2.269.el6.x86_64

redo step 2 and step 3

2. /usr/libexec/qemu-kvm -spice port=5900,disable-ticketing,x509-dir=/home/spice_x509-Pa5 -monitor stdio 
 
With "spicec -h host_ip -p 5900" spice console is accessible


3. /usr/libexec/qemu-kvm -spice port=5900,disable-ticketing,x509-cert-file=/home/spice_x509-a5/server-cert.pem,x509-cacert-file=/home/spice_x509-Pa5/ca-cert.pem,x509-key-file=/home/spice_x509-Pa5/server-key.pem -monitor stdio

With "spicec -h host_ip -p 5900" spice console is accessible

According to Comment12, this issue has been fixed.

Comment 16 Michal Novotny 2012-05-04 12:29:49 UTC
    Technical note added. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    New Contents:
NEEDINFO

Comment 17 Christophe Fergeau 2012-05-04 12:46:54 UTC
    Technical note updated. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    Diffed Contents:
@@ -1 +1,5 @@
-NEEDINFO+Cause: it's possible to specify SPICE TLS channels on qemu command line without specifying a TLS port for SPICE to use
+
+Consequence: when qemu is started this way, it's not possible to connect to the VM using SPICE
+
+Result: qemu now exits with an error in this situation

Comment 18 errata-xmlrpc 2012-06-20 11:43:28 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-2012-0746.html