Oved Ourfalli píše v St 15. 02. 2012 v 08:06 -0500:
----- Original Message -----
From: "Alon Levy" <alevy@redhat.com> To: "Oved Ourfalli" <ovedo@redhat.com> Cc: "David Jaša" <djasa@redhat.com>, spice-devel@lists.freedesktop.org, dlaor@redhat.com, engine-devel@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@redhat.com> To: spice-devel@lists.freedesktop.org, engine-devel@ovirt.org Cc: "David Jaša" <djasa@redhat.com>, "Oved Ourfalli" <ovedo@redhat.com>, "Hans de Goede" <hdegoede@redhat.com> 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?
AFAIU there was no requirement for adding Xinerama support, but only supporting using multiple heads on a single device. If this is a requirement we should know about it, and design it. Either way, as both features are new we have no backward compatibility issue here.
No and no - if you take downstream RHEV into account. RHEV 3.0 _does_ support multimonitor linux guests using more single-headed devices which in turn require Xinerama configuration in guests. When such guests are placed on top of new multi-headed device, their configuration will break - so the feature is neither new, nor backward-compatibility-free. If you choose to ignore this issue, it may turn out to be a pain to fix it in late (RHEV-M) 3.1 cycle, when it is definitely branched from upstream. David
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@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
_______________________________________________ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
-- David Jaša, RHCE SPICE QE based in Brno GPG Key: 22C33E24 Fingerprint: 513A 060B D1B4 2A72 7F0D 0278 B125 CD00 22C3 3E24