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
David
______________________________________
_________
Engine-devel mailing list
engine-de...@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
