Ich bin inzwischen fertig mit meinem Umzug, der Server konnte von einem Xen zum anderen Xen übertragen werden. Leider hatte ich aber danach so meine Schwierigkeiten.
Aber der Reihe nach.
Kurze Erklärung zu meinem Aufbau:
Xen-Center (Hat interne IP)
Firewall-VM: LAN (interne IP) // WAN (externe IP macht NAT nach intern)
Die Firewall ist also eine virutelle Maschine auf dem XEN. (Auf die Idee hat mich ein Kollege gebracht.)
Nun was alles los war:
Am 12ten wurde mein neuer Hardwareserver also im Rechenzentrum verbaut und verkabelt. Die Firewall und das Xen waren vorbereitet und konfiguriert. Los gings, als erstes habe ich meinen virtuellen Server heruntergefahren und einen Export auf dem Xen-Center angeschmissen. Zwischenzeitlich die Hardware gestartet. Und? Nichts! Meine IP war nicht zu erreichen.
Switchkonfig überprüft –> Passt alles und die Ports des Servers waren oben. Also noch mal ins RZ und den Laptop anschließen und über das Xen-Center verbunden. Hmm, die Firewall-VM lief, die IP-Adressen des beiden Interfaces stimmten auch. Kann doch nicht war sein. Also dem Xen-Server selbst mal die exterbe IP geben und sofort war diese erreichbar. Seltsam! Da ich mich mit der FW nicht so gut auskannte, erst mal die Regeln und das NAT kontrolliert. Nichts auffälliges gefunden. Verbindungen über die internen IPs gingen einwandfrei. Nur nach extern ging nichts.
Hmm, dann hatte ich die Vermutung, das die Netzwerkkarten meines Server evtl. vertauscht sein könnten, da die Bezeichnungen mich etwas verwirrten. Aber auch hier Fehlanzeige, alles war so wie ich es beim Konfigurieren angenommen hatte. Ich war mir sicher, dass es an der Firewall liegen musste, also alle Regeln rausgeschmissen und einfach alles in alle Richtungen erlaubt, also die Firewall komplett außer Kraft gesetzt. Aber auch das war nicht die Lösung. Zum Verzweifeln!!
Zum Glück war der Kollege auch da, von dem ich auf die Idee mit der Firewall-VM gebracht wurde. Also hin zu ihm und ihm gebeten mir noch mal seine Config zu zeigen. Kurz gesprochen und dann ist es mir aufgefallen. Ich hatte beim eintragen der externen IP ein falsches Subnet angeben (/32). Das ich so nicht zu meinem Gateway komme hätte mir klar sein müssen. Obwohl ich mir meine Config x-mal angeschaut hatte, ist mir dieser Fehler erst am Monitor meines Kollegen aufgefallen. Und was soll ich sagen, kaum hatte ich das richtige Subnet eingetragen, schon war meine Firewall von extern erreichbar. Schade das dafür einiges an Zeit drauf gegangen ist.
Nun kam das nächste “Problem”.
Der Export meiner Server-VM war inzwischen fertig. Knapp 20GB. Diese müssen nun aber auf meine Server drauf. Der versuch, das über das Xen-Center einzuspielen habe ich nach 3 Stunden aufgegeben. Soweit ich das nachlesen konnte, verschlüsselt der Xen-Center die Daten die er überträgt und ist daher so tierisch langsam.
Meine Lösung war dann ein NFS-Server auf meinem Laptop.
Ich habe meine Laptop also direkt an den Server angeschlossen, auf meinem Laptop einen NFS-Server laufen lassen und dann vom Xen aus gemounted. Da beide Schnittstellen Gigabit waren, war die Leistung also erfreulich schnell 
Dann per “xe vm-import” die VM importiert, was so ca. 30 min gedauert hat.
Nach dem Import konnte ich die VM ohne Probleme starten, jetzt hatte ich nur noch die IP-Adresse, den hosts-Eintrag und ein paar Programm-Configs anzupassen. Und nach dem Neustart sah alles gut aus.
Noch den Blog Eintrag geschrieben und ab ins Bett.
Am nächsten Tag wollte ich dann noch ein bisschen aufräumen und hab erst mal die Xen-Tools installiert und dann per apt-get ein bisschen aufgeräumt. Dabei ist mir zwar aufgefallen, dass ein alter Xen-Kernel gelöscht wurde, aber ich dachte mir ja, es ist ja ein neuer installiert worden. Was auch stimmte, aber leider nur teilweise.
Ein weiterer Neustart und mein Server wollte mit einem “pygrub”-Fehler nicht mehr starten. AAAHH!
Zum Glück hatte ich einen Snapshot vor dem aufräumen mit apt-get gemacht und dieser ließ sich starten. Ich konnte nach ein bisschen ausprobieren rausfinden, dass ich kein apt-get autoclean machen durft, da sonst mein Server nicht mehr booted. Was ich dann erkennen konnte war, dass das Module-Verzeichniss des Kernels der geladen werden sollte nicht (mehr) existierte. Als einen sehr dirty-Hack habe ich dann per Link auf ein anderes Modulverzeichnis verwiesen und damit ging das auch wieder. Das dies aber keine finale Lösung sein sollte, ist ja wohl klar. Aber jedenfalls war der Server so rebootsicher.
Vorgestern habe ich mir das ganze dann mal genauer angeschaut. Die menu.lst von grub verweist auf einen Kernerl, den es zwar noch gibt, dessen Module-Verzeichniss aber nicht mehr existiert. Wahrscheinlich wegen dem xen-tools update. Des weiteren gibt es einen neueren Xen-Kernel, der aber nicht als Default eingetragen wurde. Nachdem ich den neuen Kernel entsprechend als Default eingerichtet hatte, funktioniert nun alles wieder. Hierbei habe ich ein paar Befehle von diesem Artikel im Citrix-Developer-Network verwendet, welche wohl für das Benutzen von pygrub nötig sind. Auf den Artikel bin ich gestoßen als ich versucht hatte ein Lenny auf meinem Xen-Server zu installieren, ich aber keine einfach 32bit Installation zum laufen bekommen habe. Mit 64bit geht es nun aber
Mein abschließendes Fazit ist:
Ein eigener Xen-Server ist toll. Die Migration zwischen zwei Xen-Server funktioniert ebenfalls recht gut, wenn man nicht unbedingt über das xen-Center geht. Die Migration über Versionsgrenzen ist wohl nicht ganz so einfach möglich wie gedacht. Jedenfalls freue ich mich nun darüber diese Projekt abgeschlossen zu haben und habe dabei natürlich auch wieder einiges gelernt.
Für Fragen, Kommentare, Anregungen oder auch Kritik bin ich gerne zu haben. Einfach einen Kommentar hinterlassen und ich werde bestimmt antworten.
