RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 953126 - <graphics type="spice" defaultMode="secure"/> should require spice_tls=1 and tlsPort to be set
Summary: <graphics type="spice" defaultMode="secure"/> should require spice_tls=1 and ...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: libvirt
Version: 6.4
Hardware: Unspecified
OS: Unspecified
low
unspecified
Target Milestone: beta
: ---
Assignee: Martin Kletzander
QA Contact: Virtualization Bugs
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-04-17 12:21 UTC by David Jaša
Modified: 2016-04-26 15:15 UTC (History)
8 users (show)

Fixed In Version: libvirt-0.10.2-34.el6
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-10-14 04:15:49 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2014:1374 0 normal SHIPPED_LIVE libvirt bug fix and enhancement update 2014-10-14 08:11:54 UTC

Description David Jaša 2013-04-17 12:21:01 UTC
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 13:56:44 UTC
Fixed upstream in v1.0.4-252-g20cb7f3 by: 

commit 20cb7f3a41daf8252d9a2109112fb59e0d42356d
Author: Peter Krempa <pkrempa>
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>
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 07:07:37 UTC
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 07:11:58 UTC
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 14:51:53 UTC
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 08:08:51 UTC
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 04:15:49 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-1374.html


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