Okay my fellow penguinistas, now I'm even more confused... As I like to be
well-prepared, I do a lot of reading beforehand, and I keep the pertaining
webpages open in a browser on one machine while I'm trying to set up the
other machine.

Now, one of the big hurdles apparently was to overcome the lack of 3D
acceleration in the Xen /domU./ Apparently some initiatives have been
taken already in the meantime to overcome this, ranging from patching the
nVidia driver - which appears to have very limited success - up to
something flashy and new as the VMGL project. Yippie, I may have success
after all. Or...?

Well, from what it seems now - and correct me if I'm wrong - one may indeed
succeed in setting up an X11 server inside /domU,/ even with the
much-desired OpenGL acceleration, but... one cannot actually *view* this
session from within the /domU/ itself?

So, again, if I'm not mistaken, then one would still need to be running an
X11 session in /dom0/ or possibly even on another networknode and connect
to the /domU/ session using /vncviewer/ or some X11 forwarding? Is this
correct?

If it is, then it totally defeats the purpose of what I had in mind for this
new machine... The idea was that I could be running X11 _only_ inside a
specific /domU,/ with /dom0/ and the other /domUs/ configured as
character-mode-only servers.

As such, if I were to run into an X11 crash - with all the quirks I've
already experienced from proprietary nVidia *and* ATi drivers, totally
garbling all screen output after the X server is killed, making it
impossible to even do something again on the machine without a clean but
blind reboot - then any servers I'd be running inside /domU/ would lose
their uptime and availability as well, given that you cannot keep them
running while /dom0/ is rebooting.

Can anyone shed some light on this or guide me in another direction, please?
Would the Linux KVM offer me X11 sessions which actually connect to the
screen but which are isolated from the host OS? :-/

Hmm... I never thought I'd be asking so many questions on Usenet as I've
been doing these last few weeks. As it happened to be, I was typically one
of the people who _answered_ questions rather than asking. But then again,
that was another distro and another time, I guess... :-/

--
Aragorn
(registered GNU/Linux user #223157)

Aragorn wrote:

First of all, not much in Xen at all...

> So, again, if I'm not mistaken, then one would still need to be running an
> X11 session in /dom0/ or possibly even on another networknode and connect
> to the /domU/ session using /vncviewer/ or some X11 forwarding? Is this
> correct?

Using any of these methods will negate your OpenGL acceleration.

You could take a look at this thread at the Xen maillist:
http://lists.xensource.com/archives/.../msg00533.html
It's a bit old, so things may have changed.




--

//Aho

J.O. Aho <user@example.net> wrote:
> Aragorn wrote:
>
> First of all, not much in Xen at all...
>
>> So, again, if I'm not mistaken, then one would still need to be
>> running an X11 session in /dom0/ or possibly even on another
>> networknode and connect to the /domU/ session using /vncviewer/ or
>> some X11 forwarding? Is this correct?
>
> Using any of these methods will negate your OpenGL acceleration.

X11 itself supports remote OpenGL, but Gentoo doesn't allow you to compile
xorg-server with GLX extension, even if you have the mesa libraries
installed.
If you need to use X remotely and want OpenGL (and, of course, your client
supports it too), the solution is to compile your own xorg-server.

Regards,
--
*Art

Arthur Hagen wrote:
> J.O. Aho <user@example.net> wrote:
>> Aragorn wrote:
>>
>> First of all, not much in Xen at all...
>>
>>> So, again, if I'm not mistaken, then one would still need to be
>>> running an X11 session in /dom0/ or possibly even on another
>>> networknode and connect to the /domU/ session using /vncviewer/ or
>>> some X11 forwarding? Is this correct?
>>
>> Using any of these methods will negate your OpenGL acceleration.
>
> X11 itself supports remote OpenGL, but Gentoo doesn't allow you to
> compile xorg-server with GLX extension, even if you have the mesa
> libraries installed.
> If you need to use X remotely and want OpenGL (and, of course, your
> client supports it too), the solution is to compile your own xorg-server.

Thats good to know, I thought you needed XiG with it's closed source drivers
to get that, maybe I should take a look at this myself too.


--

//Aho

Arthur Hagen wrote:

> J.O. Aho <user@example.net> wrote:
>> Aragorn wrote:
>>
>> First of all, not much in Xen at all...
>>
>>> So, again, if I'm not mistaken, then one would still need to be
>>> running an X11 session in /dom0/ or possibly even on another
>>> networknode and connect to the /domU/ session using /vncviewer/ or
>>> some X11 forwarding? Is this correct?
>>
>> Using any of these methods will negate your OpenGL acceleration.
>
> X11 itself supports remote OpenGL, but Gentoo doesn't allow you to compile
> xorg-server with GLX extension, even if you have the mesa libraries
> installed.

Isn't this where VMGL comes in? If I understand correctly, then you load
something called "vmglext" as a module in X.Org.

> If you need to use X remotely and want OpenGL (and, of course, your client
> supports it too), the solution is to compile your own xorg-server.

My problem isn't so much that I couldn't get X11 to work in /domU/ -
apparently, that much is possible - but that it would seem that I wouldn't
actually be able to do the GUI work from within /domU,/ and thus that I
would still need to run X11 in /dom0,/ which defeats the whole purpose of
my plan as it renders the management virtual machine/driver domain
vulnerable to the quirks of X11 and proprietary video drivers, and thus it
would also mean that the availability of the dedicated servers running
in /domU/ virtual machines couldn't be guaranteed. :-/
--
Aragorn
(registered GNU/Linux user #223157)

Aragorn wrote:

> Okay my fellow penguinistas, now I'm even more confused... As I like to
> be well-prepared, I do a lot of reading beforehand, and I keep the
> pertaining webpages open in a browser on one machine while I'm trying to
> set up the other machine.
>
> [...]
>
> Well, from what it seems now - and correct me if I'm wrong - one may
> indeed succeed in setting up an X11 server inside /domU,/ even with the
> much-desired OpenGL acceleration, but... one cannot actually *view* this
> session from within the /domU/ itself?
>
> So, again, if I'm not mistaken, then one would still need to be running an
> X11 session in /dom0/ or possibly even on another networknode and connect
> to the /domU/ session using /vncviewer/ or some X11 forwarding? Is this
> correct? [...]

Okay guys, after some more careful scrutiny of the plethora of available yet
unclear or ambiguous webpages on the subject, I've come to realize that all
may not be lost. However, it does leave me with a question which I'm
hoping the more experienced among you - hint: Arthur Hagen? :p - could help
me solve. I will get into this question a little further down.

I am however posting my findings here so as to let you know - for those
interested in Xen - that my original plan was not so bad after all. You
see, my original plan invoked two graphics adapters, which are currently
both in that computer and are both hooked up.

One graphics adapter is an Asus GeForce 8800 GTS PCIe card with 640 MB of
memory. The other graphics adapter is a GeCube Radeon 9250 PCI card with
256 MB of memory. When the system boots, it only drives the Radeon PCI
card, apparently because it thinks it's the primary graphics adapter, which
is a bit strange since it's an older PCI card instead of the newer and
fancier PCIe cards like the GeForce card in my system. The Radeon is
hooked up to channel 2 of my primary monitor, while the GeForce is hooked
up to channel 1 on both monitors.

My original plan was to hide the GeForce from Xen in /dom0/ and thus have it
available as "native hardware" in /domU./ Apparently, a bug report on the
Xen Wiki does however state that this is broken in Xen 3.0, but I don't
know what it's status is in Xen 3.1 - Gentoo comes with Xen 3.1.2, albeit
still /~arch/ masked.

So it still remains to be seen whether I will actually be able to hide the
device from Xen and thus run X.Org with the unpatched nVidia driver in
(one) /domU./ I'm keeping my fingers crossed, as the information on the
internet seems so outdated that knowing what to expect is just plain
guesswork.

However, if I can indeed hide the device from the hypervisor and the /dom0/
XenLinux kernel, then it *should* in theory be possible to build the nVidia
driver module - provided that you export a variable called
IGNORE_XEN_PRESENCE with a value different from "0" - prior to building the
kernel module. Reportedly, this works for building and installing the
nVidia driver in /dom0,/ and if I can successfully hide the GeForce
from /dom0,/ then it becomes available as raw hardware to /domU/ and then
it shouldn't be any different there.

However - and this is where I come to my question - as long as I'm not
running X11 in the /domU,/ switching the console over from /dom0/ to /domU/
using the...

xm console

.... command, or alternatively...

xm create <virtual_machine_label> -c

.... then the primary display for character mode consoles will still be the
Radeon, and I believe it would also be very difficult to use a framebuffer
driver in /domU./ So what I would like to do is hide the Radeon
from /dom0/ when *inside* this one particular /domU,/ so that I would
simply always make use of the GeForce in this particular /domU,/ even for
character mode consoles - I'm not a fan of display managers anyway.

However - and herein lies the problem - hiding the Radeon from /dom0/ would
not be a Xen option but a Linux option. So... Does anyone know how to do
that?

--
Aragorn
(registered GNU/Linux user #223157)

Aragorn wrote:

> [...]
>
> However - and this is where I come to my question - as long as I'm not
> running X11 in the /domU,/ switching the console over from /dom0/ to
> /domU/ using the...
>
> xm console
>
> ... command, or alternatively...
>
> xm create <virtual_machine_label> -c
>
> ... then the primary display for character mode consoles will still be the
> Radeon, and I believe it would also be very difficult to use a framebuffer
> driver in /domU./ So what I would like to do is hide the Radeon
> from /dom0/ when *inside* this one particular /domU,/ so that I would
> simply always make use of the GeForce in this particular /domU,/ even for
> character mode consoles - I'm not a fan of display managers anyway.
>
> However - and herein lies the problem - hiding the Radeon from /dom0/
> would not be a Xen option but a Linux option. So... Does anyone know how
> to do that?

.... Or alternatively, I could have both the Radeon and the GeForce visible
to /domU,/ but is there a way to tell the /domU/ kernel to treat the PCIe
GeForce as the primary video adapter, rather than the PCI Radeon?

--
Aragorn
(registered GNU/Linux user #223157)

Aragorn wrote:

> My problem isn't so much that I couldn't get X11 to work in /domU/ -
> apparently, that much is possible - but that it would seem that I wouldn't
> actually be able to do the GUI work from within /domU,/ and thus that I
> would still need to run X11 in /dom0,/ which defeats the whole purpose of
> my plan as it renders the management virtual machine/driver domain
> vulnerable to the quirks of X11 and proprietary video drivers, and thus it
> would also mean that the availability of the dedicated servers running
> in /domU/ virtual machines couldn't be guaranteed. :-/

Here is guy explaining how he makes his microsoft to use the graphics,
look at this page http://permalink.gmane.org/gmane.com...en.devel/46168

--

//Aho

J.O. Aho wrote:

> Aragorn wrote:
>
>> My problem isn't so much that I couldn't get X11 to work in /domU/ -
>> apparently, that much is possible - but that it would seem that I
>> wouldn't actually be able to do the GUI work from within /domU,/ and thus
>> that I would still need to run X11 in /dom0,/ which defeats the whole
>> purpose of my plan as it renders the management virtual machine/driver
>> domain vulnerable to the quirks of X11 and proprietary video drivers, and
>> thus it would also mean that the availability of the dedicated servers
>> running in /domU/ virtual machines couldn't be guaranteed. :-/
>
> Here is guy explaining how he makes his microsoft to use the graphics,
> look at this page
> http://permalink.gmane.org/gmane.com...en.devel/46168

I was just writing up a lengthy reply to your post and I was about done when
X11 suddenly froze on this machine and I had to use the /SysRq/ keys to
bail me out, leaving me with a scambled an unreadable character mode again,
as usual. The only solution then is to reboot the machine
using /Ctrl+Alt+Del.../ :-/

Anyway, as much as I appreciate your reply and any clues thrown at me - I'm
obviously still in need of more learning - there are quite a few
differences between the set-up in the above story and mine. For starters,
the guy is using Windows in a hardware-virtualization set-up - which is
about the only legally available option to Windows users - while I intend
to use paravirtualized GNU/Linux machines instead.

The guy also has a Dell machine, and although Dell is notorious for
proprietarizing their hardware, to my knowledge an Intel VT machine does
not have an IOMMU, unlike what the author of that article claims.
Furthermore, Xen doesn't even use a hardware IOMMU; it uses SWIOTBL
(software I/O tables) instead.

I'm also not sure on whether the hiding of a device from the hypervisor/dom0
was done correctly by the author of the above article, as even the Xen
documentation and Xen Wiki are quite ambiguous on the subject; in some
instances, /pciback.hide=/ is listed as the appropriate boot parameter,
while in other instances /physdev_dom0_hide=/ is listed as the boot
parameter to use. Many topics on the Xen Wiki also relate to older
versions of Xen and may not or with certainty do no longer apply in newer
releases. It's quite confusing. :-/

Either way, the author of the article was attempting to hide the device from
the hypervisor/dom0 and thus had no need for any IOMMU, in software or
otherwise. I'm also not so sure on how his experiment - even with the
effect of the Windows Remote Desktop Protocol or the reputed poor stability
of Windows itself - could possibly lock up his machine solidly, unless
there is a serious bug in the hypervisor code. But then again,
hardware-based virtualization is a different beast from paravirtualization.

Normally, when hardware-based virtualization is used, the hypervisor
and /dom0/ run in the CPU's root mode - which has its own four privilege
rings - while /domU/ virtual machines run in the CPU's non-root mode -
equally with four privilege levels. So technically, if the machine locked
up solid, then this means that something has gone wrong in the root mode of
the CPU, and thus in the hypervisor code - unless of course we're talking
of a bug/flaw in Intel's Vanderpool technology.

Still, it was an interesting read, and certainly food for thought, thank
you. :-)

--
Aragorn
(registered GNU/Linux user #223157)

Aragorn wrote:

> Either way, the author of the article was attempting to hide the device from
> the hypervisor/dom0 and thus had no need for any IOMMU, in software or
> otherwise. I'm also not so sure on how his experiment - even with the
> effect of the Windows Remote Desktop Protocol or the reputed poor stability
> of Windows itself - could possibly lock up his machine solidly, unless
> there is a serious bug in the hypervisor code. But then again,
> hardware-based virtualization is a different beast from paravirtualization.
>
> Normally, when hardware-based virtualization is used, the hypervisor
> and /dom0/ run in the CPU's root mode - which has its own four privilege
> rings - while /domU/ virtual machines run in the CPU's non-root mode -
> equally with four privilege levels. So technically, if the machine locked
> up solid, then this means that something has gone wrong in the root mode of
> the CPU, and thus in the hypervisor code - unless of course we're talking
> of a bug/flaw in Intel's Vanderpool technology.
>
> Still, it was an interesting read, and certainly food for thought, thank
> you. :-)

I'm following your progress with interest here, as some of the ideas I
have had, you are now trying to do, mainly this with graphics access for
the domU.
What I lack at the moment is a machine powerful enough to try Xen on.

All Xen experience I have is the little I did experimented at work, but
that was just to run a number of webserver which don't require graphics
output as a virtual media player.


--

//Aho