Im getesteten Setup erfolgt der NBD-Export (via nbd-server) einfach auf jedes einzelne VMDK, das damit als Blockdevice-Datei interpretiert wird. Auf der Client-Seite wird ein NBD-Device ganz normal per nbd-client erzeugt, was eine typische Device-Datei (/dev/nbdN) ergibt. Dieses Block-Device wird dann aber eben nicht gemountet, sondern direkt angesprochen. Am einfachsten zeigt ein Link, der das VMDK (, VDI, …) repräsentiert, einfach auf die Datei des Blockdevices, z.B. /dev/nbd7/ … Andere Blockdevices (DNBD2, iSCSI) sollten sich ebenso eignen, wurden aber noch nicht getestet.

In einem generellen, weiteren Schritt, könnte dann auch überlegt werden, dass “Diffing” (Wegschreiben der Session-Unterschiede) über dieses Blockdevice (zumindest NBD kennt ein COW) zu realisieren, statt es beispielsweise in einen RW-NFS-Share zu machen. Das sollte insbesondere bei Maschinen mit relativ wenig RAM und dem Redo auf NFS die Sache deutlich vereinfachen. Dann würde man aber das Image nicht non-persistent sondern persistent nutzen.

Die ganze Aktion sollte das NFS erheblich entlasten. Der Netzwerktraffic wird sich nicht wesentlich verändern, auch wenn das Caching auf dem Client bei wiederholten Blöcken was ausmachen sollte. Die Performance scheint sich zu verbessern, wie folgende sehr grobe Messungen zeigten. Diese erfolgten später am Abend, damit das Netz schon relativ leer war. Eine Geschwindigkeitsmessung wurde mit drei verschiedenen Servern gemacht:

• NBD A: Neuere Dell-Servermaschine mit 24 GByte RAM, 10 Gbit/s Netz, Hardware-Raid auf zwei SAS (nicht super fix), OS: Scientific Linux 5.4 (2.6.18er Kernel)
• NBD B: Sechs Jahre alte SUN V20z mit 8 GByte RAM, 2 Gbit/s Netz, Software-Raid über zwei ältere SCSI-320-Platten, OS: Debian 6 (2.6.32 Kernel)
• SUN-Server (24+GByte, …, 10 GBit/s Netz), OS: Aktuelles Solaris auf ZFS

Im ersten Test war kein Server direkt im Netz des Clients, im zweiten Fall nur der NBD B. Dabei ging es dann aber trotzdem noch über einen Stapel von Switches.

Die Messung erfolgte immer beim dritten Start in der gleichen Konfiguration zum Ausschluss von Caching-Unterschieden auf einem Dual-AMD-Turion, der 3+ Jahre alt ist, 4 GByte RAM hatte und via Gigabit ans Netz angeschlossen ist:

NBD A – 1.15 Min
NBD B – 1.35 Min
NFS – 1.46 Min

Die Messungen wurden auf einer neueren Maschine (ca. 1 Jahr alt, Intel E5300 CPU, 4 GByte RAM, Gigabit Netzwerkanschluss) wiederholt:

NBD A – 1.02 Min
NBD B – 1.05 Min
NFS – 2.02 Min

Im ersten (optimalen) Fall wurden 30 Sekunden (~70% der Standardstartzeit) Einsparung erreicht. Interessant im zweiten Setup war, dass hier NFS und NBD fast um den Faktor zwei auseinanderliegen, sich NBD auf dem alten und dem neuen Server aber kaum unterschieden. Schwer zu bestimmen ist hier der Einfluss von Netzwerk und Maschinenperformance. Die beiden Rechner standen in verschiedenen Teilnetzen mit etwas unterschiedlicher dahinterliegender Infrastruktur, die aber mindestens 1 Gigabit bereitstellt.

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.