Bug 801443

Summary: Libvirt shouldn't fail on tlsPort setting if none set
Product: Red Hat Enterprise Linux 6 Reporter: Michal Privoznik <mprivozn>
Component: libvirtAssignee: Michal Privoznik <mprivozn>
Status: CLOSED ERRATA QA Contact: Virtualization Bugs <virt-bugs>
Severity: medium Docs Contact:
Priority: medium    
Version: 6.3CC: acathrow, cfergeau, dallan, desktop-qa-list, djasa, dyuan, eblake, mprivozn, mshao, mzhan, rwu, veillard, weizhan, whuang, zpeng
Target Milestone: beta   
Target Release: 6.3   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: libvirt-0.9.10-6.el6 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 790436 Environment:
Last Closed: 2012-06-20 06:49:50 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:
Bug Depends On: 790436    
Bug Blocks:    

Description Michal Privoznik 2012-03-08 14:45:34 UTC
+++ This bug was initially created as a clone of Bug #790436 +++

--- Additional comment from djasa on 2012-03-08 06:35:41 EST ---

Back to ASSIGNED, current check stops qemu even in case when 

$ grep -A2 'graphics type' rhel6.xml 
    <graphics type='spice' port='3005' autoport='no' listen='0.0.0.0'>
      <listen type='address' address='0.0.0.0'/>
    </graphics>
$ LANG= virsh domxml-to-native --format qemu-argv --xml rhel6.xml 
error: unsupported configuration: spice TLS port set in XML configuration, but TLS is disabled in qemu.conf

The behaviour is the same under root and libvirtd.log doesn't provide any insight even with debug = 1.

--- Additional comment from djasa on 2012-03-08 06:37:41 EST ---

Version information:
$ rpm -qa | grep 'libvirt*\|qemu-kvm*'
qemu-kvm-0.12.1.2-2.236.el6.x86_64
libvirt-0.9.10-3.el6.x86_64
qemu-kvm-debuginfo-0.12.1.2-2.236.el6.x86_64
qemu-kvm-tools-0.12.1.2-2.236.el6.x86_64
libvirt-python-0.9.10-3.el6.x86_64
libvirt-client-0.9.10-3.el6.x86_64

--- Additional comment from whuang on 2012-03-08 07:06:52 EST ---

If set autoport='no' and not set tlsPort in domain xml ,in this case the tlsPort is  automatic allocated , so it reports TLS error message.

--- Additional comment from djasa on 2012-03-08 07:21:19 EST ---

(In reply to comment #19)
> If set autoport='no' and not set tlsPort in domain xml ,in this case the
> tlsPort is  automatic allocated , so it reports TLS error message.

Hi Wenlong,

Is this behaviour documented somewhere? I can not find it in libvirt documentation and when writing the configuration with no mention of tlsPort, I would expect libvirt not to care about it.

--- Additional comment from whuang on 2012-03-08 07:30:56 EST ---

(In reply to comment #20)
> (In reply to comment #19)
> > If set autoport='no' and not set tlsPort in domain xml ,in this case the
> > tlsPort is  automatic allocated , so it reports TLS error message.
> 
> Hi Wenlong,
> 
> Is this behaviour documented somewhere? I can not find it in libvirt
> documentation and when writing the configuration with no mention of tlsPort, I
> would expect libvirt not to care about it.

Hi,David

Sorry ,I can not find document about this,you'd better needinfo developer of libvirt .

Wenlong

--- Additional comment from mprivozn on 2012-03-08 08:31:05 EST ---

I think this is clearly a bug;

From our parsing code:

src/conf/domain_conf.c:5992:        tlsPort = virXMLPropString(node, "tlsPort");
src/conf/domain_conf.c:5993:        if (tlsPort) {
src/conf/domain_conf.c:5994:            if (virStrToLong_i(tlsPort, NULL, 10, &def->data.spice.tlsPort) < 0) {
src/conf/domain_conf.c-5995-                virDomainReportError(VIR_ERR_INTERNAL_ERROR,
src/conf/domain_conf.c:5996:                                     _("cannot parse spice tlsPort %s"), tlsPort);
src/conf/domain_conf.c:5997:                VIR_FREE(tlsPort);
src/conf/domain_conf.c-5998-                goto error;
src/conf/domain_conf.c-5999-            }
src/conf/domain_conf.c:6000:            VIR_FREE(tlsPort);
src/conf/domain_conf.c-6001-        } else {
src/conf/domain_conf.c:6002:            def->data.spice.tlsPort = 0;
src/conf/domain_conf.c-6003-        }

However, if we build qemu command line we test tlsPort against -1:

src/qemu/qemu_command.c:5377:        if (def->graphics[0]->data.spice.tlsPort != -1) {
src/qemu/qemu_command.c-5378-            if (!driver->spiceTLS) {
src/qemu/qemu_command.c-5379-                qemuReportError(VIR_ERR_CONFIG_UNSUPPORTED,
src/qemu/qemu_command.c-5380-                                _("spice TLS port set in XML configuration,"
src/qemu/qemu_command.c-5381-                                  " but TLS is disabled in qemu.conf"));
src/qemu/qemu_command.c-5382-                goto error;
src/qemu/qemu_command.c-5383-            }
src/qemu/qemu_command.c-5384-            virBufferAsprintf(&opt, ",tls-port=%u",
src/qemu/qemu_command.c:5385:                              def->graphics[0]->data.spice.tlsPort);
src/qemu/qemu_command.c-5386-        }


I've proposed patch upstream:

https://www.redhat.com/archives/libvir-list/2012-March/msg00332.html

--- Additional comment from mprivozn on 2012-03-08 08:36:53 EST ---

Sorry for bad formatting. Maybe this time I've leaned Bugzilla gods onto my side:

From our parsing code:

tlsPort = virXMLPropString(node, "tlsPort");
if (tlsPort) {
    if (virStrToLong_i(tlsPort, NULL, 10, &def->data.spice.tlsPort) < 0) {
        virDomainReportError(VIR_ERR_INTERNAL_ERROR,
                             _("cannot parse spice tlsPort %s"), tlsPort);
        VIR_FREE(tlsPort);
        goto error;
    }
    VIR_FREE(tlsPort);
} else {
    def->data.spice.tlsPort = 0;
}

However, if we build qemu command line we test tlsPort against -1:

if (def->graphics[0]->data.spice.tlsPort != -1) {
    if (!driver->spiceTLS) {
        qemuReportError(VIR_ERR_CONFIG_UNSUPPORTED,
                        _("spice TLS port set in XML configuration,"
                          " but TLS is disabled in qemu.conf"));
        goto error;
    }
    virBufferAsprintf(&opt, ",tls-port=%u",
                      def->graphics[0]->data.spice.tlsPort);
}

Comment 5 Michal Privoznik 2012-03-14 08:28:11 UTC
Yeah, we need to backport another patch:

http://post-office.corp.redhat.com/archives/rhvirt-patches/2012-March/msg01265.html

Comment 6 zhe peng 2012-03-19 06:01:14 UTC
Verify on:
libvirt-0.9.10-6.el6.x86_64
qemu-kvm-0.12.1.2-2.241.el6.x86_64
kernel-2.6.32-244.el6.x86_64

try guest with xml:
<graphics type='spice' port='5900' autoport='no' listen='0.0.0.0'>
      <listen type='address' address='0.0.0.0'/>
    </graphics>
and 
 <graphics type='spice' autoport='yes' listen='0.0.0.0'>
      <listen type='address' address='0.0.0.0'/>
    </graphics>

the guests all can be started without error,use virt-viewer can connect the guest ,
verification passed.

Comment 8 errata-xmlrpc 2012-06-20 06:49:50 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/RHSA-2012-0748.html