Hide Forgot
Description of problem: RHEL guest setup with 1 display, the client can set up to 4 displays. I assume it has to do with a recent change in RHEL 6.5 where only one qxl driver is needed to support multimonitor for RHEL guests; however, this brings up other issues: What's the point of setting up the number of monitors for the admin of RHEVM? There have been some other side effects too. I believe this is the root cause of other issues seen: a. When testing with multiple monitors on the client, I have seen the display of the VM come up on one screen, and then when selecting full screen it would switch to the other client's monitor. b. I tried to bring up one display in full screen, qxl would not set the resolution correctly and there were black bars. After looking at the Displays 1 and 2 were both active, but the 2nd couldn't be seen. c. In a RHEL 7 VM, all 4 displays are initially active, the user can select the 2nd one which never gets displayed and then displays 2->4 are grayed out and can no longer been displayed. d. there have been other issues too Version-Release number of selected component (if applicable): RHEVM is24.2 Guest: RHEL 6.5 64bit rhevm-guest-agent-common-1.0.8-6.el6ev xorg-x11-drv-qxl-0.1.0-7.el6 Client: RHEL 6.5 32bit Virt-Viewer 0.5.6 spice-xpi-2.7-24.el6.i686 or Windows client How reproducible: 100% Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
can you describe one single flow you are doing and what is the problem you see? so we can focus on the problem and understand the issue what settings did you use and what did you expect (number of monitors set to the vm and number of physical monitors you are using, versions you are using..)
The basic flow/scenario: Admin wants to set a basic RHEL VM for a user: VM is set to use spice and 1 monitor Client: Starts using the VM. Expected from Client: Client only has access to one display on the VM. No options from virt-viewer: View->Displays, just showing Display 1 selected Actual from Client: The client has access 4 displays on the VM. The client can add more displays from virt-viewer: View->Displays-> (Display 1, Display 2, Display 3, Display 4) If this was a Windows VM it would work as expected: Same scenario described as above just replacing RHEL VM with Windows 7 VM. The client has access to one display on the VM. No options from virt-viewer: View->Displays, just showing Display 1 selected.
thanks, now its clear. can you please attach relevant engine.log and vdsm.log of starting these vms? (the 'good' windows run and the problematic linux one)
I'm not sure where the engine.log is, and the vdsm.log files are really big, as we do use a lot of VMs. The issue can clearly be seen with the following: RHEL 6.5 VM setup with 1 monitor, defined as: usr/libexec/qemu-kvm -name RHEL6.5 ... -vga qxl -global qxl-vga.ram_size=67108864 -global qxl-vga.vram_size=33554432 ... RHEL 6.5 VM setup with 4 monitors, defined as: usr/libexec/qemu-kvm -name RHEL6.5 ... -vga qxl -global qxl-vga.ram_size=268435456 -global qxl-vga.vram_size=33554432 ... The above was changed recently, previously, you needed to define multiple qxl devices/per monitor. Windows 7 VM setup with 1 monitor, defined as: /usr/libexec/qemu-kvm -name Windows7 ... -vga qxl -global qxl-vga.ram_size=67108864 -global qxl-vga.vram_size=33554432 ... Windows 7 VM setup with 4 monitors, defined as: /usr/libexec/qemu-kvm -name Windows7 ... -vga qxl -global qxl-vga.ram_size=67108864 -global qxl-vga.vram_size=33554432 -device qxl,id=video1,ram_size=67108864,vram_size=33554432,bus=pci.0,addr=0x8 -device qxl,id=video2,ram_size=67108864,vram_size=33554432,bus=pci.0,addr=0x9 -device qxl,id=video3,ram_size=67108864,vram_size=33554432,bus=pci.0,addr=0xa (4 defined qxl devices) While RHEVM does seem to be doing the right thing, the issue is right now there is no way an Admin can define a RHEL 6.5 VM with 1 monitor, and this also brings about other issues as mentioned in the original bug description. Let me know if other logs are needed.
please attach logs since i cannot reproduce this, tried rhel6.5 with guest agent and without. the relevant logs are the part include the starting of the vm, vdsm + engine. engine log is usually at /var/log/ovirt-engine/engine.log
Created attachment 837388 [details] vdsm.log
Created attachment 837390 [details] RHEL6.5.log
I attached the log files. Steps to reproduce: For the guest 1. Admin sets up the RHEL VM with 1 monitor/display 2. shouldn't matter if guest agent is installed or not, but probably should be 3. xorg-x11-drv-qxl installed on guest (verify that the /etc/X11/xorg.conf has qxl listed as the video driver, if not delete the file and qxl, will automatically be chosen). Expected: Client doesn't have the option in View->Displays-> to add display 2,3,4 and they should not be listed. Actual: client does have the option in View->Displays-> to add display 2,3,4, and they are listed.
There is nothing much to do on the RHEVM side (or nothing straightforward). The problem is that we have different design of multimonitor for Windows VMs and different for Linux VMs. Windows multimonitor - each guest (VM) display is represented by QXL emulated graphic device and Windows QXL graphic driver is installed for each such display device (Exactly like having multiple hardware graphic cards), Windows guests can see multiple devices so there is no need for QXL driver to get involved in multimonitor since it is installed per each device. So RHEVM for Windows guests has to emulate one QXL device for each desired guest display -> you do not have QXL device emulated you will not get guest display. Linux multimonitor - I am not sure about implementation details but Linux native multimonitor is handled by QXL driver, Spice guest agent and xrandr themselves on the guest because X server is not that skillful in handling multiple graphics devices as Windows (we had to use Xorg extension Xinerama to handle multiple graphic devices which is not really user friendly (requires customized xorg.conf since xrandr does not work with xinerama)). So only one QXL device should be emulated for Linux guests and QXL driver/spice guest agent/xrandr will take care of multimonitor themselves on the guest. The problem is that having for example 4 displays on the Linux guest would require more memory assigned to QXL device to keep primary surface and all the QXL commands as It is needed for only one guest display, so what RHEVM currently does is that when a user chooses 4 monitors to have on Linux guest in RHEVM, RHEVM assigns more memory to the QXL device. But If a user chooses only one monitor in RHEVM for Linux guest, there is no way how to prevent user to enable more displays on the Linux guest since It is managed on the guest itself and lack of memory may cause all the weird behaviour. We could always assign let's say 256MB to the QXL device which is enough for 4 displays but the problem is that this memory is always allocated and since 4 monitors linux guests is not so significant use case It may be wasting of memory. I have no idea how to solve that I assume there is no way how to let spice guest agent knows how many displays It should let a user enable the most.
When I pick "Edit virtual machine" in RHEV 3.3, I see Monitors: [1] [x] Single PCI I guess we should disable the number of monitors selector when Single PCI is enabled as on linux you'll always get 4 monitors, and on Windows, I think you'll only get 1 with single pci (?). With that said, single pci+number of monitors+linux could maybe be used to size the amount of VRAM for the guest? (assuming this is not a compile-time setting). Also, an RFE to add a way for RHEV to configure the number of available heads in the guest in the single PCI case would make sense if you think that's useful. oVirt already sets <video><model heads="x"/></video> in libvirt xml, but it seems that libvirt is not doing much with it
(In reply to Christophe Fergeau from comment #11) Indeed the setting does set the amount of VRAM even on Linux. So virt-viewer just defaults to 4 monitors regardless the size or anything at the moment?
(In reply to Michal Skrivanek from comment #12) > So virt-viewer just defaults to 4 monitors regardless the size or anything > at the moment? On Linux with a single PCI device and when arbitrary resolution is supported by the guest, I think it does.
we'd need virt-viewer to support a configuration of max number of monitors
(In reply to Christophe Fergeau from comment #13) > (In reply to Michal Skrivanek from comment #12) > > So virt-viewer just defaults to 4 monitors regardless the size or anything > > at the moment? > > On Linux with a single PCI device and when arbitrary resolution is supported > by the guest, I think it does. I take that back, in single PCI device setups, you can pass the qxl.num_heads=xx on the kernel command line. I'm not sure this is something RHEV can easily pass to VMs though.
(In reply to Christophe Fergeau from comment #15) > (In reply to Christophe Fergeau from comment #13) > > (In reply to Michal Skrivanek from comment #12) > > > So virt-viewer just defaults to 4 monitors regardless the size or anything > > > at the moment? > > > > On Linux with a single PCI device and when arbitrary resolution is supported > > by the guest, I think it does. > > I take that back, in single PCI device setups, you can pass the > qxl.num_heads=xx on the kernel command line. I'm not sure this is something > RHEV can easily pass to VMs though. This is a pretty recent option (RHEL7/F20 with drm driver). On RHEL6 / xf86-qxl driver, you can configure: # The number of heads to allocate by default # defaults to 4 #Option "NumHeads" "4" For Windows, it depends on the number of video devices. With all that, I think that should close the bug. I would open a different RFE bug for later, to add an option to qemu qxl device to take num_heads and pass this value to the driver via the ROM (just like guestdebug, nsurfaces...) .
why is severity high, in the first place?
And this is probably a spice-server bug, not virt-viewer.
(In reply to Christophe Fergeau from comment #19) > And this is probably a spice-server bug, not virt-viewer. well, I think the following changes will be needed: - (new num_heads field in spice-protocol QXLRom) - qemu num_heads option for qxl device (bump revision etc) - libvirt to pass the num_heads config to qemu - kernel/drm to read rom value - eventually, xf86-qxl to read it too - eventually, ovirt to use num_heads for Linux guests? I don't think the spice-server will be involved, and the current client should work without any change. Ok, let's file this rfe
*** This bug has been marked as a duplicate of bug 1075798 ***