Dazu wird eine Pipe zwischen LAN und LAN2 eingerichtet. Auf diese wirkt eine Traffic Shape Regel:

z.B.

• Bandwidth: 10 KBit/s
• Delay: 100ms
• PLR  0.1     (also ca.  jedes 10 Paket geht verloren)

Daraus ergibt sich folgender Ping (man kann ziemlich genau erkennen, wann ich die Regel aktiviert habe):

Antwort von 192.168.58.3: Bytes=1000 Zeit<1ms TTL=127

Antwort von 192.168.58.3: Bytes=1000 Zeit=910ms TTL=127

Antwort von 192.168.58.3: Bytes=1000 Zeit=930ms TTL=127

Zeitüberschreitung der Anforderung.

Antwort von 192.168.58.3: Bytes=1000 Zeit=922ms TTL=127

Antwort von 192.168.58.3: Bytes=1000 Zeit=922ms TTL=127

Antwort von 192.168.58.3: Bytes=1000 Zeit=921ms TTL=127

Antwort von 192.168.58.3: Bytes=1000 Zeit=927ms TTL=127

Antwort von 192.168.58.3: Bytes=1000 Zeit=924ms TTL=127

Zeitüberschreitung der Anforderung.

Wirklich nettes Feature!

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.

Über die Weboberfläche habe ich dann das optionale Interface als LAN2 umbenannt.

LAN hat eine Adresse im Subnetz 192.168.58.0/24 erhalten. LAN2 eine Adresse im Netzwerk 192.168.59.0/24. Die DCs wurden ebenfalls jeweils in unterschiedliche Subnetze gepackt und als Gateway die jeweilige Adresse der Netzwerkkarte von M0n0wall angegeben.

Um die beiden Netzwerkkarten zu verbinden müssen statische Routen in der Firewall hinterlegt werden:

Statische Routen:

Interface Network Gateway Description

LAN2 192.168.58.0/24 192.168.58.15

LAN 192.168.59.0/24 192.168.59.1
Normalerweise gehen Pakete auf diesen internen Routen nicht über die Firewall. Um diese doch zu filtern, ist ein Einstellung zu ändern:

Filtering bridge Enable filtering bridge
This will cause bridged packets to pass through the packet filter in the same way as routed packets do (by default bridged packets are always passed). If you enable this option, you’ll have to add filter rules to selectively permit traffic from bridged interfaces.

Danach gelten auch die Firewallregeln für den Verkehr zwischen LAN und LAN2.

Mit diesem Setup konnte ich dann genau die notwendigen Ports für die Replikation inklusive der festgelegten dynamischen RPC Ports für die AD Replikation und dem FRS ermitteln.

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.

Jetzt wurde im NetApp Forum ein Tool bereitgestellt mit dem man dies automatisiert durchführen kann. Darüber hinaus ist es möglich bestehende Header Dateien zu überprüfen. Zu finden ist das Skript unter http://communities.netapp.com/docs/DOC-2735.

Gefunden habe ich den Verweis im Blog-Post http://www.yellow-bricks.com/2009/04/03/repairing-your-vmdk-header-files/.

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…

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:

Nebenbei: Die virtuelle Disk bei VMWare besteht bei Standarddisks (also ohne Snapshot, keine RAW Files) aus zwei Dateien: eine Beschreibungsdatei mit Namen diskname.vmdk und den eigentlichen Daten in diskname-flat.vmdk. Die Beschreibungsdatei ist eine reine Textdatei mit Unix Zeilenumbrüchen (natürlich).

Solange die Maschine auf einem Host läuft, ist es noch kein Problem und fällt leider nicht auf, wenn die erste Datei fehlt. Sobald aber ein vMotion auf einen anderen Host stattfindet, dann tritt ein Fehler auf, die VM stürzt ab und kann nicht mehr gestartet werden. Im Storage Browser erkennt man den Fehler daran, dass bei derVMDK Datei kein passendes Icon davor steht bzw. nur die Datei mit -flat.vmdk zu sehen ist.

Noch kein Grund zur Panik: Zuerst: Sicherung erstellen. Besonders wichtig sind die Log Dateien. In diesen Dateien sind die später notwendigen Parametern enthalten, mit denen man die Description Datei vollständig wiederherstellen kann.

Dann: Der Anleitung unter http://sanbarrow.com/vmdk/extracting-vmdk-from-log.html folgen. Dabei ist es wichtig, einen Editor zu verwenden, der auch mit Unix Zeilenumbrüchen speichern kann (Wordpad kann es anzeigen, aber wandelt die Datei beim Anspeichern wieder um). Sobald man die Beschreibungsdatei wieder erstellt hat, kann man sie über den Storagebrowser wieder hochladen. Verschwindet die -flat.vmdk Datei nach einem Refresh und taucht das Icon vor der diskname.vmdk wieder auf, dann stehen die Chancen sehr gut, dass die Maschine wieder startet. (In meinem Fall war es zum Glück so…)

Bei Fragen einfach einen Kommentar anhängen.

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:

Jimmy Bondi 1 posts since
Nov 28, 2005

16" href="http://communities.vmware.com/message/313128#313128">16. Re: How to change Windows 2003 server Hal back to Uniprocessor Nov 28, 2005 2:25 PM
in response to: ReverendDeuce
There is also another a very simple way to change back to Uniprocessor!

Simply change the following lines in your hal.inf or create a copy and select it manually when changing the “hal-driver”:

[GENDEV_SYS.NTx86]
%E_ISA_UP.DeviceDesc% = E_ISA_UP_HAL, E_ISA_UP, MPS_UP, MPS_MP, ACPIPIC_UP, ACPIAPIC_UP, ACPIAPIC_MP ; Standard PC
%ACPIPIC_UP.DeviceDesc% = ACPIPIC_UP_HAL, ACPIPIC_UP, ACPIAPIC_UP, ACPIAPIC_MP ; ACPI PIC-based PC
%ACPIAPIC_UP.DeviceDesc% = ACPIAPIC_UP_HAL, ACPIAPIC_MP, ACPIAPIC_UP, ACPIPIC_UP; ACPI APIC-based PC (UP)
%ACPIAPIC_MP.DeviceDesc% = ACPIAPIC_MP_HAL, ACPIAPIC_MP, ACPIAPIC_UP, ACPIPIC_UP; ACPI APIC-based PC (MP)
%MPS_UP.DeviceDesc% = MPS_UP_HAL, MPS_UP, ACPIAPIC_UP ; MPS UP PC
%MPS_MP.DeviceDesc% = MPS_MP_HAL, MPS_MP, MPS_UP, ACPIAPIC_MP, ACPIAPIC_UP ; MPS MP PC

After that you will be able to choose any hal on an APIC system and it will be installed by the built-in routines. So far it should work without any further problems though it will need some two reboots until erverything is switched over.

Jimmy

Ich kann bestätigen, dass dadurch wieder alle HAL-Typen zur Auswahl stehen. Nach einem Neustart wurde die zweite CPU im Taskmanager angezeigt und auch genutzt.