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!