[Engine-devel] [Spice-devel] SPICE related features
David Jaša
djasa at redhat.com
Wed Feb 15 13:10:59 UTC 2012
Oved Ourfalli píše v St 15. 02. 2012 v 06:25 -0500:
>
> ----- Original Message -----
> > From: "Dor Laor" <dlaor at redhat.com>
> > To: spice-devel at lists.freedesktop.org, engine-devel at ovirt.org
> > Cc: "David Jaša" <djasa at redhat.com>, "Oved Ourfalli" <ovedo at redhat.com>, "Hans de Goede" <hdegoede at 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.
Downstream RHEV 3.0 does support multi-monitor linux guests using
Xinerama so it has to be taken into consideration.
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 at ovirt.org
> > >> http://lists.ovirt.org/mailman/listinfo/engine-devel
> > >
> >
> > _______________________________________________
> > Engine-devel mailing list
> > Engine-devel at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> >
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at 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
More information about the Engine-devel
mailing list