Firewalltests in VMWare
Um genaue Portangaben bei einer AD Replikation machen zu können, habe ich innerhalb eines VMWare Servers 2.0 eine Testumgebung mit zwei Domänencontroller und einer Firewall dazwischen aufgebaut. Leider ermöglicht VMWare dort nur sehr eingeschränkte Netzwerkeinstellungen (im ESX wäre es einfacher).
Als einfache Firewall nutzte ich M0n0wall: Eine sehr kleiner Linuxfirewall mit vielen netten Features. Bei VMWare existiert eine fertige Appliance zum herunterladen.
Da ich nur eine interne Netzwerkkarte zur Verfügung hatte, habe ich Monowall drei Netzwerkkarten ins gleiche “Host-Only” Netz gegeben. Eine davon wurde als externes Interface definiert und nicht weiter verwendet – die nächste als internes Interface (LAN) und die letzte als optionales Interface.
Security: VM kann Code in ESX ausführen
Ich habe gerade einen interessanten KB Artikel bei VMWare gefunden: http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1009852
Darin wird ein Update vorgestellt, dass eine Sicherheitslücke schließt, die es ermöglicht aus einer Virtuellen Maschine (VM) Code auf dem Host System (in diesem Fall ESX 3.5) auszuführen. Leider stehen auch im CVE Eintrag keine Details.
Viele Virtualisierungsgegner haben immer genau davor gewarnt. Aber es hieß immer, dass VMWare ESX so sicher ist, dass so was nicht vorkommen kann. Der Artikel zeigt jetzt etwas anderes. Wie riskant die Lücke ist, kann ich nicht einschätzen. Aber allein die Existenz ist natürlich Wasser auf die Mühlen der Virtualisierungsskeptiker.
ESX 3.5 Update 4 Patche
Gestern hat VMWare neue Updates für den ESX 3.5 und ESXi 3.5 Server herausgebracht.
Detailierte Beschreibungen zu den Änderungen sind unter folgenden Links zu finden:
ESX 3.5: http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1007971
ESXi 3.5: http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1007990
Ich hoffe ab morgen wieder Zugang zu einer Testumgebung zu bekommen, damit ich solche Neuigkeiten auch genauer testen kann…
Don’t Panik: Was tun, wenn die VMDK Datei weg ist…
Gestern war es mal wieder so weit: Durch Storage VMotion wollte ich alte SAN Disks leeren. Daei blieb auf einer SAN-Disk Dateien einer VM zurück, die eindeutig schon verschoben war. In der Annahme, dass es sich dabei um Altlasten handelte, löschte ich diese spontan. Leider handelte es sich dabei um einen Clone der anderen Machine, die im Dateisystem leider den gleichen Namen behalten hat.
Die meisten Dateien waren gesperrt und konnten zum Glück nicht gelöscht werden. Was aber erst später auffiel: Es wurde erfolgreich die Description Datei der Platten gelöscht:
HAL austauschen
Meiner SCOM-Testmaschine wollte ich per ESX einen zweiten Prozessor spendieren, da sie nur sehr langsam reagierte und die Datenbank auf dem gleichen System läuft.
Die übliche und einfache Methode unter Gerätemanager und Computer von ACPI auf Multiprozessor ACPI umzuschalten funktioniert unter Windows 2003 R2 nicht mehr, um die zweite CPU nutzen zu können. Eine kurze Webrecherche hat zwar unzählige Möglichkeiten ergeben, aber die in meinen Augen einfachste und eleganteste habe ich im VMWare Forum gefunden:
ESX und VMWare
Gerade Windows Installation für Templates werden häufig mit kleinen Platten (ich verwende 10GB für das System) installiert. Dies reicht für den Großteil der Installationen aus, wenn man versucht größere Datenmengen auf extra Disks zu legen. Trotzdem kommt es immer wieder vor, dass der Platz nicht reicht. Seit ESX 3.5 (Update 2?) kann man Disks im laufenden Betrieb vergrößern.
Windows erkennt dies auch automatisch. Leider kann Windows 2003 nur NIcht-Systemplatten mit Boardmitteln vergrößern. Bevor jetzt ein ein Neustart mit einem Festplattenpartitionierungsprogramm gemacht wird möchte ich auf ein kleines aber sehr mächtiges Tools hinweisen: DriveSnapshot (www.drivesnapshot.de): Dieser Imagebackuptool kann viel mehr als die meisten wissen.
Burn In Tests
Heute wollte ich mal wieder ein paar Blade Systeme ins ESX Cluster aufnehmen. Da ich aber bei einem bereits in einem anderen Zusammenhang ein Problem hatte, waren vorher einige Lasttests angebracht.Da momentan noch kein standardisiertes Tool eingesetzt wird, habe ich etwas im Internet gesucht und bin zufällig über ein sehr interessantes Tool mit Namen Inquisitor gestolpert. Es bietet eine Linux Live CD mit Burn-In Tests. An sich noch nichts besonderes. Interessant wird es zusammen mit der Serverkomponente, mit der solche Tests auch zentral protokolliert und verglichen werden können.