Hide Forgot
Description of problem: The qemu-kvm man page shows, that supported tls-channels are: tls-channel=[main|display|inputs|record|playback|tunnel] But if the tls-channel=tunnel is supplied, it fails with: spice: failed to set channel security for tunnel Moreover, if tls-channel=cursor (legacy?) is supplied, it doesn't fail, although it is not specified in the man page. Version-Release number of selected component (if applicable): $ rpm -q qemu-kvm qemu-kvm-0.12.1.2-2.150.el6.x86_64 How reproducible: 100% Steps to Reproduce: $ /usr/libexec/qemu-kvm -spice tls-port=3001,tls-channel=cursor,tls-channel=tunnel (this is not the actual nor correct usage of the options, but the minimal set to reproduce the issue) Actual results: spice: failed to set channel security for tunnel Expected results: The man page should not list tunnel channel and should list cursor channel instead?
More man page errors: in man page: "-soundhw hda" -> that is not the correct way of adding the intel hda sound card this works: "-device intel-hda,id=sound0,bus=pci.0,addr=0x5 -device hda-duplex"
regarding comment #1 - cursor is not legacy, tunnel is compiled out in our spec, and we also support a smartcard channel now which is also not mentioned. I'm not sure how to proceed, because it seems the correct fix is to have a qemu.1.template and build the full one based on compile time options (maybe can be done with qemu.1.in, I'm not familiar enough with autotools to know, but I guess it can). So I'll take this upstream. Alon
Moving to 6.3
upstream commit d70d6b31091ab522ce793a52559e3dd9f9913b32 .
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. Boot guest /usr/libexec/qemu-kvm -cpu cpu64-rhel6,+x2apic,family=0xf -rtc base=localtime,clock=host,driftfix=slew -M rhel6.2.0 -enable-kvm -name win7_x64 -smp 2 -m 2G -uuid bd85c229-6384-446d-bedd-c111008ecfce -boot menu=on -drive file=/nfs/win7sp1.qcow2,if=none,id=drive-virtio-disk0,format=qcow2,cache=none,aio=native,media=disk,werror=stop,rerror=stop -device virtio-blk-pci,drive=drive-virtio-disk0,id=virtio-blk-pci0,bootindex=1 -netdev tap,id=hostnet0,vhost=on,script=/etc/qemu-ifup -device virtio-net-pci,netdev=hostnet0,id=net0,mac=44:37:E6:5E:A3:F7 -spice port=9000,disable-ticketing,tls-channel=cursor,tls-port=3001,tls-channel=tunnel -balloon none -monitor stdio -usb -device usb-tablet,id=input1 spice: failed to set channel security for tunnel 2. On host ,check man manual # man qemu-kvm -----we can find tls-port=<nr> Set the TCP port spice is listening on for encrypted channels. tls-channel=[main|display|inputs|record|playback|tunnel] Verified this issue with steps and environment as follows: # uname -r;rpm -q qemu-kvm 2.6.32-251.el6.x86_64 qemu-kvm-0.12.1.2-2.255.el6.x86_64 1. boot guest /usr/libexec/qemu-kvm -cpu cpu64-rhel6,+x2apic,family=0xf -rtc base=localtime,clock=host,driftfix=slew -M rhel6.2.0 -enable-kvm -name win7_x64 -smp 2 -m 2G -uuid bd85c229-6384-446d-bedd-c111008ecfce -boot menu=on -drive file=/nfs/win7sp1.qcow2,if=none,id=drive-virtio-disk0,format=qcow2,cache=none,aio=native,media=disk,werror=stop,rerror=stop -device virtio-blk-pci,drive=drive-virtio-disk0,id=virtio-blk-pci0,bootindex=1 -netdev tap,id=hostnet0,vhost=on,script=/etc/qemu-ifup -device virtio-net-pci,netdev=hostnet0,id=net0,mac=44:37:E6:5E:A3:F7 -spice port=9000,disable-ticketing,tls-channel=cursor,tls-port=3001,tls-channel=main,tls-channel=display,tls-channel=inputs,tls-channel=record,tls-channel=playback -balloon none -monitor stdio -usb -device usb-tablet,id=input1 (qemu) info spice Server: address: 0.0.0.0:9000 address: 0.0.0.0:3001 [tls] auth: none Channels: none 2. On host ,check man manual # man qemu-kvm -----we can find tls-channel=[main|display|cursor|inputs|record|playback] So,this bug had been fixed.
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: No Documentation Needed
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