nicht angemeldet
Apache in einer virtuellen Maschine (VMware)
hallo Forum,
ich arbeite (bekanntlich?) ganz gerne mit virtuellen Maschinen, in aller Regel mit VMware. Im Moment benutze ich VMware Workstation 6.0.0.
Jetzt gibt es ein "Serverproblem" beim Einsatz auf einer WindowsXP-Maschine. Das heißt, WindowsXP ist das Trägersystem, in VMware können mehrere unterschiedliche Linux laufen, oder auch Win2003Server usw. Jetzt habe ich in einer dieser virtuellen Maschinen (Debian) einen Apache 2.2.4 laufen. Der liefert auch brav Webinhalte an localhost (also an sich selbst) aus, ebenfalls an eine andere virtuelle Maschine. Nicht aber an das Trägersystem. Dieser virtuelle Apache hat die IP 172.24.20.1.
Mit vorangegangenen VMware-Installationen (5.x) hatte ich ein solches Problem nicht. Die gesamte virtuelle Maschine bekommt zwei ebenfalls virtuelle NICs: eine mit NAT und die andere mit DHCP konfiguriert. Die NAT-Schnittstelle ist in der virtuellen Maschine eth0, die andere eth1. Über eth0 stellt die virtuelle Maschine den Internetzugang her, was auch gut funktioniert, aber über eth1 soll dann eigentlich der virtuelle Apache "funken" - tut er auch, aber nur in eine zweite virtuelle Maschine hinein, und nicht auf den "Host".
Selbstverständlich sind die hosts-Dateien sowohl auf der Trägermaschine (WindowsXP) wie auch auf allen virtuellen Maschinen korrekt eingerichtet.
Ich wollte diesen virtuellen Apache dazu nutzen, ein kleines selbst entwickeltes CMS zu testen und auch ein paar Dateien aus der virtuellen Maschine als "download" für die Trägermaschine anzubieten. Die logs der virtuellen Maschine weisen leider keinerlei Zugriffsversuch der Trägermaschine (IP ist 192.168.0.1) aus, also auch keinen Fehler.
Hat jemand eventuell einen Hinweis, wie ich meinen virtuellen Apache bzw. mein virtuelles Debian so konfigurieren muß, daß das Trägersystem den virtuellen Server abfragen kann?
Übrigens: ein IIS, den ich in einem virtuellen Win2003Server eingerichtet habe, läßt sich problemlos erreichen, obwohl (von Trägersystem-Seite aus) die virtuellen NICs exakt dieselben sind.
Grüße aus Berlin
Christoph S.
-
Hallo Christoph S.!
Nur mal als Frage:
Wenn Du dich mit Windows und Linux auskennst, warum verwendest du denn dann eine Linux Emulation unter Windows und nicht umgekehrt?Ich mein, ich bin "relativ" neu in Linux mit nur 2 Jahren Erfahrung (gegenüber 15 bei DOS/WIN), aber meine Erfahrung ist:
-Linux ist stabiler (ist echt in 2 Jahren trotz gröbster Bedienfehler nie gecrasht)
-Linux ist handlicher/besser organisiert (VNC Multidektop - nicht wie bei Windows alle User auf einem Screen), Rechteverwaltung etc.
-Linux ist klarer (konfigurier mal WIN so, dass es nicht irgendwohin telefoniert, wo es nicht soll...)
-...
Für Windows spricht im Wesentlichen:
-Die Gewohnheit
-Die bessere Hardwareunterstützung (leider nicht wegzudiskutieren)
-Software, die nur unter Win läuftAber ich würde trotzdem eher den umgekehrten Ansatz wählen:
Windows als Sandkasten unter Linux erscheint doch irgendwie praktikabler, oder?Nu noch 'tschuldigung dass ich dich zulaber statt dir weiterzuhelfen, aber das würd mich echt interessieren.
Grüsse,
Richard-
hallo,
Wenn Du dich mit Windows und Linux auskennst, warum verwendest du denn dann eine Linux Emulation unter Windows und nicht umgekehrt?
Ich verwende keine "Linux-Emulation", sondern ich setze gelegentlich virtuelle Maschinen ein. Was da "emuliert" wird, betrifft ausschließlich die (virtuelle) Hardware, auf der ich Betriebssysteme nahezu nach Belieben installieren kann - bis auf Macintosh (siehe http://community.de.selfhtml.org/my/zitatesammlung/zitat12. Und im übrigen kann ich das mit einer Linux-Maschine als Trägersystem auch machen, allerdings habe ich da die genannten Probleme nicht.
-Linux ist stabiler
-Linux ist handlicher/besser organisiertDarum geht es nicht. Im übrigen gibt es im Forumsarchiv eine Reihe Threads (auch mit meiner Beteiligung) zu dieser Thematik.
Windows als Sandkasten unter Linux erscheint doch irgendwie praktikabler, oder?
Es gibt Gründe, weshalb ich es eben _auch_ mit einer Windows-Kiste als Host haben möchte.
Grüße aus Berlin
Christoph S.
-
-
Hallo Christoph,
Dieser virtuelle Apache hat die IP 172.24.20.1.
Mit vorangegangenen VMware-Installationen (5.x) hatte ich ein solches Problem nicht. Die gesamte virtuelle Maschine bekommt zwei ebenfalls virtuelle NICs: eine mit NAT und die andere mit DHCP konfiguriert.
Wie wäre es, wenn Du die Konfiguration Deines virtuellen Netzwerkes hier detailliert darstellst. Mit diesen mangelhaften Informationen kann man Dir beim besten Willen nicht helfen.
Die logs der virtuellen Maschine weisen leider keinerlei Zugriffsversuch der Trägermaschine (IP ist 192.168.0.1) aus, also auch keinen Fehler.
Wenn Deine Trägermaschine keine IP-Adresse gleichen Netzwerk wie der Rechner mit Deinem Apache hat, dann benötigst Du entsprechendes Routing dazwischen. Wie sind die virtuellen Netzwerkkarten, die VMware einrichtet konfiguriert? Gibt es eine, über die die Kommunikation läuft. Ist etwa Routing innerhalb Deiner Debian-Maschine erforderlich.
Nutze die bekannten TCP/IP-Systemwerkzeuge zur Netzwerkdiagnose (z.B. ping), um herauszufinden, ob Du über TCP/IP zwischen "Trägermaschine" und der virtuellen Maschine, auf der Dein apache läuft - und zwar über die IP-Adresse, die Dein apache nutzt - kommunizieren kannst.
Ohne exaktere Angaben läuft Deine Problembeschreibung auf Rätselraten hinaus.
Freundliche Grüße
Vinzenz
-
hallo Vinzenz,
Wie wäre es, wenn Du die Konfiguration Deines virtuellen Netzwerkes hier detailliert darstellst. Mit diesen mangelhaften Informationen kann man Dir beim besten Willen nicht helfen.
Es gibt bei VMware (in diesem Fall auf einem Windows-Host) noch einen grafisch basierten "Netzwerkmanager". Auf einer Linux-Trägermaschine werden die nötigen Einstellungen über Scripts vorgenommen.
Wenn Deine Trägermaschine keine IP-Adresse gleichen Netzwerk wie der Rechner mit Deinem Apache hat, dann benötigst Du entsprechendes Routing dazwischen.
Richtig, aber genau deswegen ist eine der beiden virtuellen NICs auf eine IP gestellt, mit der sie im selben Subnetz angesiedelt ist wie eine der beiden Netzwerkkarten im Hostrechner. Auch die zweite befindet sich in einem Subnetz, das es als IP-Alias auf dem Hostrechner gibt.
Wie sind die virtuellen Netzwerkkarten, die VMware einrichtet konfiguriert?
Es gibt immer zwei Konfigurationen: eine auf dem Hostrechner und eine auf dem Gastsystem. Auf dem Hostrechner können bis zu zehn virtuelle NICs konfiguriert werden (bis VMware 5.5.4 waren es acht). Standardmäßig wird durchgezählt von "VMNet0" bis "VMNet9". Drei davon sind vorkonfiguriert: VMNet0, VMNet1 und VMNet8. VMNet0 als "bridged" - das heißt, wenn man die bei der Konfiguration der virtuellen Hardware auswählt, wird sie demselben Subnetz zugeordnet, das für die erste NIC des Hostrechners gilt und mit der gebridget. Damit kann dann beispielsweise die Internetverbindung des Hostrechners genutzt werden, und bei Windowsmaschinen funktioniert dann die Anzeige von "Netzwerkverbindungen". VMNet1 wird standardmäßig auf "host only" gestellt. Das bedeutet: ein anderes Subnet (irgendwas aus 192.168.xxx.xxx), keine Internetverbindung, aber eine "Netzwerkverbindung", so daß Dateiaustausch zwischen Host und Gast möglich ist. Ein auf dem Host laufender lokaler Apache ist zum Beispiel im Gastsystem erreichbar. VMNet8 wird auf NAT gestellt, damit wäre Routing zwischen Host und Gast möglich.
Diese Voreinstellungen reichen nicht aus, um auch im Gastsystem einen Apache betreiben zu können - naja, "betreiben" kann man ihn schon, aber er ist dann auch nur innerhalb dieses Gastsystems als "localhost" verfügbar. Ich stelle also VMNet2 so ein, daß es auf Hostseite als NAT behandelt wird - also gleiches Subnetz wie die erste im Host vorhandene NIC (192.168.0.0), Zuweisung einer IP über den VMware-internen DHCP-Server aus dem Bereich 192.168.0.128...192.168.0.255 und als Gateway 192.168.0.1. Über diese Schnittstelle kann die Internetverbindung laufen, und der auf dem Host vorhandene Apache ist im Gastsystem erreichbar (allerdings nicht alle virtuellen Hosts des Apache, sondern nur der erste). VMNet3 wird auf Hostseite auf das Subnetz 172.24.20.xxx gestellt und bekommt ebenfalls über DHCP eine Adresse 172.24.20.128...172.24.20.255.
Auf dem Gastsystem (beispielsweise Gentoo) wird VMNet2 zu eth0 mit unveränderter DHCP-IP-Adressse. VMNet3 wird zu eth1 mit festgelegter IP 172.24.20.1. Über eth0 läuft die Internetanbindung (und übrigens sind auch die anderen eventuell grade aktiven Rechner mit den IPs 192.168.0.x wechselseitig erreichbar), über eth1 soll eigentlich der im Gastsystem vorhandene Apache erreichbar sein - tat er jedenfalls bis VMware 5.5.4, deshalb diese Netzwerkeinstellungen.Nutze die bekannten TCP/IP-Systemwerkzeuge zur Netzwerkdiagnose (z.B. ping), um herauszufinden, ob Du über TCP/IP zwischen "Trägermaschine" und der virtuellen Maschine, auf der Dein apache läuft - und zwar über die IP-Adresse, die Dein apache nutzt - kommunizieren kannst.
"Kommunizieren" kann ich über beide virtuelle NICs, das heißt, ping funktioniert anstandslos in beide Richtungen (vom Host zum Gast, vom Gast zum Host, vom Gast zu anderem Netzwerkrechner, von anderem Netzwerkrechner zum Gast sowie zwischen Host und anderen Netzwerkrechnern). Auch andere Diagnosemöglichkeiten (netstat, traceroute ...) liefern keine irgendwie problematichen Aussagen.
Es wäre noch möglich, daß die Windows-eigene Firewall etwas blockiert. Die ist ja auf dem Host aktiv. Tut sie aber nicht, bzw. ich hab sie so eingestellt, daß das Gastsystem nicht geblockt wird.
Ich habe bereits angegeben, daß ein ebenfalls als virtuelle Maschine laufendes Windows2003Server-Gastsystem, das exakt über dieselbe Netzwerkkonfiguration läuft und auf dem IIS installiert ist, keinerlei Probleme macht.
Da ich über ausreichend RAM im Hostrechner verfüge, können auch mehrere virtuelle Maschinen gleichzeitig nebeneinander laufen. Wenn ich also beispielsweise ein virtuelles Gentoo und ein virtuelles Debian laufen habe, erreiche ich von Debian aus sowohl den Apache des Hostrechners wie auch den Apache in Gentoo. Aber der Hostrechner bekommt eben den Apache aus Gentoo nicht - dafür aber kann ein anderer Netzwerkrechner (192.168.0.2) auf ihn zugreifen.
Ohne exaktere Angaben läuft Deine Problembeschreibung auf Rätselraten hinaus.
Wars jetzt exakt genug?
;-)Grüße aus Berlin
Christoph S.
-