Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
Xorg on xen-enabled desktop: xserver in dom0 or in domU?
View unanswered posts
View posts from last 24 hours

 
Reply to topic    Gentoo Forums Forum Index Desktop Environments
View previous topic :: View next topic  
Author Message
oegat
n00b
n00b


Joined: 12 Apr 2003
Posts: 41
Location: Sweden

PostPosted: Sat Mar 10, 2012 4:16 pm    Post subject: Xorg on xen-enabled desktop: xserver in dom0 or in domU? Reply with quote

I have a simple question for my xen-desktop project. I'm building a desktop system with xen in order to be able to run gentoo and win7 concurrently on one machine. I see that most similar linux systems mentioned around the net have installed Xorg in dom0 and run the day-to-day desktop software from dom0. But it would also have been convenient to keep a fairly lightweight and stable dom0 and move most other software usage to a less critical and more experiment-friendly pv domU.

This would, in it's most straightforward form, entail that the Xorg-server would preferably run in domU. If Im not mistaken the framebuffer in recent kernels may be forwarded to a pv domU. Given a recent kernel (right now 3.2.1-r2) and the nouveau video driver, is it possible or advisable to run the X server in a domU? Would it hit performance, stability, or both?

If this is not recommended, I would instead be happy for recommendations on how to keep the dom0 X setup minimal. What parts of an X desktop may conveniently be moved to a domU (maybe even the WM?). The goal is to have less stuff which can break in dom0 and preferably less frequent world updates there (apart from security updates).

I have seen posts asking about this before, but since kernel features change quickly I'm looking for an up-to-date recommendation on this idea. Thanks.

Edit: I went with everything in dom0 for now. But the questions remain for curiosity and future reference...
_________________
Högt över fjällen där flyger en ko
kanske den flyger på sin tro?
Back to top
View user's profile Send private message
miket
Guru
Guru


Joined: 28 Apr 2007
Posts: 426
Location: Gainesville, FL, USA

PostPosted: Tue Mar 13, 2012 4:12 am    Post subject: Reply with quote

I have a similar situation, but with Linux containers (LXC) instead of Xen. I'm not sure of the hardware-access situation for Xen DomU's, but in LXC you use Cgroups to grant permissions to the virtualized instances to use specific hardware devices. That's great, but the thing that tipped the issue for me is that there is currently no mechanism in LXC to pass udev events to the guest. This means that I could run the X server in the guest but at the price of having to use the old video drivers instead of Kernel Modeswitching. I like KMS better, so I put the X server on the host.

I installed a lightweight window manager (Openbox) on the host and an equally lightweight display manager (slim) and use X client-server forwarding. First I tried Xnest on the guest, but it wanted all the guest's fonts to be installed on the host and had problems with color depth. Then I went to Xephyr and got around those problems, but still had to figure out how to make the guest's keyboard work correctly and deal with a few odd display issues. It works well enough, though, so I didn't try using VNC. That would be a reasonable next step.

Both Xnest and Xephyr are optional parts of the X server. Emerge xorg-server with the "xnest" USE flag to get Xnest; use the "kdrive" USE flag to get Xephyr. I enabled them both on guest and host; you may not have to, but I didn't try it in other combinations.

I didn't stick with Xnest, and I don't remember enough to give you a solid lead. I this is the command I had to start the guest with Xephyr. It took several painful tries before I got the right sauce.
Code:
/usr/bin/Xephyr :1 -query <guestname> -screen <width>x<height> -keybd ephyr,,,xkbmodel=pc105,xkblayout=us,xkbrules=evdev


The name of the keyboard is not a typo. The word is Xephyr without the X.

Openbox and Slim are pretty straighforward. Both of them *are* awfully minimal. You can choose your backgrounds, but I never got too fancy. Slim starts up with a black screen, the Gentoo "G", and a login-ID box; Openbox defaults to a black background. Right-click on the Openbox screen and you ought to see a popup menu with a "Shells" category and an XTerm selection under that. Assuming you have your X server and WM or DE or whatever installed in the guest, you're almost ready to try things out. First you have to make sure that starting XDM in the guest does not try to access real hardware. In /etc/X11/xdm/Xservers on the guest you need to comment out any line like this:

Code:
:0 local /usr/bin/X :0 vt7


Now you ought to be able to start XDM:

Code:
/etc/init.d/xdm start


Now you can play with the Xephyr or Xnest. I hadn't done a whole lot with VNC, but I'm pretty sure that every VNC solution requires you to be able to start the X server. This means you're still going to need to comment out that line in /etc/X11/xdm/Xservers.

As is normally the case when you install XDM, the xdm service goes in the default runlevel. When listening for remote requests, XDM switches the normal X-Window notions of client and server. Your Xephr client (on the host) makes an XDMCP request to the guest XDM server, which sets up the connection and turns into an X client to the X server on your host. It has to be listening in order to do this.


Let me tell you some more about Openbox and Xephyr. I'll bet you'll find Openbox helpful even if you don't use Xephyr. The file .config/openbox/menu.xml controls what you get in the popup menu. I didn't change much from the default; I added the following after the section in the XML file for utilities.

Code:
     <menu id="41" label="Xephyr">
             <item label="the-guestname">
                     <action name="Execute">
                             <execute>/usr/bin/Xephyr :1 -query the-guestname -screen 1280x968 -keybd ephyr,,,xkbmodel=pc105,xkblayout=us,xkbrules=evdev</execute>
                     </action>
             </item>
     </menu>


I'm assuming that you will have tried several rounds of testing with the Xephyr command in a terminal, so copy and paste whatever you end up with. If Openbox is running while you set this menu item, get Openbox popup menu and click on Openbox -> Reconfigure to make the new configuration change take effect. Now you should be able to start your guest using the popup menu then selecting Xephyr -> the-guestname.


Openbox has almost no dependencies; it makes XFCE look like a heavyweight. Slim is mighty slim. There are a few seemingly not-necessary packages that I've got on the host, but not a lot.

media-gfx/sane-backends
media-sound/alsa-tools
media-sound/alsa-utils
media-sound/vorbis-tools
net-dns/bind
net-misc/ntp

(Yes, I run Bind and NTP on this host.) Beyond this, though, the heavy stuff on this machine is on the guests. I've got KDE 4.7 on an LXC guest this way.
Back to top
View user's profile Send private message
oegat
n00b
n00b


Joined: 12 Apr 2003
Posts: 41
Location: Sweden

PostPosted: Tue Mar 13, 2012 10:02 pm    Post subject: Reply with quote

Interesting. When you say that you had to use the old video drivers, I assume these were not nvidia or fglrx? Otherwise I would have been fine with that, although xen plays badly with nvidia (at least on the host side). Now I run nouveau on the baremetal host (dom0), which is OK to me.

So what youre doing is having a lightweight system with X and openbox running on the baremetal host, and having a virtualized X-session forwarded by XDMCP to a nested X server via Xephyr? This would if I understand it right require a display manager to run in the virtual machine, and then it's entire display is forwarded via XDMCP to a nested X server via Xephyr, which in turn runs in a window under X and openbox. Could you also have forwarded the X-session from the virtual environment directly to the main X server in the host system, skipping the nesting step with Xephyr?

I was thinking that if I cannot forward the X server from a vm to the host's framebuffer, I'd run the X server and window manager on the host system as you describe, but then just stick with old-style X11 forwarding (using the DISPLAY variable) for X programs run inside virtual machines. But this may not at all be a plausible solution. I won't run only an occasional xterm but at least things like firefox and Gimp. My idea is that X11 forwarding over the fake "internal" virtual network would be fast and secure enough, but I might be wrong about this.

I will have a look at Xephyr. Although from reading around it seems that vnc is what people use with xen, I guess its pretty much similar as you say.
_________________
Högt över fjällen där flyger en ko
kanske den flyger på sin tro?
Back to top
View user's profile Send private message
miket
Guru
Guru


Joined: 28 Apr 2007
Posts: 426
Location: Gainesville, FL, USA

PostPosted: Wed Mar 14, 2012 3:31 am    Post subject: Reply with quote

Quote:
When you say that you had to use the old video drivers, I assume these were not nvidia or fglrx?


No, I have Intel hardware, so the drivers are not so funky. I have been very happy with the KMS approach to video and keyboard drivers, where all the mode setting and hardware access is in the kernel. In the context of a guest LXC instance, a huge plus is not having to share the host's /dev/kmem with the guest. So when I was talking about old drivers, it wasn't to indicate drivers for old hardware or such, but drivers using the pre-KMS interface. The Nouveau driver supports KMS. The downside of KMS is that the X server needs to be able to receive dbus event notifications, and, so far as I know, none of Xen, KVM, or LXC have any facility to route udev events to virtualized guests. That means old-fashioned drivers for the X server if you want to talk to bare metal in the guest--and sharing /dev/kmem.

Quote:
So what youre doing is having a lightweight system with X and openbox running on the baremetal host, and having a virtualized X-session forwarded by XDMCP to a nested X server via Xephyr?


Yes. Yes, I've got x11-apps/xdm and kde-base/kdm on the guest, and when I start Xephyr in Openbox, I start a whole KDE session--startup music and all. The Xephyr client on the host views the nested X server on the guest. So far as I know, forwarding the X requests (with SSH or directly with TCP/IP) can't get you the whole desktop, but only one client window (and children) at a time. Also, clients that use the X shared-memory extension, which can't traverse the network, won't run unless you explicitly disable the shm for the client (Firefox used to fall in this category); you also have to have all the needed fonts installed on the host. These are problems also for Xnest. Xephyr and VNC do a better job of making things transparent.

Quote:
I will have a look at Xephyr. Although from reading around it seems that vnc is what people use with xen, I guess its pretty much similar as you say.


An advantage of Xephyr is that you don't have to get more packages; it's already in the X server. Depending on how they handle the sending of tiles for changes in the framebuffer image, Xephyr might also be a bit faster than VNC. On the other hand, VNC would likely not have the odd display artifacts I see. I'll have to try it myself.
Back to top
View user's profile Send private message
oegat
n00b
n00b


Joined: 12 Apr 2003
Posts: 41
Location: Sweden

PostPosted: Sat Mar 31, 2012 6:34 pm    Post subject: Reply with quote

So the WM always must run on the same machine as the X server, even with xdmcp. I suspected that this would be the case, especially since networks weren't that fast in the times when xdmcp was developed. It seems that I am going run my desktop system under dom0 and live with the scalability drawbacks, and run vnc for occasional windowed guests. Anyway, thanks for helping me sorting out the options.
_________________
Högt över fjällen där flyger en ko
kanske den flyger på sin tro?
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Desktop Environments All times are GMT
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum