Hallo VMWare Fans
Hatte den Beitrag von Basti alias Gbbi schon vor einiger Zeit gelesen und war neugierig hier ebenfalls etwas zu experimentieren. Bin leider erst dieses Wochenende dazu gekommen.
Daher hier ein kurzer Bericht zu meinen Erfahrungen...
Erster Stolperstein: die verwendete VMWare Workstation Version. Gibbi hat ja schon darauf hingewiesen.
Habe hier auf meinem Rechner eine Lizenz von VMWare Workstation 6.0.x.
Wie von ihm beschrieben war es nicht möglich mit dieser Version den ESXi zu starten/installieren. Der Kernel hängte sich immer beim Booten auf.
Deshalb entschied ich mich dafür eine Testinstallation des ESX Servers durchzuführen. 60 Tage reichen mir vorerst um zu prüfen ob alles funktioniert und den Kauf einer Lizenz ziehe ich sowieso in Erwäging.
Leider hat die 6er Version der VMWare Workstation noch einen weiteren Bug. Diese Version änderte immer die MAC-Adresse in der VMX-Datei auf eine VMWare typische (00:50:xx) MAC.
Nachdem ich mich etwas schlau gemacht hatte (z.B. hier:
http://www.vmware.com/support/ws45/doc/network_macaddr_ws.html) änderte ich folgende Zeilen
ethernet1.addressType = "generated"
ethernet1.generatedAddress = "XXXXXXXXXXXXXXXXXXXXXXXXX"
ethernet1.generatedAddressOffset = "10"
in
ethernet1.addressType = "static"
ethernet1.address = "XXXXXXXXXXXXXXXXXXXXXXXXX"
Bei ethernet0 ebenso...
Leider hat daraufhin meine VMWare Workstation Version eine Fehlermeldung ausgegeben, dass diese MAC (00:40:d0:c0:xx:xx) nicht akzeptiert würde.
Erst nach einem Update auf VMWare Workstation 6.5 funktionierte es, dass die VM mit den richtigen MAC-Adressen bootete. Ich bin also um die 6.5er Version nicht herum gekommen. Beim ESX blieb ich dennoch (vorerst).
Und nun funktionierte alles ganz gut... habe gleich während der Installation IP/Gateway, usw. eingerichtet, dann ein Image (705MB) gezogen und in die Ramdisk des Rescue-Systems geladen. Von dort aus dann 1-zu-1 auf die Festplatte gespielt und gebootet.
Dies hier konnte ich leider nicht prüfen:
Außerdem muss bei 64-Bit-Systemen im BIOS die Hardwarevirtualisierung eingeschaltet sein.
, da Serverloft das BIOS mit einem Passwort versehen hat und seinen Kunden keinen Zugriff ins BIOS gewährt.
Lauf /proc/cpuinfo wird das entsprechende Feature aber unterstützt.
Leider war der Server nach dem booten nicht über das Netzwerk zu erreichen.
Ich habe dann nochmal das Rescue-System gestartet und die root- und bootpartition des ESX Servers dort gemountet. Konnte dann den Support für die Serielle Console/Console Redirection hinzufügen. Also die ttyS0 in der /etc/securetty hinzufügen und
co:2345:respawn:/sbin/agetty -h -L 57600 ttyS0 ansi
in der /etc/inittab.
Dann habe ich noch die Console Redirection im IPMC auf "Erweitert" gestellt, sodass ich auch die Ausgaben zum Kernel und Bootloader zu Gesicht bekommen habe.
Dort konnte ich mich dann an der Console anmelden und dann mittels esxcfg-vswif und esxcfg-vswitch das Netzwerk zu konfigurieren.
Dennoch war die Virtual Console nicht über das Internet zu erreichen.
"esxcfg-nics -l" zeigte die vmnic1 als up (mit 100Mps) mit der richtigen MAC-Adresse an. Diese Nic habe ich erfolgreich der Portgroup "Service Console" auf dem vSwitch0 hinzugefügt. Und der Console habe ich in dieser Portgroup das Device vswif0 mit der entsprechenden externen IP eingerichtet.
Und hier war der Fehler zu finden... das Device vswif0 hat eine eigene MAC-Adresse (00:50:56:xx:xx:xx) bekommen. Und mit dieser weiß der Switch nichts anzufangen.
Ich konnte sie in der /etc/esx.conf unter dem Punkt "/net/pnic/child[0000]/mac" glücklicherweise anpassen. Nun haben die Devices vmnic1 und vswif0 in der Console die gleiche MAC-Adresse. Störend wirkte sich das bis jetzt aber nicht aus - es funktionierte jedenfalls alles.
Jetzt war nur noch das Problem mit den MAC-Adressen der VMs zu lösen...
Zwei Möglichkeiten habe ich ausprobiert:
1. SNAT und DNAT:
Hierzu habe ich einen weiteren vSwitch (vSwitch1) ohen physikalische nic eingerichtet und die VMs diesem Switch zugeordnet. Zudem habe ich noch ein weiteres vswif (vswif1) für die Console dort eingerichtet.
Dann habe ich die VMWare Firewall Regeln testweise entfernen:
iptables -P INPUT ACCEPT
iptables -P OUTPUT ACCEPT
iptables -P FORWARD ACCEPT
iptables -F
iptables -X
und dann das Forwarding von und zur VM eingerichitet
echo 1 > /proc/sys/net/ipv4/ip_forward
iptables -t nat -A POSTROUTING -s *INTERNEIP* -o vswif0 -j SNAT --to-source *EXTERNEIP*
iptables -t nat -A PREROUTING -d *EXTERNEIP* -j DNAT --to-destination *INTERNEIP*
Dies hat schonmal funktioniert. Ich weiß nur nicht, ob auch in der minimal-console (vermute mal busybox) ein iptables zur verfügung steht.
Deshalb noch mein zweiter Lösungsansat.
2. proxy_arp.
Hierzu habe ich ersteinmal das Feature im Kernel angeschaltet:
echo 1 > /proc/sys/net/ipv4/conf/all/proxy_arp
echo 1 > /proc/sys/net/ipv4/conf/default/proxy_arp
dann eine Route zu der VM eingerichtet:
route add -host *EXTERNEIP* gw *INTERNEIP*
und diese (mit der externen MAC der vmnic1) Public gemacht:
arp -s *EXTERNEIP* 00:40:d0:XX:XX3:XX pub
Auch dies hat gut funktioniert. Steht denn der "arp" command und "route" in der ESXi Console zur Verfügung?
Persönlich ziehe ich die Methode über SNAT/DNAT vor, da ich damit mehrere VMs (mit unterschiedlichen) Ports auf eine externe IP mappen kann. Also z.B. Mailserver (z.B. mit den Ports 25 und 110) und Webserver (80/443) auf eine gemeinsame IP legen kann.
Notfalls wäre es sogar nichteinmal so tragisch wenn ich nicht mehr per IP auf die VMWare Console kommen würde. Denn darauf komme ich notfalls auch per Console Redirection im IPMC.
Bin nun weiter am ausprobieren und halte euch gerne darüber auf dem Laufenden. Bin auch gespannt ob ihr noch das ein oder andere erreicht habe.
Viele Grüße,
Andreas