Description of problem: When creating a VM with qemu-kvm and a bad_value is entered for the streaming-video option, the VM creation still works. However, the only acceptable values should be [off | all | filter], and if these aren't set, then VM creation should not occur and it should gracefully exit. Version-Release number of selected component (if applicable): spice-gtk-0.11-9.el6.x86_64 spice-usb-share-4.9-9.el6.x86_64 spice-server-0.10.1-10.el6.x86_64 spice-xpi-2.7-19.el6.x86_64 spice-gtk-python-0.11-9.el6.x86_64 spice-glib-0.11-9.el6.x86_64 spice-client-0.8.2-15.el6.x86_64 spice-vdagent-0.8.1-3.el6.x86_64 kmod-kspiceusb-rhel60-4.9-14.el6.x86_64 usbredir-0.4.3-1.el6.x86_64 qemu-kvm-0.12.1.2-2.292.el6.x86_64 kmod-kspiceusb-rhel60-4.9-14.el6.x86_64 xorg-x11-drv-qxl-0.0.14-13.el6_2.x86_64 virt-viewer-0.5.2-8.el6.x86_64 libvirt-client-0.9.10-18.el6.x86_64 libvirt-python-0.9.10-18.el6.x86_64 libvirt-0.9.10-18.el6.x86_64 How reproducible: 100% Steps to Reproduce: 1. Start VM creation using qemu-kvm, and set the streaming-video=bad_value (Actual cmd used: /usr/libexec/qemu-kvm -name 'vm1' -nodefaults -monitor unix:'/tmp/monitor-humanmonitor1-20120608-155203-bZeX',server,nowait -serial unix:'/tmp/serial-20120608-155203-bZeX',server,nowait -device ich9-usb-uhci1,id=usb1 -drive file='/tmp/kvm_autotest_root/images/rhel63-64.qcow2',index=0,if=ide,cache=none -device e1000,netdev=idRxxrhi,mac='9a:12:47:29:97:66',id='idjm0PxD' -netdev tap,id=idRxxrhi,fd=22 -m 1024 -smp 1 -device usb-tablet,id=usb-tablet1,bus=usb1.0 -spice port=3000,disable-ticketing,image-compression=auto_glz,jpeg-wan-compression=auto,zlib-glz-wan-compression=auto,streaming-video=bad_value,playback-compression=on -vga qxl) Actual results: VM Creation is successful Expected results: Graceful exit of the command. Additional info: Same behavior on 6.2 and 6.3
When using libvirt to start VMs, this problem would not happen. Currently, when a bad param is given to the -spice streaming-video option, it is ignored and the default ("filter") value is used. Looking at the code, I found that spice_server_set_streaming_video() (spice-server) does returns -1 on bad param. The calling function qemu_spice_init (qemu-kvm) does not check the return value. I'm not sure if using the default value on bad param done on purpose or not. If we want to fix this bug, the return value should be looked at, and if it's -1 (or <0) exit the program
From our testing, We found that an invalid value entered from streaming-video is the only spice value that lets the VM be launched instead of returning an error. For the other cases (image compression, wan compression, playback compression, bad port value), the VM does not get launched and returns an error.
Took me a while to understand why streaming-video was behaving differently from the other options, and actually I think this can be fixed with a simple one-line patch: diff --git a/ui/spice-core.c b/ui/spice-core.c index 4fc48f8..3eed1da 100644 --- a/ui/spice-core.c +++ b/ui/spice-core.c @@ -344,7 +344,7 @@ static const char *stream_video_names[] = { [ SPICE_STREAM_VIDEO_FILTER ] = "filter", }; #define parse_stream_video(_name) \ - name2enum(_name, stream_video_names, ARRAY_SIZE(stream_video_names)) + parse_name(_name, "stream video control", stream_video_names, ARRAY_SIZE(stream_video_names)) static const char *compression_names[] = { [ SPICE_IMAGE_COMPRESS_OFF ] = "off",
(In reply to comment #4) Yes, that should fix it.
Patch sent to qemu-devel, thanks for confirming the patch makes sense!
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: Before Fix: When a bad value was given for qemu-kvm command line "-spice" option "streaming-video", it was ignored. The default value was used and the VM was running. After Fix: When a bad value is given for qemu-kvm command line "-spice" option "streaming-video", an error message is shown and the program exits.
Reproduced with qemu-kvm-0.12.1.2-2.312.el6.x86_64, spice-server-0.10.1-10.el6.x86_64. Steps: 1. passing invalid value to streaming-video CLI: /usr/libexec/qemu-kvm -M rhel6.3.0 -enable-kvm -m 2048 -smp 4,sockets=2,cores=2,threads=1 -drive file=test.qcow2,if=none,id=drive-virtio-disk0,format=qcow2,serial=f82002eb-520c-469b-90c2-663277e90437,cache=none,werror=stop,rerror=stop,aio=native -device virtio-blk-pci,scsi=off,bus=pci.0,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 -netdev tap,id=hostnet0,vhost=on -device virtio-net-pci,netdev=hostnet0,id=net0,mac=00:1a:4a:42:0b:38,bus=pci.0 -k en-us -vga qxl -spice port=5900,disable-ticketing,image-compression=auto_glz,jpeg-wan-compression=auto,zlib-glz-wan-compression=auto,streaming-video=bad_value,playback-compression=on -monitor stdio ^^^^^^^^^ Actual Result: Guest successfully booted up instead of quitting on error. Did same tests on image-compression, jpeg-wan-compression, zlib-glz-wan-compression=auto, playback-compression=on. All caused qemu-kvm quitted on invalid error. Detail error info: 1. image-compression=bad_value spice: invalid image compression: bad_value 2. 2.1 jpeg-wan-compression=bad_value spice: invalid wan compression: bad_value 2.2 zlib-glz-wan-compression=bad_value spice: invalid wan compression: bad_value 3. playback-compression=bad_value qemu-kvm: -spice port=5900,disable-ticketing,image-compression=auto_glz,jpeg-wan-compression=auto,zlib-glz-wan-compression=auto,streaming-video=filter,playback-compression=bad_value: Parameter 'playback-compression' expects 'on' or 'off' parse error: port=5900,disable-ticketing,image-compression=auto_glz,jpeg-wan-compression=auto,zlib-glz-wan-compression=auto,streaming-video=filter,playback-compression=bad_value
Verified on: RHEL 6.3, using qemu-kvm-0.12.1.2-2.320.el6.x86_64, that qemu-kvm no longer allows the VM to be launched if an invalid value is set for streaming-video. It now exits and displays the error message: spice: invalid stream video control: <invalid value> Also verified that the 3 valid values of off, all, and filter work properly.
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-2013-0527.html