Wir haben hier eine hübsche VMWare GSX Server Kiste die einige unserer Testsysteme hostet. Eine Besonderheit dabei ist, dass die Maschine neben ihrem normalen eth0 noch ein eth1 hat das in mehreren VLAN's steht und mit Hilfe von VLAN Tagging und einem 802.1q Trunk Port auf der Switchseite nur ein Ethernet Interface benötigt.

Die unterliegende Hardware war bisher ein guter? alter Compaq DL760 mit 8 CPU's den es bei Last immer in einen Kernel-Lockup getrieben hat. Nach diversen Experimenten mit anderen VMWare Versionen, Kernel Updates, Distro Wechsel von Debian nach RHEL4 die alle das Problem nicht behoben haben wurde es nun mal Zeit die zugrunden liegende Hardware zu tauschen. Nachdem nun ein HP DL380G3 frei wurde habe ich die komplette Maschine per rsync -avPSHx auf die neue Hardware umgezogen. Nach 2 1/2 Stunden war alles auf der neuen Maschine eigentlich sollte diese ja nun recht problemlos wieder hochkommen.

Leider wird sich das noch als Trugschluss herausstellen, da ich einige Kleinigkeiten nicht bedacht habe und andere Effekte es sich in den Kopf gesetzt haben mir ins Knie zu schiessen.

rsync ist Klasse, hat aber Nebenwirkungen. Man bekommt zwar alle Daten 'rüber, einige Metadaten gehen allerdings verloren, wie z.B. die Context-Informationen von SELinux. Ausserdem sollte man sich ein wenig mit grub auskennen damit man die neue Maschine auch wieder bootbar bekommt. Und die dritte Hürde ist dann der Wechsel des RAID Controller Treiber von cpqarray zu cciss.

Nachdem ich grub und mkinitrd gebändigt habe und die neue Maschine gebootet hat habe ich die VM's wieder gestartet. Leider ist das vmware allerdings so "intelligent" dass es bei der automatischen Ermittlung eines Netzes für NAT eines unserer intern genutzten Netze verwendet so dass eine Kommunikation mit dem VMWare Host nach dem Start des VMWare nicht mehr möglich ist. Nun gut, ist ja nix was nicht ändern könnte. vmware-config.pl gestartet ein ungenutztes Netz für's NAT eingerichtet und dezent eine Warnung wegen differierender Compilerversionen ignoriert.

Dem Start der VM sollte nun ja eigenlich nicht mehr im Wege stehe, und so habe ich die 10 installierten VM's gestartet und micht auf einen frühen Feierabend gefreut (dummer Fehler!) Nachdem die VM's gestartet waren und ich noch ein defektes /var Filesystem auf einer der VM neu angelegt habe muss ich leider feststellen dass die VM's die über eth1= auf ein anderes VLan zugreifen wollen zwar untereinander reden können aber nichts ausserhab der VM in diesen LAN erreichten. Nun gut, =tcpdump und ethereal sind ja meine Freunde und so machte ich mich auf die Suche nach den verlorenen Paketen.

tcpdump auf dem VMWare Host zeigt nichts gesonderes, ausser dass wohl keine Antworten auf die ARP Anfragen aus diesem LAN kommen. Nun gut dann muss ich mal schauen was aus dem Ethernet Interface wirklich 'rausfällt und nach einer kleinen Umkonfigurierungs-Arie von Switches und Sniffer Host konnte ich dann auch dass Ethernet Interface per =ethereal= sniffen und sah das keine Arp-Anfragen aus dem Interface 'rausfielen.

Nun gut, dass könnte ja die Netzwerkkarte im neuen Host sein, vielleicht hat ja der tg3 Chipsatz da irgend ein Problem... So baue ich die alte Ethernetkarte aus dem alten DL760 und baue sie in den neue Rechner ein. Leider ist das Problem damit nicht beseitigt, sondern besteht weiterhin, also noch mal tcpdump und ethereal anwerfen und schauen ob sich was verändert hat. Ausser der MAC Adresse wohl offensichtlich nichts :-(

Um zu prüfen ob es nun am Linux oder am VMWare konfiguriere ich eine IP Adresse auf VLAN Interface des VMWare Hosts, bisher hatte es keine, da es ja nur zum Bridging in den VMWare Software Switch benutzt wird. Aber auch von Host aus kann ich nichts anpingen oder in dem Netz erreichen, scheint wohl eher am Linux zu liegen ?!?

Erst ein Blick in /proc/net/vlan/eth1.23 macht mich stutzig, Warum steht "total frames transmitted" eigentlich auf 0? OK, dann einfach mal das debugging im e100 kernel modul aktivieren vieleicht gibt das einen Hinweis. /etc/modprobe.conf ist schnell ergänzt, aber ein rmmod e100 schlägt fehl weil irgendwer das eth1.23 nicht richtig freigegeben hat. Nun gut dann boote ich die die Kiste eben... Noch schnell den Autostart von vmware ausgeschaltet, Kiste rebootet (hat jemand mitgezählt? war bestimmt von das 5. mal heute) und dann mal geschaut ob nun das VLAN Tagging geht. Ob Wunder! ohne VMWare funktioniert es ja! War da nicht etwas mit einer Warnung bezüglich differierender Kompilerversionen?!? OK, Kernel wurde mit gcc 3.4.5 kompiliert aber installiert ist ein gcc 3.4.6. Grmml, das tut doch nicht Not!

Nun gut dann machen wir mal ein up2date, hoffentlich kommt dann eine mit einem gcc 3.4.6 gebaute kernel version. up2date liefert rd. 20 neue RPM's aber die Installation der RPM's schlägt im %pre und/oder %post mit "scriptlet failed, exit status 255" fehl... Grrr, inzwischen ist es 18:45 und ich hab eigentlich keinen Bock mehr aber aufgeben zählt nicht. Ein wenig googlen bringt mich dann auf den Trichter dass SELinux mir da möglicherweise in die Suppe spuckt. Also in /etc/sysconfig/selinux SELinux disabled, Kiste wieder booten und die RPM's nun endlich installiert. Nun noch ein weiterer Boot um den neuen Kernel zu starten und noch einmal durch =vmware-config.pl= durchgehühnert diesmal ohne Warnung wegen differierender Compilerversionen. Nun VMWare starten und die VM's hochziehen und siehe da: Sie sind alle wieder erreichbar.

Was lernen wir daraus liebe Kinder: Immer schön an die Meta-Informationen eines Filesystems denken und die eine oder andere Warnung erstnehmen, das kann einem 6 Stunden Sucherei ersparen.

Nu ist aber Zeit für Feierabend!