Hi,
On 02/09/2012 08:55 AM, Itamar Heim wrote:
On 02/08/2012 04:36 PM, Hans de Goede wrote:
> Hi all,
>
> Dor, thanks for the forward.
>
> On 02/08/2012 12:49 PM, Dor Laor wrote:
>> On 02/08/2012 01:43 PM, Oved Ourfalli wrote:
>>> Hello all,
>>>
>>> The following feature page describes the engine adjustments needed
>>> for new SPICE features.
>>>
>>>
http://www.ovirt.org/wiki/Features/SPICERelatedFeatures
>
> Al in all this looks good, some remarks:
>
> * WRT multi monitor support for RHEL, the latest RHEL xorg-x11-drv-qxl and
> spice-vdagent packages do support multi monitor support using multiple
> cards in Xinerama mode. We are waiting for a RHEL-6 z-stream update to
> fix an x11-xorg-server-Xorg bug which atm makes the mouse unusable in this
> mode wants this lands, multi-monitor support this way should be available
> for RHEL-6.2 (and later) guests. The same holds true for Fedora guests,
> although I don't expect the necessary Xorg changes to be available for
> versions older then Fedora 17. The driving multiple monitors from a single
> qxl device support OTOH is still a long time away, likely 6 months or so.
so this means we need to ask the user for linux guests if they want single head or
multiple heads when they choose multi monitor?
We could ask the user, but I don't think that that is a good idea.
this will cause their (single) head to spin...
With which you seem to agree :)
any better UX we can suggest users?
Yes, no UI at all, the current solution using multiple single monitor
pci cards means using Xinerama, which disables Xrandr, and thus allows
no dynamic adjustment of the monitor settings of the guest, instead
an xorg.conf file must be written (the linux agent can generate one
based on the current client monitor info) and Xorg needs to be restarted.
This is the result of the multiple pci cards which each 1 monitor model
we've been using for windows guests being a poor match for Linux guests.
So we are working on adding support to drive multiple monitors from a
single qxl pci device. This requires changes on both the host and
guest side, but if both sides support it this configuration is much
better, so IMHO ovirt should just automatically enable it
if both the host (the cluster) and the guest support it.
On the guest side, this is the current status:
RHEL <= 6.1 no multi monitor support
RHEL 6.2(*) - 6.? multi monitor support using Xinerama (so 1 monitor/card, multiple
cards)
RHEL >= 6.? multi monitor support using a single card with multiple outputs
Just like when exactly the new multi mon support will be available
for guests, it is a similar question mark for when it will be available for
the host.
*) Note for 6.2 this requires a z-stream xorg server update.
> * WRT the native USB support, the wiki page says:
> "If the cluster level is 3.1 (which supports native USB support), but the
> client only has non-native USB support (old client), then we will use the
> old client. This means that we'll have to keep supporting the non-native
> USB
> support, side-by-side with the native one."
>
> Note that the new usb-support requires starting the guest with a number of
> extra emulated devices. These will just sit around and do nothing if
> unused,
> so I don't really expect any issues with this, but this still is something
> to be aware of. OTOH the old usb-support requires the installation of extra
> software inside the guest, if this is not installed falling back to the old
> client will not help wrt usb support.
true, I think we need to offer at least a single version that offers backward
compatibility before we can deprecate it.
Agreed.
Regards,
Hans