[Engine-devel] [Spice-devel] SPICE related features

Itamar Heim iheim at redhat.com
Thu Feb 9 09:07:20 UTC 2012


On 02/09/2012 11:05 AM, Hans de Goede wrote:
> Hi,
>
> On 02/09/2012 09:33 AM, Itamar Heim wrote:
>> On 02/09/2012 10:31 AM, Hans de Goede wrote:
>
> <snip>
>
>>>> 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.
>>
>> this is the ovirt mailing list, so upstream versions are more relevant
>> here.
>> in any case, I have the same issue with backward compatibilty.
>> say you fix this in fedora 17.
>> user started a guest VM when host was fedora 16.
>> admin upgraded host and changed cluster level to utilize new features.
>> suddenly on next boot guest will move from 4 heads to single head? I'm
>> guessing it will break user configuration.
>> i.e., user should be able to choose to move to utilize the new mode?
>
> I see this as something which gets decided at vm creation time, and then
> stored in the vm config. So if the vm gets created with a guest OS which
> does not support multiple monitors per qxl device, or when the cluster does
> not support it, it uses the old setup with 1 card / monitor. Even if the
> guest OS or the cluster gets upgraded later.

so instead of letting user change this, we'd force this at vm creation 
time? I'm not sure this is "friendlier".



More information about the Devel mailing list