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

[Itamar Heim]

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".