VMware auf einem Rootserver betreiben
Seit einiger Zeit schon bietet VMware den VMware Server incl. gültigem und unbegrenzten Lizenzkey, kostenlos zum Download an. Gleichzeitig ist es mittlerweile auch kein Problem mehr bei einem Provider, für einen Rootserver mehrere IP Adressen zu bekommen. Gute Voraussetzungen also, um aus einem Rootserver mehrere kleine virtuelle Maschinen zu machen. Die heutigen Rootserver sind mit AMD 64bit Dual Core und über 1000MB RAM sowieso absolut überdimensioniert.
Also fangen wir mal an.
Ersteinmal brauchen wir die Software und den Lizenzkey. Den bekommt man unter http://www.vmware.com/. Dann brauchen wir noch den Rootserver und ein paar IP Adressen. Das bekommt man ja auch an jeder Ecke, z.B. bei http://www.1und1.de/, http://www.elkhouse.de/, http://www.kolido.net/, http://www.server4you.de/ usw. usf. Wem diese Auswahl nicht reicht, der schaut am besten mal bei http://www.webhostlist.de/ vorbei. Wobei das sowieso Pflicht ist, wenn man sich auf einen neuen Provider einlassen möchte.
Ich gehe mal davon aus, dass das tgz Paket vom VMware Server auf dem Server liegt, Die Clientsoftware von VMware passend zu dem daheim verwendeten Betriebssystem bereits installiert ist und der Lizenzkey ebenfalls vorhanden ist. Der Rootserver ist jungfräulich installiert und die zusätzlichen IPs sind ebenfalls bekannt.
Jetzt fehlt noch die Auswahl des Betriebssystems für die virtuellen Server. Denn da muss ja auch noch was drauf. Wer sich da allerdings nicht so sicher ist, was er denn nehmen soll, dem empfehle ich erst einmal ein paar Runden Zuhause zu testen, bevor man sich an die finale Installation auf dem Rootserver macht. Denn diese kann sich besonders bei einer schwachen DSL Leitung zum Geduldsspiel entwickeln. soabld man sich für das Betriebssystem entschieden hat - wird wohl in den meisten Fällen ein Linux sein - die Images der Installations-CDs saugen und ebenfalls auf dem Server ablegen. Zum Schluss sollte noch sicher getellt sein, dass der zum installierten Kernel passende Quelltext installiert ist. Dieser wird bei der Installation von VMware Server benötigt.
Hier nun die Ausgangssituation im Überblick:
Rootserver:
SuSE 9.3 64bit, Kernel 2.6.16.20-060620b
AMD 64 3200+
1024MB RAM
80GB Festplatte
Pfad zu den virtuellen Servern /srv/vm/
Pfad zu den CD Images /srv/vm/
Installationspaket von VMware /usr/src/
Achtung: evtl. ist die Festplatte vom Hostsystem partioniert, dann könnte es durchaus sein, dass unter dem Pfad /srv nicht genügend Festplattenspeicher zur Verfügung steht. Bei mir jedenfalls ist der meiste Festplattenplatz dem Verzeichnis /home zugeordent. Deshalb lege ich unter /home das unterverzeichnis vm an und mach einen Softlink zu /srv/vm
#mkdir /home/vm
#cd /srv
#ln -s /home/vm
So ich denke, jetzt können wir mal mit installieren anfangen.
Das Installationspaket wird erst einmal entpackt. danach in das neue Verzeichnis wechseln und das Installationsskript starten.
#cd /usr/src
#tar -xzf VMware-server-1.0.0-28343.tar.gz
#cd vmware-server-distrib
#./vmware-install.pl
Eigentlich kann man die Vorgaben einfach bestätigen. Ich habe mich allerdings dafür entschieden, die ausführbaren Programme und die Dokumentationen unter /usr/local/vmware abzuspeichern. Wer das möchte, muss halt den geänderten Pfad eingeben.
Bei der Prüfung der vorhandenen und benötigten Bibliotheken kann es sein, dass da die eine oder andere angemeckert wird. Dann empfiehlt es sich erst einmal nachzuschauen, ob die Bibliothek tatsächlich fehlt, oder ob es nur ein Softlink ist, der noch fehlt. Bei SuSE scheint der eine oder andere Softlink erst gesetzt zu werden, wenn davon abhängige Programme über Yast installiert werden. Bei anderen Distributionen kann das natürlich noch einmal anderst sein. Für die Suche nach den vorhandenen Bibliotheken verwende ich den Befehl locate aus den findtools. Wenn diese neu installiert werden müssen, dann das updatedb nicht vergessen.
Ein weiterer Knackpunkt sind die Kernelsourcen. Wie oben schon angegeben, ist bei mir der Kernel 2.6.16.20-060620b installiert. Also ne gepachte Geschichte. wobvei ich nicht genau weiss, was denn da genau gepacht wurde. Die ungepachten Sourcen konnte ich direkt vom FTP-Server des Providers runterziehen. Den Patch habe allerdings nicht gefunden. Dennoch - ist zwar gefährlich, und jedem eingefleischtem Linuxadmin wird zwar das Herz bluten - es gibt eine Lösung für das Problem. Problem!? Ja hatte ich das nicht gesagt!? Die Installationsroutine von VMware besteht darauf, dass in der Includedatei version.h genau die zum laufenden Kernel passende Versionsangabe definiert ist. Ansonsten geht es nicht weiter. Da ich nicht weiss, welche(r) Patch(s) in den Kernel eingearbeitet sind, habe ich kurzerhand einfach die Datei version.h angepasst.
Damit das passt habe ich aus
–#define UTS_RELEASE “2.6.16.20″
++#define UTS_RELEASE “2.6.16.20-060620b”
gemacht.
Jetzt sollte die Installation durchlaufen und man kann nunzum Abschluss den Lizenzschlüssel eingeben. Sollte man den jetzt nicht eingeben wollen oder können oder die abfrage zu schnell wegbestätigt haben, dann kann man das auch noch später über die Clientsoftware tun. Womit wir beim nächsten Abschnitt wären.
Wer es bis jetzt noch nicht getan hat, der muss es wohl jetzt nachholen. Nämlich die Clientsoftware von VMware installieren. Natürlich gibt es da ein Paket für Windows und ein Paket für Linux. Beide sind in der Anwendung gleich und Lizenzfrei. Also nur der zu administrierende Server bnötigt den Lizenzkey.
Sind beide Programme (Server u. Client) richtig installiert, kann man jetzt mal einen Verbindungsversuch unternehmen. Startet man den Client neu, dann ist der Dialog für die Verbindungsdetails schon offen, hat man den schon weggeklickt, dann kann man den erneut aufrufen, indem man im Menü auf Host -> Connect to Host klickt oder einfach die Tasten STRG+L drückt. Bei Hostname trägt man die IP und getrennt durch einen Doppelpunkt den Port ein, über den die Verbindung abgewickelt werden soll. Bei User name trägt man root ein und bei Password das Rootpasswort, mit dem man sich auch sonst per ssh am Rootserver einloggt.
Die Geschichte mit dem Port kann noch zum Stolperstein werden. Bei der Installation wurde ein Port festgelegt. Bei mir ist das der Port 904. Und ein entsprechendes Konfigurationsfile für den xinetd wurde im Verzeichnis /etc/xinetd.d abgelegt. Das bedeutet, der xinetd muss laufen, sonst ist eine Verbindung zwischen Server und Client nicht möglich.
Jetzt haben wir also die Verbindung zum Server hergestellt und sehen erst einmal, dass wir nichts sehen ;-) Wer vorher den Lizenzkey nicht angegeben hat, sollte dies nun nachholen. Unter Help -> Enter Serial Number kann man das nachholen.
Machen wir uns an den ersten virtuellen Server. Dies wird ein Minimalsystem, mit den Programmen und Funktionen, die man eigentlich für jeden Server - gleich welcher Art - benötigt. Auf diesen kommen also nur solche Sachen wie iptables, ntp, snmp etc. Einfach halt Sachen, die für das netzwerk und das Monitoring notwendig sind. Warum das so spartanisch ausfällt, ist ganz einfach. Der Server, den wir als erstes einrichten, dient als Template für alle weiteren Server. Das heisst, dass wir diesen Server selbst eigentlich nie in Betrieb nehmen, sondern nur Kopien von diesem Server.
Um den Server zu installieren, starten wir den Assistenten und wählen die für uns passenden Optionen aus. In vielen Fällen bietet VMware die für uns passende Option mit an. Nur selten muss man auf eine etwas allgemeinere Option zurückgreifen. Ich habe bei mir die Option Typical und dann SuSE Linux 64bit ausgewählt. Dann den Namen für das System habe ich so belassen, wie vorgegeben und lediglich noch den Zusatz Template hinzugefügt. Als Netzwerkverbindung habe ich “Use bridged networking” gewählt (aber dazu gibt es später noch ne Anmerkung). Erst noch die Festplatte definieren. Die Grösse hängt natürlich vom Verwendungszweck ab. Ein virtuelles System kann durchaus mit 500MB klar kommen, dann dürfen halt die Logfiles nicht so lange gespeichert werden und es haben nicht soviele Daten drauf Platz. 2GB dürften aber für ein kleines System mehr als ausreichend sein. 8GB - wie vorgeschlagen empfinde ich als zu üppig, weshalb ich den Mittelweg wähle von 5GB. Diese lasse ich auch in 2GB Happen zerlegen. Mit einem Klick auf “Fertigstellen” ist dann die Maschine auch schon fertig.
Jetzt kann man das virtuelle System noch fein justieren. An einem Server braucht man z.B. kein Floppy, keine Soundkarte und auch kein USB. Das sind Hardwarekomponenten, die man getrost entfernen kann. Evtl. muss man auch den Hauptspeicher unseres neuen vServers anpassen. Wieviel man der einzelnen Maschine zugesteht, hängt vom Hauptspeicher des Rootservers selber ab und davon, wieviel virtuelle Server man betreiben möchte. Leider habe ich erst nach einigen Abstürzen dann festgestellt, dass ich zuviel erwartet habe. Das Hostsystem möchte dann auch noch etwas Hauptspeicher übrig haben. Und so muss man an dieser Stelle ein bisschen kalkulieren. Es schaut auch so aus, als wenn VMware bei der Simulation eines 64bit rechners mehr RAM benötigt, als bei einem 32bit System. Jedenfalls waren 4x 128MB für die virtuellen Server zuviel. Diese sind bei der kleinsten Beanspruchung schon in die Knie gegangen bzw. haben komplett den Geist aufgegeben. Mit 3x 128MB läuft es nun recht smooth. Anderst als man erwarten möchte hat das Hostsystem aber 700MB für die Gastsysteme reserviert. Damit meine ich, dass da ein Überhang von 316MB vorhanden ist. Das ist wohl das Mehr, das VMware für die 64bit benötigt. Zusätzlich wird das ganze auch noch von der Einstellung beeinflusst, wieviel Speicher “geswapped” werden soll/darf. Zu finden sind die Einstellungen unter Host-> Settings und im Dialog auf dem Reiter “Memory”.
So und bevor die Installationsorgie nun endgültig losgeht, muss man natürlich noch das Image der Start CD dem virtuellen CD-ROM zuordnen. Ist das auch Okay, dann kann es losgehen, und startet den ersten virtuellen Rechner mit einem Klick auf den grünen Pfeil. Wer eine langsame Leitung hat, muss alerdings schnell sein. Da kann es schon mal vorkommen, dass zwischen dem was gerade tatsächlich passiert und dem, was man sieht etwa 5 Sekunden liegen. Aber Übung macht den Meister. Also jetzt wird installiert!!!
Bei der Installation stösst man unweigerlich auf die Netzwerkkonfiguration. Und das kan je nach Provider entweder ganz normal laufen, oder auf dem herkömmlichen Weg überhaupt nicht funktionieren. (Das war eigentlich das einzige, was ich hier beschreiben wollte 
Folgende Konstellationen wären denkbar:
Der virtuelle Server bekommt eine offizielle IP Adresse und ist über diese erreichbar. (z.B. bei Kolido möglich. Und das ist der bestmögliche Fall)
Der virtuelle Server kann zwar über das Bridged Network betrieben werden, aber die offizielle IP ist nicht erreichbar. (z.B. 1&1. Ist nicht so schön - aber auch kein grösseres Problem)
Der virtuelle Server kann nicht über das Bridged Network betrieben werden. (auch dafür gibt es eine Lösung)
Und als konsequente Fortsetzung der Liste. Immer wenn der virtuelle Server seine Netzkarte (Bridged Network) aktiviert, wird der Rootserver vom Netz getrennt. (Das ist böse - aber auch dafür gibt es eine Lösung.)
Auf den 1. Fall muss man nicht näher eingehen. Da ist alles ganz normal und so wie man das auch an einem realen rechner machen würde.
Die restlichen Möglichkeiten haben dann einiges gemeinsam. Man kann die offizielle IP nicht direkt eintragen. In dem Fall muss man ein lokales, privates Netz innerhalb des Rootservers aufbauen. Dabei hat das Hostsystem also der Rootserver selber die Funktion des Routers und muss den dann natürlich auch entsprechend konfigurieren. Die Gastsysteme bekommen in dem Fall je eine private Adresse und als Standardgateway wird die PRIVATE IP des Rootservers eingegeben.
Im Detail heisst das, beim Rootserver selber muss ip forwarding muss aktiviert werden. Der Rootserver braucht eine private Adresse. Ich habe die IP 192.168.1.254 gewählt. Die offizielle IP muss ebenfalls auf dem Rootserver eingerichtet werden. Und zum Schluss brauchen wir noch ein paar Regeln für iptables damit der Traffik, der für die virtuelle Maschine gedacht ist auch ankommt und beantwortet werden kann.
#!/bin/bash
IPTABLES=/usr/sbin/iptables
IFCONFIG=/sbin/ifconfig
GATEWY=192.168.1.254
IPVM01=192.168.1.1
IPRM01=86.105.74.241$IFCONFIG eth0:0 $GATEWY netmask 255.255.255.0 up
$IFCONFIG eth0:1 $IPRM01 netmask 255.255.255.255 broadcast $IPRM01 up$IPTABLES -F
$IPTABLES -t nat -F
$IPTABLES -Xecho “1″ > /proc/sys/net/ipv4/ip_forward
$IPTABLES -t nat -A POSTROUTING -o eth0 -s $IPVM01 -j SNAT –to-source $IPRM01
$IPTABLES -t nat -A PREROUTING -d $IPRM01 -j DNAT –to-destination $IPVM01
$IPTABLES -t nat -A OUTPUT -d $IPRM01 -j DNAT –to-destination $IPVM01
Beim vServer ist dann lediglich die private IP einzutragen, in meinem Fall 192.168.1.1 für den ersten vServer und als Standardgateway die private Adresse des Rootservers 192.168.1.254.
Und für die letzten 2 Varianten, also da wo kein Bridged Network möglich ist, da bekommt man das ganze zum laufen, indem man noch eine zusätzliche Route für das private Netz 192.168.1.0 über das entsprechende Interface von VMware einträgt.
In meinem Fall wäre das vmnet1 mit der IP 172.16.131.1
#route add 192.168.1.0 gateway 172.16.131.1
Anmerkungen:
Wenn der erste vServer als Template eingerichtet wird, sollte man dem eine IP zuordnen, die man nicht vorhat zu benutzen. Angenommen man gibt dem Template die Adresse 192.168.1.1. für den ersten echten vServer. Dann hat man bei jedem weiteren vServer, den man aufsetzt (aus dem Template heraus erstellt.) das Problem, dass dieser einen Konflikt auslöst mit dem ersten server, den man schon installiert hat. Also besser dem Template eine IP wie 192.168.1.111 verpassen. Und wenn man dann das kopierte Template das erste mal hochfährt, dann die richtige IP zuordnen.
Bei VMware Workstation gibt es die Option “Clone erstellen”. Das haben wir bei VMware Server leider nicht. Deshalb auch der Vorschlag mit dem Template. Ein solches Template kann man dann auf Filesystemebene in ein weiteres Verzeichnis kopieren und über den Client laden.
#cp /srv/vm/template /srv/vm/wwwsrv02 -pr
und im VMware Client dann mit Open -> Browse -> /srv/vm/wwwsrv02/*vmx öffnen.
Beim Starten eines so kopierten vServers kommen dann einige Hinweise vor allem zur Netzwerkkarte und einer eindeutigen ID des Systems. Das muss natürlich aktzeptiert werden, da es sonst zu Konflikten zwischen den Maschinen kommt.
Und zum Schluss: Es hat mich jede Menge Zeit gekostet, die Systemzeit der einzelnen virtuellen Rechner stabil zu hinzubekommen. aber das ist ein anderes Thema und wird in einem neuen Beitrag beschrieben. Nur soviel: Bei der NAT-Lösung scheint NTP nicht zu funktionieren.
Danke für Kritik, Anregungen und Lobeshymnen
sonnige Grüsse
HaPe
Hi Danke für das schöne Tutorial ich habe eine Frage dazu:
ich habe auch das Problem, dass mein Kernel nicht unterstützt wird.
Jedoch finde ich keine config.h auf meinem server?
Nur eine in /usr/include/linux die ist jedoch leer?
Was mach ich nun?
Vielen Dank schonmal
Danke für das Lob!!!
VMware möchte die Sourcen installiert haben. die liegen dann unter /usr/src/linux Das ist meist ein Softlink auf das Verzeichnis mit der Versionsangabe im Namen, auf gleicher Ebene.
Die installierten Sourcen sollten von der Version her, so nahe wie nur möglich an der des Kernels liegen.
Du kopierst nun aus dem Verzeichnis /boot die config Datei, in das Verzeichnis /usr/src/linux. Dann gehst Du in dieses Verzeichnis. Dort führst Du den Befehl
# make menuconfig
aus. Dafür müssen auch die Sourcen von ncurses installiert sein.
Wenn Du dann im Config bist, lädst du die vorher kopierte Datei ins Config. Du gehst wieder aus dem Config raus. Hier wirst Du gefragt, ob Du die Änderungen speichern möchtest. Selbstverständlich bestätigst Du das mit Ja.
Zum Abschluss, wenn das Config wieder beendet ist, noch den Befehl
# make
ausführen.
Jetzt hast Du die neue version.h, da wo sie auch VMware sucht.
Der Rest geht dann wie oben beschrieben.
sonnige Grüsse
HaPe
Servus,
danke für das HowTo, das ist genau was ich gesucht habe. Ich hab mich quasi als Untermieter auf einem Strato Server niedergelassen mit eine 2. IP bestellt und dann den VmWare server aufgesetzt.
Jetzt hätte ich da noch ein paar Fragen, mein Setup sieht folgendermaßen aus: Der Server hat eine reale Karte, eth0, der sind zwei Adressen zugeordnet: 1.1.1.1 auf eth0 und 1.1.1.2 auf eth0:1 dann gibt es da noch die vmnet1 (192.168.50.1), die “steckt” in einem Virtuellen LAN in dem auch meine Virtuelle Maschine steht (192.168.50.3) Ich habe das code Beispiel oben für mich so interpretiert:
GATEWY=192.168.50.1 (der Root Server)
IPVM01=192.168.50.3 (die Gastmaschine)
IPRM01=1.1.1.2 (die 2. offizielle IP)
Wenn ich den code oben entsprechend anpasse, und laufen lasse, tut sich leider nicht allzuviel
ich seh bestimmt den wald vor lauter Bäumen nicht mehr.
Daher meine Fragen:
wofür ist das eth0:0, warum wird das angelegt?
wo kommt denn im Beispiel “#route add 192.168.1.0 gateway 172.16.131.1″ die 172er Adresse her?
Warum gehts bei mir nicht
Danke schon mal
Ingo
Das Beispiel mit der Adresse 172.16.131,1 ist eben genau das Beispiel mit dem vmnet1 das VMware für mich eingerichtet hat. Also wenn man das Guestsystem per Bridgednetwork betreiben möchte. Und so wie ich das sehe, möchtest Du das genau so einrichten.
Das einzige, was mir bei Deinem Problem einfällt, ist dass vielleicht das Forwarding bei Dir nicht greift. Das wird mit
echo ?1? > /proc/sys/net/ipv4/ip_forward
aktiviert. Und Du kannst es kontrollieren, mit
cat /proc/sys/net/ipv4/ip_forward
Bei diesem Befehl muss ne 1 rauskommen. Alles andere ist falsch.
Und wenn das auch nicht hilft, dann bräuchte man mehr Infos, um dem genau nachzugehen.
Das wären die genauen Befehlszeilen die Du in der Konsole in welcher Reihenfolge eingibst, was genau in Deinen Skripten steht und zum Schluss eben auch wie Netzkarten konfiguriert sind. Das wären dann die Ausgaben von ifconfig und route, sowohl auf dem Host als auch auf dem Gastsystem.
übrigens
Gern geschehen
sonnige Grüsse HaPe
Servus HaPe,
ich hab mich nochmals eingehend mit Deinem Script und meiner VM befasst, ich denke ich hab das jetzt soweit alles hinbekommen, was mit jetzt noch fehlt ist ein kleiner Hinweis, wo bridge ich die Gastnetzwerkkarte hin?
Also Mein Setup sieht ja so aus: eth0 HostServer Public IP, eth0:1 192.168.1.254 von Deinem Script, eth0:2 Gastsystem Public IP von Deinen Script, vmnet1 192.168.1.1 Host only networking für die VM Clienten.
Die VmWare Config sieht folgendermaßen aus: vmnet0 BR=> eth0, vmnet1 => hostonly, vmnet2 BR=> eth0:2
Wenn ich in der VmWare einstelle sie soll hostonly networking benutzen, dann ist sie ja im 192.168.1.0er netz aber das ist ein Vlan oder? denn der gast kann die 192.168.1.254 (eth0:1) nicht anpingen. Wenn ich den Gast auf Vmnet2 bridge, dann kommt er auch nicht raus, dann kam mir die Idee, den Gast auf eth0:1 zu bridgen, aber das hat leider auch nicht gehofen. Was für Gast Netzwerkeinstellungen hast Du denn vorgenommen.
Liebe Grüße einstweilen und frohes Fest.
Ingo
Hallo HaPe,
das Tutorial ist super! Wie lange ich nach so etwas gesucht habe. Ich habe sogar nun endlich die Version.h “gefunden”, dank dem Kommentar und der Antwort hier unten.
Ein Problem habe ich noch mit der Netzwerkkonfiguration. Ich hoffe du kannst mir helfen.
Ich habe einen 1und1-rootserver. auch noch eine zusätzliche IP… aber irgendwie will er nicht ins netz.
Ich habe Bridged-Networking eingestellt und die IP statisch auf der VM … aber das funtkioniert wohl nicht bei 1und1 (laut dem tutorial), oder?
So richtig habe ich die andere Vorgehensweise aber nicht verstanden. Kannst du mir noch einmal genau erklären was ich auf welchem Server (root/vm) einstellen muss, so dass die vm per eigenen IP erreichbar ist?
Vielen Dank für eine Antwort im Voraus und noch einmal für die sehr gute Anleitung hier.
Viele Grüße,
Alex
Hiho,
Dir gehört für dieses Tut ein Denkmal errichtet!
Hat bei mir (Strato-Rootserver) wunderbar funktioniert!
Vielen vielen Dank,
Johannes
PS: Vielleicht wär es nicht schlecht, wenn eine Notiz dazukäme, dass die hintere IP bei dem “route”-command bei einem “ifconfig” im Abschnitt vmnet1 steht.
Hi Alex,
Danke für das Lob!!!
Speziell für 1&1 müssen der Gast und das Hostsystem in einem privaten Netz miteinander kommunizieren können. Auf dem Host die für das Gastsystem bstimmte öffentliche IP eingerichtet und IP Forwarding muss aktiviert sein. Zusätzlich benötigst Du dann noch das Masquerading, in dem die öffentliche IP für das Gastsystem auf die private IP des Gastsystems weitergeleitet wird.
Ich hoffe diese Anhaltspunkte helfen Dir weiter. Die Details stehen oben ja schon beschrieben.
Hi Johannes,
Danke für das Lob!!! Aber ein Denkmal ist doch nicht nötig
… Oder!? Na schlecht wärs auch nicht 
Und danke für Deinen Hinweis!
Hi HaPe,
nach so einem Tutorial hab ich gesucht. Vielen Dank! Installation ging ohne Probleme. VM installiert + läuft.
Allerdings habe ich ein Problem (Skript wie o.g. angepasst und ausgeführt).Zwischen der VM und dem Host kann ich kommunizieren. Nur kann ich von der VM nicht aufs Internet zugreifen / Internet -> VM. Was mache ich falsch? Provider ist EinsUndEins.
Viele Grüße
Joerg
Hallo Joerg,
damit Du mit dem Gastsystem mit der Aussenwelt kommunizieren kannst, sind das die wichtigsten Punkte.
Du benötigst auf Deinem Hostsystem, für das Gastsystem eine extra IP Adresse.
In der Firewall (iptables) von Deinem Hostsystem muss das Masquerading eingerichtet sein.
Im Hostsystem muss das Forwarding aktiviert sein.
Die Punkte sind oben beschrieben.
Lass es mich wissen, ob Dir die Hints geholfen haben, und wenn ja, woran es gelegen hat.
sonnige Grüsse
HaPe
Hallo,
also irgendwie scheine ich dafür zu dumm zu sein *g*
Der Root-Server hat nur eine IP, somit fällt bridging weg und ich habe NAT eingerichtet.
Ich kann auf dem Gast auch im Internet surfen, aber meine Port-Forwoardings funktionieren nicht.
Host: Debian
Gast: WinXP
Ich habe das vmnat config File editiert und die gewünschten Ports eingetragen und danach die vmware neu gestartet.
Ich habe auf dem Server die Ports per Iptables geöffnet, bsp.:
- iptables -A OUTPUT -p tcp –dport 5900 -j ACCEPT
- iptables -A INPUT -p tcp –dport 5900 -j ACCEPT
Was mache ich falsch?
Wäre echt klasse wenn du mir helfen könntest.
mfg
Hallo Martin,
einzelne Ports forwarden, ist natürlich auch machbar, da ich das aber nicht testen kann, und für die genauen iptables-Regeln selbst nachlesen müsste, verweise ich Dich mal aufs Internet
Es wird sich sicher auf Anhieb ein passender Regelsatz in einem Howto finden lassen.
Und … zu dumm kann nicht sein
das Gastsystem kann nach aussen kommunizieren, und somit funktioniert das IP-Forwarding und das Masquerading. Ergo diesem meinem Howto entsprechend zu 100% richtig umgesetzt.
sonnige Grüsse
HaPe
Hallo,
danke für den Beitrag. Habe eine Frage, habe einen Rootserver von Strato zur Verfügung, dieser hat auch zwei IPs. Kann mir jemand sagen, ob der Betrieb von Bridging bei Strato möglich ist? Habe bereits selber herumprobiert, leider ohne Erfolg bisher. Ein Ping von der VM scheitert schon bei der Auflösung der MAC-Adresse des Routers von Strato.
Wie findet Strato überhaupt heraus, dass ich eine VM verwende? Würde es evtl. helfen die MAC Adresse der VM zu verändern?
Gruß
coin3d
Hi,
höchstwahrscheinlich wird es daran liegen, dass die MAC Adresse abgefangen wird. Deshalb eben auch dieses Tutorial. Ob ein einfaches ändern der MAC Adresse Abhilfe schafft steht 50/50. Wenn Du es probierst, würde ich mich über den Bericht freuen. Versuch dann aber eine MAC Adresse zu finden, die nicht für VMware vergeben ist, und nicht in der unmittelbaren Umgebung Deines Servers. Oder besser gesagt, wenn Du das schon probieren möchtest, dann nimm die MAC von einer alten Karte. Vielleicht hast Du ja noch eine zuhause rumliegen. Einfach eine MAC aufs gerade Wohl zu erraten, dürfte nicht so prickelnd sein.
Ansonsten bleibt eigentlich nur noch die hier vorgeschlagene Lösung, indem Du auf dem Server ein kleines privates Netz aufbaust und dann per Masquerading nach aussen gehst.
Warum Strato weiss, dass der Ping nicht von einem echten Starto-Server kommt kann meiner Einschätzung nach 4 Möglichkeiten haben.
1. Strato hat von vorneherein einen Filter drin, in dem die ungewünschten MAC Adressen enthalten sind. Das wäre sogar verhältnismässig einfach, VMware damit auszuschliessen. Da in der MAC Adresse ja auch der Hersteller seinen Code verewigen MUSS.
2. Starto vergibt die IP-Adressen, wie auch bei 1&1, die IP Adressen per DHCP mit einer ewig langen Verfallsdauer. Dann wäre die IP Adresse schon bei der Vergabe und dem ersten Lebenszeichen der IP fest mit der MAC Adresse verknüpft. Und dann hat eine 2. Netzkarte keine Chance mehr diese IP an sich zu reissen.
3. Strato verbaut immer die gleichen Netzkarten. Zumindest ist zu erwarten, dass es nur eine Handvoll versch. Hersteller sind. damit könnte man eine Whiteliste bauen. Obwohl ich das eher für unwahrscheinlich halte.
4. Der 1. Router zu Deinem Server, muss ja wissen, wo er die Pakete für diese IP hinschicken soll. Bzw. er ist eigentlich der einzige, der es wirklich weiss. Alle anderen Router arbeiten dann nur noch mit Netzsegmenten. Diese Einrichtung geht wohl auch automatisch, bei der Vergabe der IP vonstatten. Und auch hier merkt sich der Router die MAC.
Naja ne 5. Möglichkeit gibt es doch noch. nämlich eine gesunde Mischung aus den vorherigen 4 Möglichkeiten.
Das alles sind aber nur Vermutungen. Genau wissen wird das wahrscheinlich nur der Oberaufseher vom Rechenzentrum von Strato
sonnige Grüsse
HaPe
Hallo Hape,
danke für deine schnelle Antwort. Ich habe schon den ganzen Tag rumgespielt, ich habe dabei das zweite Interface heruntergefahren (eth1) und mir die MAC Adresse des Interfaces gemopst, diese dann in der Knoppix-VM per ifconfig eingestellt, das Knoppix eth0 dann auf eth0 des Servers gebridged, und und und…leider habe ich auch mit anderen VM-seitigen Problemen auf dem Server zu kämpfen. Ich krieg z.B. keine Bridge auf ein virtuelles eth0:1 zum laufen. Nix nullo, keine MAC-Auflösung. Hattest du damit auch schon mal Probleme oder ist dir das neu? Kann natürlich auch an meinem verfrickeltemn Gentoo liegen..
Gruß
Hallo,
leider kann ich Dir da gar keine konkrete Auskunft geben. Ausser vielleicht…
Nach einem Neustart von VMware muss es eigentlich möglich sein, zumindest in der VMware Console das Bridged Network einzurichten. Wenns dann noch nicht nach aussen geht, kann es an dem bisher besprochenem liegen. Wenn Du aber von vorneherein das Bridged Dings nicht aktivieren kannst, liegt es vermutlich an was anderem.
Am besten wäre natürlich schon, wenn sogar Du selbst schon feststellst, dass Deine Grundinstallation verkorkst ist, dass Du das einfach mal komplett neu installierst oder installieren lässt.
Im Zweifelsfall, wenn Du nicht mehr weiter weisst, dann solltest Du auch mal die Logfiles zu Rate ziehen. Und - ganz wichtig - auch VMware schreibt Logfiles. Diese findest Du - so zumindest bei mir - unter /var/log/vmware.
Sonnige Grüsse
HaPe
P.S.: Achja, nicht so vorschnell loben! ich bin nicht immer so schnell
Habe ein Problem:
server:/scripts# ./ip-vm
Bad argument `62.75.255.xx’
Try `iptables -h’ or ‘iptables –help’ for more information.
Bad argument `192.168.1.1′
Try `iptables -h’ or ‘iptables –help’ for more information.
Bad argument `192.168.1.1′
Try `iptables -h’ or ‘iptables –help’ for more information.
Hier das Script
#!/bin/bash
IPTABLES=/sbin/iptables
IFCONFIG=/sbin/ifconfig
GATEWY=192.168.1.254
IPVM01=192.168.1.1
IPRM01=62.75.255.xx
$IFCONFIG eth0:0 $GATEWY netmask 255.255.255.0 up
$IFCONFIG eth0:1 $IPRM01 netmask 255.255.255.255 broadcast $IPRM01 up
$IPTABLES -F
$IPTABLES -t nat -F
$IPTABLES -X
echo “1″ > /proc/sys/net/ipv4/ip_forward
$IPTABLES -t nat -A POSTROUTING -o eth0 -s $IPVM01 -j SNAT -to-source $IPRM01
$IPTABLES -t nat -A PREROUTING -d $IPRM01 -j DNAT -to-destination $IPVM01
help plz
Hallo nochmal,
wollte mich nochmal bzgl. des aktuellen Status melden. Leider ist es mir nicht gelungen, über die zweite MAC-Adresse eine VMWare zu betreiben. Ich glaube das liegt daran, dass die Änderung in der VMWare der MAC-Adresse keine Wirkung hat, da VMWare selbst von der MAC-Adresse “Bescheid” wissen muss. Dies ist aber leider nicht möglich, da nur ein sehr eingeschränkter MAC-Adresspool für die virtuellen Maschinen seitens VMWare Server zur Verfügung steht.
Deine NAT-Vorgehensweise funktioniert aber auch super. Habe auch mal ein wenig mit IPTables herumgespielt, um “ganz normales” NAT an der ersten IP betreiben zu können. Ist also auch nützlich für Leute, die nur eine IP Adresse zur Verfügung haben. Hier ist mal der Code:
iptables -F
iptables -t nat -F
iptables -X
echo “1″ > /proc/sys/net/ipv4/ip_forward
iptables -A FORWARD -s 192.168.0.2 -j ACCEPT
iptables -A FORWARD -p tcp –dport 3389 -d 192.168.0.2 -j ACCEPT
iptables -A FORWARD -d 192.168.0.2 -m state –state ESTABLISHED,RELATED -j ACCEPT
iptables -t nat -A PREROUTING -p tcp –dport 3389 -j DNAT –to 192.168.0.2:3389
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
Die 192.168.0.2 ist in diesem Fall die IP meiner VM, ich habe in diesem Beispiel den Port 3389 (Windows Remote Desktop) geforwarded.
Gruß
coin3d
Hallo!
Hab noch ein Problemchen. Mein Host (Suse) hat nur eine IP, der Gast(XP) ist über NAT angebunden. Raus kommt der Gast super, rein kommt gar nichts. Das VMWare eigene NAT läuft irgendwie nicht. Ich hab die Ports da eingetragen, aber sie kommen nicht durch.
Jetzt wollte ich Host-Only benutzen und über die Host-Firewall Routen bzw. Maskieren. Das soll über Yast gehen. Ich hab auch deinen Weg oben versucht. Er macht es irgendwie einfach nicht… Kann mir jemand mal genau schreiben wie ich vorgehen muss? Gerne auch per ICQ. (82-757-268) Vielleicht hab ich auch nur zwei IPs vertauscht.
Christian
Hallo !
Es ist nicht möglich bei VMware die MAC Adresse des Servers zu spoofen. Beim Versuch beschwert sich der Server, dass die Adresse nicht zugelassen ist. Nur VMware eigene MACs sind erlaubt.
Wie das geht könnt ihr hier sehen:
http://virtrix.blogspot.com/2007/04/vmware-configuring-static-mac-address.html
http://www.fedorawiki.de/index.php/VMware
Ferner muss ich erwähnen, dass auch bei Server4you der Betrieb von VMware ziemlich unmöglich ist.
Die NAT/iptables Lösung ist OK, aber für uns leider nicht anwendbar … Asterisk ist keine Freude!
Alex
Wie kann man das ganze unter Windows Server 2003 Webedition realisieren?
hi, ich bin zufällig auf dieses tutorial gestossen (btw danke dafür), aber ich kriegs irgendwie nicht gebacken. ich schaff es nicht, dein rule an die output chain anzufügen, ich krieg immer:
iptables v1.3.5: Unknown arg `DNAT’
dabei ist DNAT ja für die output chain gültig, ich verstehs nicht…
Hallo!
Ich installiere gerade auf einem Strato-Rootserver “(Heul-)Suse 10.0″ VMWare-Server 1.04 und bin auf der vmware-config.pl auf folgendes Problem gestoßen:
The directory of kernel headers (version 2.6.13-15-default) does not match your
running kernel (version 2.6.13-15.15-default). Even if the module were to
compile successfully, it would not load into the running kernel.
Ich habe sogar nach kernel-header rpm’s gesucht, aber nix passendes gefunden!
Zu Hause funktioniert die Installation auf jeden ubuntu einwandfrei, sogar auf warty warthog 4.10!!!
wie sehen die configs aus, wenn man eine smoothwall als erste vm fahren will ???
Hallo HaPe,
du hast eine tolle Anleitung geschrieben, vielen Dank.
Der erste Teil funktioniert soweit, jedoch hängt es beim zweiten Teil (Netzwerk).
Ich habe einen 1-und-1-Server mit Debian Linux. Dieser hat 2 öffentliche IP-Adressen die auf eth0 eingerichtet sind. Die VM und der Rootserver befinden sich in einem HostOnly-Netzwerk mit den IPs 192.168.214.1 (RS) bzw. 192.168.214.128 (VM).
Was muss ich nun genau alles eingeben, damit die VM im Internet erreichbar ist unter einer der beiden öffentlichen IPs und auch das Internet erreichen kann.
Ich habe bereits dein Skript oben auf dem RS ausgeführt, denke aber dass ich falsche Werte verwende. Besonders “das zusätzliche Netzwerk” 192.168.1.1 verwirrt mich. Wieso brauch man das? Geht das nicht direkt zum HostOnly-Netzwerk durchzuleiten?
Ich würde mich freuen, wenn du mir behilflich sein kannst.
Viele Grüße,
Wiedsche
Hallo,
das ist echt ein super Tut! Klappt hervorragend bei mir. Allerdings habe ich mehrere feste IPs und möchte nun noch eine IP an eine andere VM übergeben. Daher habe ich mir das Script mehrfach angepasst, aber wie ich es auch dreh, es ist immer nur die erste IP erreichbar.
—————————————-
Probiert #1:
#!/bin/bash
IPTABLES=/usr/sbin/iptables
IFCONFIG=/sbin/ifconfig
GATEWY=192.168.1.254
IPVM01=192.168.1.1
IPRM01=86.105.74.241
IPVM02=192.168.1.2
IPRM02=86.105.74.242
$IFCONFIG eth0:0 $GATEWY netmask 255.255.255.0 up
$IFCONFIG eth0:1 $IPRM01 netmask 255.255.255.255 broadcast $IPRM01 up
$IFCONFIG eth0:2 $GATEWY netmask 255.255.255.0 up
$IFCONFIG eth0:3 $IPRM02 netmask 255.255.255.255 broadcast $IPRM02 up
$IPTABLES -F
$IPTABLES -t nat -F
$IPTABLES -X
echo ?1? > /proc/sys/net/ipv4/ip_forward
$IPTABLES -t nat -A POSTROUTING -o eth0 -s $IPVM01 -j SNAT ?to-source $IPRM01
$IPTABLES -t nat -A PREROUTING -d $IPRM01 -j DNAT ?to-destination $IPVM01
$IPTABLES -t nat -A OUTPUT -d $IPRM01 -j DNAT ?to-destination $IPVM01
$IPTABLES -t nat -A POSTROUTING -o eth0 -s $IPVM02 -j SNAT ?to-source $IPRM02
$IPTABLES -t nat -A PREROUTING -d $IPRM02 -j DNAT ?to-destination $IPVM02
$IPTABLES -t nat -A OUTPUT -d $IPRM02 -j DNAT ?to-destination $IPVM02
—————————————
Probiert #2:
#!/bin/bash
IPTABLES=/usr/sbin/iptables
IFCONFIG=/sbin/ifconfig
GATEWY=192.168.1.254
IPVM01=192.168.1.1
IPRM01=86.105.74.241
GATEWY2=192.168.1.254
IPVM02=192.168.1.2
IPRM02=86.105.74.242
$IFCONFIG eth0:0 $GATEWY netmask 255.255.255.0 up
$IFCONFIG eth0:1 $IPRM01 netmask 255.255.255.255 broadcast $IPRM01 up
$IFCONFIG eth0:2 $GATEWY2 netmask 255.255.255.0 up
$IFCONFIG eth0:3 $IPRM02 netmask 255.255.255.255 broadcast $IPRM02 up
$IPTABLES -F
$IPTABLES -t nat -F
$IPTABLES -X
echo ?1? > /proc/sys/net/ipv4/ip_forward
$IPTABLES -t nat -A POSTROUTING -o eth0 -s $IPVM01 -j SNAT ?to-source $IPRM01
$IPTABLES -t nat -A PREROUTING -d $IPRM01 -j DNAT ?to-destination $IPVM01
$IPTABLES -t nat -A OUTPUT -d $IPRM01 -j DNAT ?to-destination $IPVM01
$IPTABLES -t nat -A POSTROUTING -o eth0 -s $IPVM02 -j SNAT ?to-source $IPRM02
$IPTABLES -t nat -A PREROUTING -d $IPRM02 -j DNAT ?to-destination $IPVM02
$IPTABLES -t nat -A OUTPUT -d $IPRM02 -j DNAT ?to-destination $IPVM02
Vielleicht kann mir ja jemand helfen, wie ich mehrere IPs über mehrere Server nutzen kann…
Vielen Dank!
Lösung bereits gefunden, trotzdem DANKE und vorallem für die super Hilfe!
Einfach zweite config anlegen, den gateway kann man dann rauslassen, sonst gibts Fehlermeldungen, da die IP schon auf einem Interface gemappt ist, oder einfach einen weiterne GW mit ner anderen IP (z.b. .253) anlegen. Ist aber nicht nötig. Klappt super mit 3 Maschinen nun, alle mit öffentlichen IPs.
[...] to make a VMWare client available from the internet with his own public IP, I found the answer on kex.cc. This script will configure your IPTables to pass trough the traffic to your VMWare [...]
[...] aus dem Internet die VMClients mit eigenen, öffentlichen IP’s zu erreichen, habe ich auf kex.cc eine gute Lösung gefunden. Mit diesen IP Tables war es nun problemlos möglich auf meine VMWare [...]
Ich will VMWARE betreiben doch leider funktioniert das noch nicht. VMware funktioniert, ich kann vom main aus die vmclients pingen und per ssh connecten. aber die öffentliche ip routet noch nicht auf den vm-client, aber ausgehend verwended der client die ip die zugeteilt wurde.
————————————————————————-
#!/bin/bash
IPTABLES=/usr/sbin/iptables
IFCONFIG=/sbin/ifconfig
GATEWY=192.168.1.1
IPVM01=192.168.1.10
IPVM02=192.168.1.20
IPVM03=192.168.1.30
IPVM04=192.168.1.40
IPVM05=192.168.1.50
IPRM01=78.47.76.82
IPRM02=78.47.76.83
IPRM03=78.47.76.84
IPRM04=78.47.76.85
IPRM05=78.47.76.86
$IFCONFIG eth0 $GATEWY netmask 255.255.255.255 up
$IFCONFIG eth0:0 $IPRM01 netmask 255.255.255.255 broadcast $IPRM01 up
$IFCONFIG eth0:1 $IPRM02 netmask 255.255.255.255 broadcast $IPRM02 up
$IFCONFIG eth0:2 $IPRM03 netmask 255.255.255.255 broadcast $IPRM03 up
$IFCONFIG eth0:3 $IPRM04 netmask 255.255.255.255 broadcast $IPRM04 up
$IFCONFIG eth0:4 $IPRM05 netmask 255.255.255.255 broadcast $IPRM05 up
$IPTABLES -F
$IPTABLES -t nat -F
$IPTABLES -X
echo ?1? > /proc/sys/net/ipv4/ip_forward
# 1. ip routen
$IPTABLES -t nat -A POSTROUTING -o eth0:0 -s $IPVM01 -j SNAT -?to-source $IPRM01
$IPTABLES -t nat -A PREROUTING -d $IPRM01 -j DNAT ?-to-destination $IPVM01
$IPTABLES -t nat -A OUTPUT -d $IPRM01 -j DNAT ?-to-destination $IPVM01
# 2. ip routen
$IPTABLES -t nat -A POSTROUTING -o eth0:1 -s $IPVM02 -j SNAT ?-to-source $IPRM02
$IPTABLES -t nat -A PREROUTING -d $IPRM02 -j DNAT ?-to-destination $IPVM02
$IPTABLES -t nat -A OUTPUT -d $IPRM02 -j DNAT -?to-destination $IPVM02
# 3. ip routen
$IPTABLES -t nat -A POSTROUTING -o eth0:2 -s $IPVM03 -j SNAT -?to-source $IPRM03
$IPTABLES -t nat -A PREROUTING -d $IPRM03 -j DNAT -?to-destination $IPVM03
$IPTABLES -t nat -A OUTPUT -d $IPRM03 -j DNAT ?-to-destination $IPVM03
# 4. ip routen
$IPTABLES -t nat -A POSTROUTING -o eth0:3 -s $IPVM04 -j SNAT -?to-source $IPRM04
$IPTABLES -t nat -A PREROUTING -d $IPRM04 -j DNAT ?-to-destination $IPVM04
$IPTABLES -t nat -A OUTPUT -d $IPRM04 -j DNAT -?to-destination $IPVM04
# 5. ip routen
$IPTABLES -t nat -A POSTROUTING -o eth0:4 -s $IPVM05 -j SNAT ?-to-source $IPRM05
$IPTABLES -t nat -A PREROUTING -d $IPRM05 -j DNAT ?-to-destination $IPVM05
$IPTABLES -t nat -A OUTPUT -d $IPRM05 -j DNAT -?to-destination $IPVM05
————————————————————————
siehst du hier n fehler? ich sehe nix falsches doch funktionierts ned.
danke schon im voraus
Dein Tutorial ist schön
keine Frage =)
Aber, NAT ist nie die gute Lösung. Allein schon wegen der Beschränkung der Bandbreite auf 10Mbit.
Gut, wie kann man das umgehen?
Ich kann hier nur eine Lösung für Server4you anbieten da ich nicht weiss wie die Router/Firewall Struktur von Strato etc. ist.
Ich führe ein Beispiel für eine Windowsmaschine auf.
Man nehme eine Windows Version und installiere sie auf seinem Server. Achtet bitte darauf das euere VmWare im Bridged Mode beim Netzweradapter ist!
Nach Abschluss oder während der Installtion müsst ihr die IP Einstellen die euch zugewiesen wurde. Als Gateway gebt ihr die Standard Gateway IP eures Servers an. Vergesst nicht die Subnetmask, auch wenn sich diese sicherlich unterscheidern wird von der ersten zugewiesenen IP.
Gut, all done? Weitergehts.
Wenn euer Windows nun gebootet ist geht ihr in die Hardwarekonfiguration. Wählt den Netzwerkadapter aus und wählt den Reiter “Erweitert”.
Hier sucht ihr euch nun den Punkt Lokale Adresse und fügt dort die Mac-Adresse euerer Netzwerkkarte ein. Natürlich auch wieder die, vom ersten Netzwerkadapter (meist eth0).
ICH WARNE EUCH AUSDRÜCKLICH ! SOLLTET IHR DIE MAC ADRESSE ÄNDERN OHNE DAS IHR SCHON ZUVOR DIE IP ADRESSE EINGESTELLT HABT WERDEN ALLE VERBINDUNG VON DEINEM SERVER DURCH VMWARE ÜBERLAGERT UND DU HAST OHNE REBOOT KEINEN ZUGRIFF MEHR AUF DEINEN SERVER!
Gut, wenn ihr die Adresse geändert habt wählt ihr jetzt könnt ihr testweise in den Internet Explorer, oder ähnliches gehen, und euch freuen das eure VmWare jetzt im Internet ist. Das gute ist, das die Ip-Adresse nun komplett allein der VmWare gehört und ihr könnt nun exrta Dienste wie einen Webserver, Email Server etc. dort laufen lassen.
Der Gewaltigste Vorteil ist gegenüber Nat, man sparrt sich den Streß mit IpTables und der Speed entspricht nun der eures Netzwerkadapters. Also wenn ihr 100mbit habt, habt ihr jetzt auch 100mbit in der VmWare statt 10mbit =)
Wenn ihr dennoch nicht klar kommt, könnt ihr euch gerne melden bei mir über meine E-Mail Adresse. Ich beantworte nur Fragen betreffend der Einrichtung des Bridged-Network Modus!
Liebe Grüße,
Stefan Popp
Wie kann ich das ganze “IP-Forwarding” unter Windows Server 2003 einrichten? VM Server läuft also auf Windows. Darauf dann eine VM mit Debian Linux. Wie kann ich eine komplette IP vom Windows-Server auf die VM weiterleiten? Bridged geht nicht. Ich möchte auch nicht nur einzelne Ports, bzw. sollen nur Ports einer bestimmten IP geforwardet werden. Der ans Internet angeschlossene LAN-Adapter hat 2 IP-Adressen … eine davon soll eben für die VM genutzt werden (wie Beispiel oben, jedoch kein Linux-Host sondern Windows).
Hat da jemand eine Idee?
Alex
irgendwie fehlte das Ende von meinem Post…deshalb hier nochmal:
Hallo,
ich habe das Tutorial wunderbar umsetzen können. Vielen Dank. Es funktioniert alles bestens - jedoch habe ich einen Bug entdeckt.
Versucht eine VM vom Hostsystem über die öffentliche-IP oder eine Domain einer anderern (oder der gleichen) VM irgendeinen Dienst aufzurufen, so antwortet die lokale IP-Adresse.
Hier ein Beispiel:
auf der VM1 wird aufgerufen:
> ping vm2.domain-xy.com
Ping wird ausgeführt für vm2.domain-xy.com [87.106.241.8] mit 32 Bytes Daten:
Antwort von 172.16.186.130: Bytes=32 Zeit < 1ms TTL=128
Die Anfrage ging also an 87.106.241.8 und die Antwort kommt von 172.16.186.130. Damit kommen viele Anwendungen nicht klar.
Wie kann man das umgehen? Hat jemand eine Idee?
Viele Grüße
Alex
Ein paar Anmerkungen zu Stefan Popps Kommentar:
Zunächst ein herzliches Danke, Danke, Danke!
Dein Hinweis war auch bei mir die Lösung des Problems. Ich habe einen Rootserver mit Windows 2008 bei Serverloft/Server4You gemietet und wollte (bei 6 GB RAM eigentlich selbstverständlich) einen VMWare Server 2.0 für diverse Software aufsetzen. Da 4 IPs im Preis drin sind, dachte ich mir, kein Problem, zichmal gemacht: Virtuelle Maschine (VM) aufsetzen, Netzwerkkarte bridgen und zusätzliche IP-Adresse in VM eintragen. Naja, funktionierte nicht. Der Support erklärte mir dann, dass die zusätzlichen IPs Aliase auf die erste Haupt-IP sind und auf den Switches nur die MAC-Adresse der Netzwerkkarte des Hostservers eingetragen werden…
Ich beschreibe hier mal die Konfiguration mit Windows 2008 Server als Host und einem Windows XP/2003/2008 als Gast in einer VM. Linux-Host/Windows-Guest wird schon weiter oben beschrieben (IP-Tables, sollte aber auch über die VMX-Datei gehen, ebenso die Variante Windows-Host/Linux-Gast).
Die Lösung ist hier dann, wie von Stefan Popp oben beschrieben, der gebridgeten virtuellen Netzwerkkarte ( die mit einer der zusätzlichen IP-Adressen) die MAC-Adresse des Lan-Interfaces des Hostservers beizubringen.
Dazu existieren zwei Möglichkeiten:
1. Siehe oben: In der VM die Eigensschaften des LAN-Adapters (Nicht der LAN-Verbindung!) aufrufen und unter Erweitert->NetworkAddress die MAC-Adresse des Hostservers ohne Trennzeichen eintragen.
2. Anpassen der vmx-Datei im Verzeichnis der VM auf dem Hostserver. Die MAC-Adresse kann NICHT über die VMWare-GUIs eingetragen werden, da hier nicht-VMWare Einträge gefiltert werden. Empfehlenswert ist aber die Konfiguration einer manuelle MAC-Adresse und keiner vom Host generierten. Dieses also zunächst über die GUI einstellen und bei mehreren VMs auf dem Host zunächst UNTERSCHIEDLICHE Adressen aus dem VMWare-Bereich zu wählen.
Als nächstes die vmx-Datei mit einem Texteditor (PSPad, notepad,…) öffnen und folgende Zeilen, so vorhanden, auf die MAC-Adresse des Hostservers ändern:
ethernet0.generatedAddress = “00:40:d0:df:fe:7b”
ethernet0.address = “00:40:d0:df:fe:7b”
“00:40:d0:df:fe:7b” wäre hier die MAC-Adresse des Hostservers.
Sinnvoll ist es die VMs NICHT automatisch zu starten, denn wenn was schiefgeht, hat man sonst ein Problem (Siehe auch Anmerkung von Stefan).
Damit die Anzeige in den GUI-Tools von WMWare dann auch richtig ist, kann man die VM einmal aus dem Inventory entfernen (natürlich die Dateien auf der Platte NICHT löschen) und danach neu importieren. Wenn jetzt die Eigenschaften der LAN-Verbindung geöffnet werden wird dort auch die “neue” MAC-Adresse angezeigt. Aber, wie gesagt, hier KEINE Änderungen vornehmen.
Dieses Verfahren funktioniert nur für EINE VM!!! Mehrere VMs mit der gleichen Host-MAC-Adresse funktionieren NICHT. Es wird immer die zuerst gestartete verwendet. Doch auch hier existiert eine Lösung:
1. Eine VM, wie oben beschrieben, konfigurieren. Zusätzlich eine weitere virtuelle Netzwerkkarte mit NAT konfigurieren und dieser eine statische IP geben (Siehe VMWare Doku).
2. Alle weiteren VMs mit einer NAT-Verbindung konfigurieren. Als Standardgateway die IP-Adresse der NAT-Netzwerkkarte aus 1. konfigurieren! NICHT die von VMWare vorgegebene IP des Hostservers. DNS und WINS können aber weiterhin die NAT-Adresse des Hostservers benutzen. Wichtig ist ggf. das die Kommunikation der VMs untereinander über die NAT-Adressen und nicht über die externen Adressen läuft. Hier muss dann die hosts-Datei angepasst werden (Per DNS ist z.b. http://www.xyz.de auf eine externe reale IP-Adresse gemappt. Wenn aber http://www.xyz.de auf einer der VMs läuft, dann darf http://www.xyz.de im NAT-Netz nicht über die externe IP aufgelöst werden. Daher in der hosts-Datei 192.168.x.y auf http://www.xyz.de mappen).
3. Je nach Betriebssystem der VM, muss dort jetzt NAT für die weiteren VMs konfiguriert werden. Bei Windows 2003 in der VM z.B. über den RAS/Routing-Manager. Dort beim externen LAN-Adapter alle zusätzlichen IPs angeben, die konfiguriert worden sind. Kein Mapping externe IP auf interne IP aufsetzen. Hat bei mir nicht funktioniert. Für jede gewünschte externe IP/Port Kombination ein Mapping auf die gewünschte VM NAT-Adresse und den entsprechenden Port einzutragen. Bei Linuxen können hier die IP-Tables benutzt werden.
Ein Hinweis noch zur Anzeige 10 MBit. Das wurde aufgrund des von VMWare emulierten LAN-Adapters angezeigt. Tatsächlich war die Geschwindigkeit immer sehr viel höher. In VMWare Server 2.0 hat man daher auch eine Gigabit-Adapter…
Just my 2 cents,
Jan