[Engine-devel] [Spice-devel] SPICE related features
Oved Ourfalli
ovedo at redhat.com
Wed Feb 15 13:06:41 UTC 2012
----- Original Message -----
> From: "Alon Levy" <alevy at redhat.com>
> To: "Oved Ourfalli" <ovedo at redhat.com>
> Cc: "David Jaša" <djasa at redhat.com>, spice-devel at lists.freedesktop.org, dlaor at redhat.com, engine-devel at 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 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.
>
> 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.
> > 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
> > >
> > _______________________________________________
> > Spice-devel mailing list
> > Spice-devel at lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/spice-devel
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
>
More information about the Devel
mailing list