Wenn mehrere verschiedene Systeme (unterschiedliche Distros, Versionen oder Exports) angeboten werden, will man evtl. das default-mäßig startende System ändern. Dieses geht durch slxsettings set pxe-default-menu-entry='suse-11.3-clone::nfs' (hier ist das Vendor-OS “suse-11.3-clone” in seiner Export-Variante “nfs” als im Menü vorselektiert eingestellt worden).
Ebenso lässt sich das Timeout bis der Default-Eintrag gebootet wird auf diesem Wege anpassen: slxsettings set pxe-timeout='50'. Weitere für das PXE-Menü auf dieser Weise festlegbare Variablen sind: pxe-passwd, pxe-title oder pxe-totaltimeout. Das Theme kann mit der Variablen syslinux-theme eingestellt werden (Voraussetzung ist natürlich, dass ein solches vorher angelegt wurde).

Wieder mal ein Test gemacht mit einem luxuriösen Server und ganz ordentlichen Clients. Der Server bietet 16 CPU Cores und verfügt über 48 GByte Speicher und ist als SLX- sowie Homeverzeichnisserver im Einsatz. Der Server hängt mit 4 Gigabit-Netzwerkinterfaces der Intel-Server-Bauart mittels Bonding-Interface am Switch (3COM Gigabit). Dabei passierte während der Tests im Bereich der Homeverzeichnisse nichts. NFS lief mit insgesamt 64 Threads (bei maximal 32 Clients).
Der Server ist ein aktuelles Debian mit 2.6.32 Kernel, die Clients ein Ubuntu-LTS-10.04.01. Bootzeit eines einzelnen Clients sowohl mit NFSv3 als auch mit SuashFS/NBD lag bei 18 Sekunden von der PXE-Menüauswahl bis zum Login-Screen (KDM auf Xorg/Intel). Wenn 16 Clients gleichzeitig per NFS booteten stieg die Zeit auf 22 Sekunden bei NBD sogar auf 24 Sekunden.
Folgende Dinge waren zu beobachten:

• Die maximale Transferleistung ausgehend auf dem Server war 1.9 Gbit/s
• Maximal wurden 1.8 Gbit/s beim gleichzeitigen NFS-Boot von 16 Clients gemessen
• Der gleichzeitige Start von 16 Clients mittels SquashFS/NBD erbrachte maximal 680 Mbit/s
• Das lineare Lesen des Blockdevices auf den Clients time dd if=/dev/nbd0 of=/dev/null erbrachte ein maximales Transfervolumen serverseitig ausgehend von 1.75 Gbit/s

Insgesamt scheint also im beschriebenen Setup das NBD die Kapazität des Netzes so gut wie nicht auszunutzen. Auch das Lesen von nur einem Client nach der beschriebenen Methode brachte die Peakleistung auf gerade 1/10 der Leistung. Im gesamten NBD-Setup machte es keinen Unterschied, ob der auszuliefernde SquashFS-Container auf der Festplatte (RAID) oder im RAM lag.
Ebenfalls fiel eine start schwankende Transferleistung auf: Das Maximum empfangener Pakete lag bei 100 Mbit/s das Minimum fiel bis unter 10 MBit/s bei insgesamt hoher Volatilität. Dabei wurde nicht weiter untersucht, ob das durch TCP-Parameter (Window-Size, ACKs, …) verursacht wurde oder ein Problem des NBD-Servers war. Von der Server- und Client-Leistung her sollte es keine Einschränkungen gegeben haben.
Das wirft nochmal ein anderes Licht auf den NBD (zumindest im vorliegenden Setup).
NFS lässt sich auch aus einem TEMPFS heraus exportieren, man muss es aber mit einer ID versehen (“fsid=1234″). Es braucht jedoch bedeutend mehr Platz (ca. 5:2 bezogen auf SquashFS).

Die Grafikkarteneinrichtung ist häufiger leider nicht ganz trivial, da sich immer mal wieder die Konstellation aus Distribution, Kernel, Xorg-Revision und evtl. notwendigen non-gpl Treibern ändert. Für die Fehlersuche ist es deshalb sinnvoll das fehlschlagende Setup möglichst vollständig an die Liste (z.B. openslx-users-de) zu posten.

Im Stage3 liefert hwinfo --gfxcard die Daten der Grafikkarte, z.B.

24: PCI 02.0: 0300 VGA compatible controller (VGA)
[Created at pci.310]
UDI: /org/freedesktop/Hal/devices/pci_8086_2772
Unique ID: _Znp.kw4rvyJqLZ2
SysFS ID: /devices/pci0000:00/0000:00:02.0
SysFS BusID: 0000:00:02.0
Hardware Class: graphics card
Model: "Intel 945G"
Vendor: pci 0x8086 "Intel Corporation"
Device: pci 0x2772 "945G"
SubVendor: pci 0x1028 "Dell"
SubDevice: pci 0x01ad
Revision: 0x02
Memory Range: 0xfeb00000-0xfeb7ffff (rw,non-prefetchable)
I/O Ports: 0xe898-0xe89f (rw)
Memory Range: 0xe0000000-0xefffffff (rw,prefetchable)
Memory Range: 0xfeac0000-0xfeafffff (rw,non-prefetchable)
IRQ: 16 (42777197 events)
I/O Ports: 0x3c0-0x3e7 (rw)
Module Alias: "pci:v00008086d00002772sv00001028sd000001ADbc03sc00i00"
Driver Info #0:
XFree86 v4 Server Module: intel
Driver Info #1:
XFree86 v4 Server Module: intel
3D Support: yes
Extensions: dri
Config Status: cfg=new, avail=yes, need=no, active=unknown

Primary display adapter: #24

Hierbei wird ein bestimmtes Xorg-Modul ermittelt (im Beispiel “intel”). Das hier gefundene Modul kann aber “überstimmt” werden, siehe dazu den Eintrag im Wiki. Wenn man das versucht hat zu ändern, sollte man im nächsten Schritt herauskriegen, ob das geklappt hat. Dabei sollte man nicht vergessen, die Änderungen zu installieren und den Demuxer laufen zu lassen.

Generell ist es sinnvoll zu ermitteln, um was für eine Hardware insgesamt
es sich bei einer Kiste handelt lspci, z.B.:

00:00.0 Host bridge: Intel Corporation 82945G/GZ/P/PL Memory Controller Hub (rev 02)
00:02.0 VGA compatible controller: Intel Corporation 82945G/GZ Integrated Graphics Controller (rev 02)
00:02.1 Display controller: Intel Corporation 82945G/GZ Integrated Graphics Controller (rev 02)
00:1c.0 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 1 (rev 01)
00:1c.1 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 2 (rev 01)
00:1d.0 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #1 (rev 01)
00:1d.1 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #2 (rev 01)
00:1d.2 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #3 (rev 01)
00:1d.3 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #4 (rev 01)
00:1d.7 USB Controller: Intel Corporation 82801G (ICH7 Family) USB2 EHCI Controller (rev 01)
00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev e1)
00:1e.2 Multimedia audio controller: Intel Corporation 82801G (ICH7 Family) AC'97 Audio Controller (rev 01)
00:1f.0 ISA bridge: Intel Corporation 82801GB/GR (ICH7 Family) LPC Interface Bridge (rev 01)
00:1f.1 IDE interface: Intel Corporation 82801G (ICH7 Family) IDE Controller (rev 01)
00:1f.2 IDE interface: Intel Corporation 82801GB/GR/GH (ICH7 Family) SATA IDE Controller (rev 01)
00:1f.3 SMBus: Intel Corporation 82801G (ICH7 Family) SMBus Controller (rev 01)
01:00.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5751 Gigabit Ethernet PCI Express (rev 01)

Hier gibts z.B. neben dem Namen der Grafikkarte (hier sieht man auch, ob mehr
als eine eingebaut ist), an welchem Bus diese hängt – im Beispiel: 0:02.0 Die
Bus-ID merkt man sich, um im nächsten Schritt mit lspci -n die PCI und VendorID des Devices herauszubekommen:

00:00.0 0600: 8086:2770 (rev 02)
00:02.0 0300: 8086:2772 (rev 02)
00:02.1 0380: 8086:2776 (rev 02)
00:1c.0 0604: 8086:27d0 (rev 01)
00:1c.1 0604: 8086:27d2 (rev 01)
00:1d.0 0c03: 8086:27c8 (rev 01)
00:1d.1 0c03: 8086:27c9 (rev 01)
00:1d.2 0c03: 8086:27ca (rev 01)
00:1d.3 0c03: 8086:27cb (rev 01)
00:1d.7 0c03: 8086:27cc (rev 01)
00:1e.0 0604: 8086:244e (rev e1)
00:1e.2 0401: 8086:27de (rev 01)
00:1f.0 0601: 8086:27b8 (rev 01)
00:1f.1 0101: 8086:27df (rev 01)
00:1f.2 0101: 8086:27c0 (rev 01)
00:1f.3 0c05: 8086:27da (rev 01)
01:00.0 0200: 14e4:1677 (rev 01)

Hier ist also die VendorID 8086 (Intel, das war zu erwarten) und die PCI-ID 2772.
Beide sind wichtig, da anhand dieser einmal hwinfo seine Zuordnungen vornimmt und zum anderen weil danach die Xorg-Treiber suchen. Die Infos zu den non-gpl Treibern geben diese Nummern für die unterstützten Karten an.

Für weitere Fehlersuchen sind die “(/mnt)/etc/X11/xorg.conf” und die Ausgaben des Logfiles des X-Servers “/var/log/Xorg.0.log” sinnvoll. Die meisten Informationen kann man im Stage4 beschaffen, hwinfo steht da jedoch unter Umständen nicht zur Verfügung.

Es gibt ein neues Tool in testfähigem Zustand am Start, den Pool Video Switch. Das ist ein Open Source Projekt als freie Alternative zu kommerziellen Hardware- und Softwareprodukten. Einige Hintergrundinfo zu Ideen oder auch von einem gehaltenen Vortrag.

Herunterladen kann man sich das Projekt derzeit lediglich mittels SVN, erst wenn eine gewisse Stabilität zur Verfügung steht, wird es auch Pakete geben:

svn co http://svn.openslx.org/svn/pvs

Benötigt werden die VNC-Libraries und einige Gnome/Gtk-Entwicklungspakete. Anschließend ruft man das übliche

configure

und

make

auf. Hier sieht man dann auch, welche Pakete noch fehlen; die man dann nachinstallieren sollte.

Installiert sein sollte auch das x11vnc Paket. Darauf basiert derzeit die VNC-Verbindung für das Monitoring der Clients. Es ist aber geplant, hier auch Alternativen zuzulassen.

Der poolVSClient läuft auf jedem Teilnehmerrechner und braucht eine Kon-
fig im Homeverzeichnis des Users:

• Konfigverzeichnis .pvs anlegen
• Darin eine Datei clientfile anlegen, die so aussieht:

  start:name-konsolen-rechner
  client-name
  end:name-konsolen-rechner

• Datei .allow anlegen mit einer “1″ drin
• Das Skript irgendwo hinlegen und dem poolVSClient dieses beim Aufruf mitgeben

Der poolVS ist die Steuerkonsole. Diese sollte auf einer separaten Maschine laufen oder in einem zweiten X-Server auf der Dozentenmaschine. Die Clients melden sich automatisch bei korrekter Konfig (name-konsolen-rechner ist die Maschine auf der poolVS läuft) an der Steuerkonsole an und können von dort aus bedient werden. Wenn alles glatt geht, schafft man es, auf die Clients per VNC zuzugreifen, sie zu sperren und Botschaften abzusetzen

Feedback ist willkommen!

Nun gibts auch die Möglichkeit via VMchooser den alternativen Emulator QEMU bzw. den darauf basierenden KVM in einer OpenSLX-Umgebung zu starten.

Unterstützt ist dabei das automatische Setup des jeweiligen Netzes (via TAP-Interface). Konfiguriert wird eine virtuelle Maschine wie gewohnt durch die entsprechende XML-Datei wobei das Attribut virtualmachine param=”qemukvm” gesetzt sein sollte. Es werden bisher jedoch nicht alle der angegebenen Attribute ausgewertet.