[Engine-devel] [Spice-devel] SPICE related features
David Jaša
djasa at redhat.com
Wed Feb 15 14:22:44 UTC 2012
Oved Ourfalli píše v St 15. 02. 2012 v 08:06 -0500:
>
> ----- 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.
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 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
> >
> _______________________________________________
> 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