Bug 953126 - <graphics type="spice" defaultMode="secure"/> should require spice_tls=1 and tlsPort to be set
<graphics type="spice" defaultMode="secure"/> should require spice_tls=1 and ...
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: libvirt (Show other bugs)
6.4
Unspecified Unspecified
low Severity unspecified
: beta
: ---
Assigned To: Martin Kletzander
Virtualization Bugs
: Upstream
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-04-17 08:21 EDT by David Jaša
Modified: 2016-04-26 11:15 EDT (History)
8 users (show)

See Also:
Fixed In Version: libvirt-0.10.2-34.el6
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2014-10-14 00:15:49 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description David Jaša 2013-04-17 08:21:01 EDT
Description of problem:
defaultMode="secure" means that:
  * tlsPort needs to be set unless the defaultMode is overriden by <channel name="CHANNEL" mode="insecure|any"/> for _every_ possible channel
  * if no <channel name="CHANNEL" mode="insecure|any"/> element is present, port doesn't have to be allocated at all

That in turn means that wehn defaultMode="secure" is set:
  * switch spice_tls of qemu.conf to 1 at least for the domain in question
    * fail to start the VM if prerequisites for spice_tls=1 are not met
  * always allocate tlsPort
  * allocate port only if some <channel name="..." mode="insecure|any"/> exists

Version-Release number of selected component (if applicable):
libvirt-0.10.2-18.el6_4.4.x86_64

How reproducible:
always

reproducer 1:
/etc/libvirt/qemu.conf: spice_tls = 1
domain xml contains: <graphics type="spice" defaultMode="secure"/>

results in: "-spice port=0,..."
should be: "-spice tls-port=<auto_allocated_port>"


reproducer 2:
/etc/libvirt/qemu.conf: spice_tls = 0
domain xml contains: <graphics type="spice" defaultMode="secure"/>

results in: "-spice port=0,..."
should be:
  * if prerequisites for spice_tls = 1 are met, flip spice_tls to 1
  * if not, refuse to start the VM


reproducer 3:
/etc/libvirt/qemu.conf: spice_tls = 1
domain xml contains:
<graphics type="spice" defaultMode="secure">
  <channel name="display" mode="insecure"/>
</graphics

should result in: "-spice port=PORT,tls-port=SPORT,..."
Comment 1 Peter Krempa 2013-04-24 09:56:44 EDT
Fixed upstream in v1.0.4-252-g20cb7f3 by: 

commit 20cb7f3a41daf8252d9a2109112fb59e0d42356d
Author: Peter Krempa <pkrempa@redhat.com>
Date:   Tue Apr 23 14:23:30 2013 +0200

    qemu: Improve handling of channels when generating SPICE command line
    
    Improve error reporting and generating of SPICE command line arguments
    according to the need to enable TLS. If TLS is disabled, there's no need
    to pass the certificate dir to qemu.
    
    This patch resolves:
    https://bugzilla.redhat.com/show_bug.cgi?id=953126

commit 7b4a6304846b020582dd0b978d20a184f3e15a60
Author: Peter Krempa <pkrempa@redhat.com>
Date:   Tue Apr 23 07:01:38 2013 +0200

    qemu: Do sensible auto allocation of SPICE port numbers
    
    With this patch, if the autoport attribute is used, the code will
    sensibly auto allocate the ports only if needed.


Moving to POST.
Comment 2 Geyang Kong 2013-05-13 03:07:37 EDT
I'm not sure if I missed something or I misunderstood this bug, but looks I didn't reproduce this with build: libvirt-0.10.2-18.el6_4.4.x86_64
List my steps here:

1. Run following script:
#!/bin/bash

SERVER_KEY=server-key.pem

# creating a key for our ca
if [ ! -e ca-key.pem ]; then
    openssl genrsa -des3 -out ca-key.pem 1024
fi
# creating a ca
if [ ! -e ca-cert.pem ]; then
    openssl req -new -x509 -days 1095 -key ca-key.pem -out ca-cert.pem  -subj "/C=IL/L=Raanana/O=Red Hat/CN=my CA"
fi
# create server key
if [ ! -e $SERVER_KEY ]; then
    openssl genrsa -out $SERVER_KEY 1024
fi
# create a certificate signing request (csr)
if [ ! -e server-key.csr ]; then
    openssl req -new -key $SERVER_KEY -out server-key.csr -subj "/C=IL/L=Raanana/O=Red Hat/CN=my server"
fi
# signing our server certificate with this ca
if [ ! -e server-cert.pem ]; then
    openssl x509 -req -days 1095 -in server-key.csr -CA ca-cert.pem -CAkey ca-key.pem -set_serial 01 -out server-cert.pem
fi

# now create a key that doesn't require a passphrase
openssl rsa -in $SERVER_KEY -out $SERVER_KEY.insecure
mv $SERVER_KEY $SERVER_KEY.secure
mv $SERVER_KEY.insecure $SERVER_KEY

# show the results (no other effect)
openssl rsa -noout -text -in $SERVER_KEY
openssl rsa -noout -text -in ca-key.pem
openssl req -noout -text -in server-key.csr
openssl x509 -noout -text -in server-cert.pem
openssl x509 -noout -text -in ca-cert.pem

# copy *.pem file to /etc/pki/libvirt-spice
if [[ -d "/etc/pki/libvirt-spice" ]]
then
    cp ./*.pem /etc/pki/libvirt-spice
else
    mkdir /etc/pki/libvirt-spice
        cp ./*.pem /etc/pki/libvirt-spice
fi

# echo --host-subject
echo "your --host-subject is" \" `openssl x509 -noout -text -in server-cert.pem | grep Subject: | cut -f 10- -d " "` \"

2. Prepare a spice guest.

reproducer 1:
3. /etc/libvirt/qemu.conf: spice_tls = 1 and restart libvirtd.
4. Edit Guest's XML: <graphics type='spice' autoport='yes' defaultMode='secure'/>
5. Start guest.
6. Run ps -aef |grep kvm
7. Got -spice port=5900,tls-port=5901 
---------------------I think this is same as reproducer 1.

reproducer 2:
3. /etc/libvirt/qemu.conf: spice_tls = 0 and restart libvirtd.
4. Edit Guest's XML: <graphics type='spice' autoport='yes' defaultMode='secure'/>
5. Start guest.
6. Hit following error:
[root@KP-T2 libvirt-spice]# virsh start T1
error: Failed to start domain T1
error: internal error Process exited while reading console log output: char device redirected to /dev/pts/2
neither port nor tls-port specified for spice.
---------------------According to reproducer 2 in description, I think this behavior is correct(* if not, refuse to start the VM).

reproducer 3:
3. /etc/libvirt/qemu.conf: spice_tls = 1 and restart libvirtd.
4. Edit Guest's XML:
    <graphics type='spice' autoport='yes' defaultMode='secure'>
      <channel name='display' mode='insecure'/>
    </graphics>
5. Start guest.
6. Run ps -aef | grep kvm
7. Got: -spice port=5900,tls-port=5901
---------------------According to reproducer 3 in description, I think this behavior is correct(should result in: "-spice port=PORT,tls-port=SPORT,...").

So can you provide some more details to reproduce this? Especially for reproducer 2, I cannot even start guest after adding defaultMode='secure' with spice_tls=0
Comment 3 Geyang Kong 2013-05-13 03:11:58 EDT
For reproducer 2, error message should be like following if I add autoport='yes':
[root@KP-T2 libvirt-spice]# virsh start T1
error: Failed to start domain T1
error: internal error Process exited while reading console log output: char device redirected to /dev/pts/2
qemu-kvm: spice: tried to setup tls-channel without specifying a TLS port

If without autoport='yes', error same as Comment2
Comment 4 David Jaša 2013-05-21 10:51:53 EDT
I think that every described result is correct, i.e. the domain is started with secure port or not started at all.

The reproducer 2 doesn't seem to be handled nicely in the libvirt but that makes no actual harm because the wrong state (domain requiring tls beings started without it) doesn't occur anymore.
Comment 15 zhe peng 2014-07-09 04:08:51 EDT
I can reproduce this with libvirt-0.10.2-18.el6_4.4.x86_64
verify with build:
libvirt-0.10.2-40.el6.x86_64

step(same with comment 2):
for reproducer 1:
#ps -ef | grep kvm
got result:
-spice tls-port=5900,addr=127.0.0.1

for reproducer 2:
# virsh start rhel6
error: Failed to start domain rhel6
error: unsupported configuration: Auto allocation of spice TLS port requested but spice TLS is disabled in qemu.conf

for reproducer 3:
#ps -ef | grep kvm
got result:
-spice port=5900,tls-port=5901,addr=127.0.0.1

move to verified.
Comment 17 errata-xmlrpc 2014-10-14 00:15:49 EDT
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-1374.html

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