On Mon, Mar 12, 2012 at 02:21:48PM +0100, Jiri Denemark wrote:
On Thu, Mar 08, 2012 at 14:30:05 +0100, Michal Privoznik wrote:
If user hasn't supplied any tlsPort we default to setting it to zero in our internal structure. However, when building command line we test it against -1 which is obviously wrong. --- src/qemu/qemu_command.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/src/qemu/qemu_command.c b/src/qemu/qemu_command.c index de2d4a1..ed82cc2 100644 --- a/src/qemu/qemu_command.c +++ b/src/qemu/qemu_command.c @@ -5374,7 +5374,7 @@ qemuBuildCommandLine(virConnectPtr conn,
virBufferAsprintf(&opt, "port=%u", def->graphics[0]->data.spice.port);
- if (def->graphics[0]->data.spice.tlsPort != -1) { + if (def->graphics[0]->data.spice.tlsPort) { if (!driver->spiceTLS) { qemuReportError(VIR_ERR_CONFIG_UNSUPPORTED, _("spice TLS port set in XML configuration,"
Oops, looks like this is a doomed feature. With this change in, a domain configured with
<graphics type='spice' autoport='yes'/>
fails to start with error: unsupported configuration: spice TLS port set in XML configuration, but TLS is disabled in qemu.conf
Apparently tlsPort may be both -1 and 0 depending on autoport value.
Hmm, that smells like a bug - something somewhere is not correctly initializing tlsPort to -1. Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|