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

From: "Alon Levy" <alevy(a)redhat.com&gt; To: "Oved Ourfalli" <ovedo(a)redhat.com&gt; Cc: "David Jaša" <djasa(a)redhat.com&gt;, spice-devel(a)lists.freedesktop.org, dlaor(a)redhat.com, engine-devel(a)ovirt.org Sent: Wednesday, February 15, 2012 2:51:47 PM Subject: Re: [Engine-devel] [Spice-devel] SPICE related features On Wed, Feb 15, 2012 at 06:25:37AM -0500, Oved Ourfalli wrote: > > > ----- Original Message ----- > > From: "Dor Laor" <dlaor(a)redhat.com&gt; > > To: spice-devel(a)lists.freedesktop.org, engine-devel(a)ovirt.org > > Cc: "David Jaša" <djasa(a)redhat.com&gt;, "Oved Ourfalli" > > <ovedo(a)redhat.com&gt;, "Hans de Goede" <hdegoede(a)redhat.com&gt; > > Sent: Wednesday, February 15, 2012 12:52:46 PM > > Subject: Re: [Engine-devel] [Spice-devel] SPICE related features > > > > On 02/09/2012 02:50 PM, David Jaša wrote: > > > Itamar Heim píše v Čt 09. 02. 2012 v 11:07 +0200: > > >> 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". > > > > > > I think that some history-watching logic& one UI bit could be > > > the > > > way > > > to go. The UI bit would be yet another select button that would > > > let > > > user > > > choose what graphic layout ("all monitors on single graphic > > > card", > > > "one > > > graphic card per monitor (legacy)"). The logic would be like > > > this: > > > * pre-existing guest that now supports new layout in 3.1 > > > cluster > > > * The guest uses 1 monitor, is swithed to 2+ --> > > > new > > > * The guest uses 2+ monitor layout --> old, big > > > fat > > > warning when changing to the new that user > > > should > > > wipe > > > xinerama configuration in the guest > > > * pre-existing guest in old or mixed cluster: > > > * guest uses 2+ monitors --> old > > > * guest is newly configured for 2+ monitors --> > > > show > > > warning that user either has co configure > > > xinerama > > > or > > > use newer cluster --> old > > > * new guest in new cluster: > > > * --> new > > > * if user switches to old, show warning > > > * old guest in any type of cluster > > > * --> old > > > > > > This kind of behavior should provide sensible defaults, all > > > valid > > > choices in all possible scenarios and it should not interfere > > > too > > > much > > > when admin chooses to do anything. > > > > In short, the same rule of the thumb applies to all of our > > virtual > > hardware: > > - new vm creation should use the greatest and latest virtual > > hardware > > version (if the current cluster allows it) > > - For existing VMs we should preserve their current virtual > > hardware > > set (-M flag in qemu machine type vocabulary, cluster > > terminology > > for ovirt). > > - Changing the virtual hardware by either changing existing > > devices, > > adding devices, changing pci slots, or changing the virtual > > hardware revision should done only by user consent. > > The later may have the exception of smart offline v2v tool. > > > > Dor > > > > I agree. > What I don't understand (not a question for you Dor, but more for > the SPICE guys), though, is the requirement to support Xinerama > configuration on the guest. > Today the ovirt-engine doesn't support using more than one monitor > on Linux guests. Why? With Xinerama support we have a solution for this. That's the reason for asking for more the one monitor support for linux guests, no?

> If someone did something with is not the standard, somewhere behind > the scenes, the engine cannot be aware of that, thus it cannot > take it into consideration. > Moreover, don't change the device layout when we add support, as > the guest had one display device with one head, and it will remain > that way, unless he chooses to work with multiple monitors through > the engine management system. > > > > > > > David > > > > > >> ______________________________________ > > >> _________ > > >> Engine-devel mailing list > > >> Engine-devel(a)ovirt.org > > >> http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > > > > _______________________________________________ > > Engine-devel mailing list > > Engine-devel(a)ovirt.org > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > _______________________________________________ > Spice-devel mailing list > Spice-devel(a)lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/spice-devel _______________________________________________ Engine-devel mailing list Engine-devel(a)ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel