WS9 auf Windows 7 Client: kein Netzwerkzugriff der VM

[Peter1973]

Hallo,

folgendes Problem:

SYSTEMBESCHREIBUNG
Betrieben wird unser Host-Rechner mit einem Windows 7 Pro SP1 Client Betriebssystem (auf Host und VMs) sowie zur Virtualisierung VMware Workstation v9 auf dem Host und Antivirus OfficeScan v10.5 (auf Host und VMs).

KONFIGURATIONSHISTORIE
Die Konfigurierung der einzelnen VMs verlief im Grunde reibungslos. Auf Basis eines erzeugten VM-Templates mit neutralen Netzwerkeinstellungen bzgl. Knotenname und MAC-Adresse wurden nach einander mehrere VMs erzeugt. In diesen VMs wurden anschließend die Netzwerkeinstellungen aktualisiert und die jeweiligen Windows-Lizenzschlüssel eingetragen.
Vier der auf diese Weise erzeugten VMs funktionieren problemlos hinsichtlich Zugriff nach außen (anpingen externer Rechner, Domänenzugriff) und von außen (per ping und RDP).

PROBLEMBESCHREIBUNG
Die beiden verbleibenden VMs lassen weder einen Zugriff auf Host-externe Rechner zu (obwohl der eigene Host sicht- und ansprechbar ist), noch kann von außerhalb des eigenen Host auf diese VMs zugegriffen werden. Es scheint also so, als bestünde ein Problem in der Konfiguration der Netzwerkeinstellungen dieser VMs, obwohl die einstellbaren Parameter denjenigen der funktionierenden VMs entsprechen.

Ist solch ein Problem bekannt? Kennt sich jemand soweit aus, dass die Ursache weiter eingegrenzt werden kann? Gibt es bereits eine Lösung?

Vielen Dank und Gruß
Peter

[Dayworker]

Verlinke mal bitte die ungekürzten "vmware.log" von einer funktionierenden und beider fehlerhaften VMs. Damit
können wir schon mal grundlegende Probleme hinsichtlich VMware-IDs ausschliessen.
Poste mal dazu auch noch eine Übersicht, worin man Netzwerknamen, IPs, Gateways und Netmask sehen kann.

Das VMDKs in jedem Fall in der Ausschlußliste deines Virenscanners eingetragen sind, setz ich mal voraus. Falls dein Virenscanner sowas nicht bietet, schmeiß den einfach runter und nimm einen anderen. Falls du dafür Geld bezahlt hast, verbuch das als Lehrgeld.

[Peter1973]

Verlinke mal bitte die ungekürzten "vmware.log" von einer funktionierenden und beider fehlerhaften VMs

funktionierende VM SI-Z0FTP (entspricht der Konfiguration von SI-Z0FTL)
http://filecloud.io/op306kdn

defekte VM SI-Z0FTL
http://filecloud.io/h7cgwp89

defekte VM SI-Z0FTQ
http://filecloud.io/0j9b4eix

Poste mal dazu auch noch eine Übersicht, worin man Netzwerknamen, IPs, Gateways und Netmask sehen kann

Hier der geplante Zustand der Netzwerkkonfiguration der WMs (so wurde es mal eingestellt):

Code: Alles auswählen

SI-Z0FTP  10.2.160.217  10.2.160.1  255.255.248.0
SI-Z0FTL  10.2.160.210  10.2.160.1  255.255.248.0
SI-Z0FTQ  10.2.160.221  10.2.160.1  255.255.248.0


Da die VMs aber DHCP nutzen (Server ist entsprechend eingerichtet), die IP-Adressen also automatisch anhand des Knotennamens zugeordnet werden, allerdings bei den "defekten" VMs kein Netzwerkzugang nach Außen möglich zu sein scheint, stimmen die IP-Adressen beim Aufruf von ipconfig aktuell nicht.

Das VMDKs in jedem Fall in der Ausschlußliste deines Virenscanners eingetragen sind, setz ich mal voraus

Auf dem Host liegen alle Shared VMs im Verzeichnis ...\VirtualMachines . Dieses wurde im Virenscanner in der "scan exclusion list" aufgeführt.

[Dayworker]

Mal davon abgesehen, daß mir deine CPU/VMware-Kombi (Desktop-Produkt VMware-Workstation auf Sandy Bridge EP bzw Intel(R) Xeon(R) CPU E5-2640 0 @ 2.50GHz) nicht einleuchtet, sehe ich keine ID-Doppelungen.
Problematisch bei Workstation und Win7-SP1 war jedoch in der Vergangenheit, daß die Netzwerkverbindung im Gast bzw Gäste instabil wurden, sobald eine bestimmte, prozentuale Menge an Host-RAM für VMs verwendet und somit dem Host-OS entzogen war.
Ungeschickt für die allgemeine Geschwindigkeit bzw Schwuppdizität in einer VM sind natürlich die 8GB vRAM und 4 vCPUs in den VMs. Das würde ich testweise mal korrigieren, mit 2 vCPUs und 2 GB vRAM dürfte sich die Lage schon wesentlich entspannter geben. Funktionieren die problematische VMs eigentlich, wenn nur diese gestartet werden?

[mommi]

Ich leide seit geraumer Zeit auch unter diesen Problem.
Siehe auch http://vmware-forum.de/viewtopic.php?p=143538
Eine Lösung dazu habe ich nicht gefunden. An der VM liegt es definitiv nicht. Wenn ich diese auf eien ESX übertrage und dort starte habe ich auch Netz.
Es scheint also im Zusammenspiel zwischen dem HOST und der WS zu liegen.
Auch ein Rückbau auf WS8 hat bei mir nichts gebracht.

[Dayworker]

Ich leide seit geraumer Zeit auch unter diesen Problem.
Siehe auch http://vmware-forum.de/viewtopic.php?p=143538
Eine Lösung dazu habe ich nicht gefunden. An der VM liegt es definitiv nicht. Wenn ich diese auf eien ESX übertrage und dort starte habe ich auch Netz.
Es scheint also im Zusammenspiel zwischen dem HOST und der WS zu liegen.
Auch ein Rückbau auf WS8 hat bei mir nichts gebracht.

Danke für die Erinnerung an den Thread. Mir ist bei der erneuten Durchsicht deiner NAT.conf klar geworden, daß ich blind war. Da dein Problem nichts mit dem hiesigen zu tun hat, geht deine Problemlösung im verlinkten Thread weiter.

[Peter1973]

Mal davon abgesehen, daß mir deine CPU/VMware-Kombi (Desktop-Produkt VMware-Workstation auf Sandy Bridge EP bzw Intel(R) Xeon(R) CPU E5-2640 0 @ 2.50GHz) nicht einleuchtet, sehe ich keine ID-Doppelungen.

Was ist mit dieser Kombi nicht in Ordnung? Es der Rechner ist mit einem DUAL Xeon E5 (jeweils 6 physikalische Cores, jeder pCore dann noch geteilt in 2 vCores) und 64 GB RAM ausgestattet. Jede VM verwendet 8 GB RAM und i.d.R. 1 und einmal auch 4 Cores.

Problematisch bei Workstation und Win7-SP1 war jedoch in der Vergangenheit, daß die Netzwerkverbindung im Gast bzw Gäste instabil wurden, sobald eine bestimmte, prozentuale Menge an Host-RAM für VMs verwendet und somit dem Host-OS entzogen war.

Der Host sollte eigentlich bei maximal genutzten 6 x 8 GB noch 16 GB RAM für seine eigenen Belange haben. Interessant ist, dass die (nun plötzlich OHNE Konfigurationsänderung defekte) SI-Z0FTL ehemals mit korrekt arbeitendem externen Netzwerk funktioniert hat. Erst nach Installation einiger weiterer VMs trat das Netzwerkproblem bei der SI-Z0FTL auf. Und blieb seither.

Ungeschickt für die allgemeine Geschwindigkeit bzw Schwuppdizität in einer VM sind natürlich die 8GB vRAM und 4 vCPUs in den VMs. Das würde ich testweise mal korrigieren, mit 2 vCPUs und 2 GB vRAM dürfte sich die Lage schon wesentlich entspannter geben. Funktionieren die problematische VMs eigentlich, wenn nur diese gestartet werden?

Die externe Netzwerkfunktion der problematischen VMs funktioniert tatsächlich, wenn die VMs separat laufen (alle weiteren VMs sind heruntergefahren). Habe dies für die "defekte" SI-Z0FTL (4 Cores) ausprobiert. Wenn ich die anderen VMs dazuschalte, steigt die 5. VM netzwerkmäßig aus. Also scheint es doch eine Anzahl-Limitierung für Netzwerk-Zugriffe der VMs zu geben?

Gruß
Peter

[Dayworker]

Was ist mit dieser Kombi nicht in Ordnung? Es der Rechner ist mit einem DUAL Xeon E5 (jeweils 6 physikalische Cores, jeder pCore dann noch geteilt in 2 vCores) und 64 GB RAM ausgestattet. Jede VM verwendet 8 GB RAM und i.d.R. 1 und einmal auch 4 Cores.

Bei der HW würde ich eher an den kostenlosen, aber dennoch lizenzpflichtigen VMware Hypervisor denken. Allerdings mag dieser nur mit 32GB RAM zusammenspielen. Wer aber das Geld für eine Dual-Xeon Maschine ausgeben kann, dürfte auch noch das restliche Kleingeld von 504 Euronen haben und dieses in die kleinste Essentialsversion mit einjährigem S'n'S investieren können.

Problematisch bei Workstation und Win7-SP1 war jedoch in der Vergangenheit, daß die Netzwerkverbindung im Gast bzw Gäste instabil wurden, sobald eine bestimmte, prozentuale Menge an Host-RAM für VMs verwendet und somit dem Host-OS entzogen war.

Der Host sollte eigentlich bei maximal genutzten 6 x 8 GB noch 16 GB RAM für seine eigenen Belange haben. Interessant ist, dass die (nun plötzlich OHNE Konfigurationsänderung defekte) SI-Z0FTL ehemals mit korrekt arbeitendem externen Netzwerk funktioniert hat. Erst nach Installation einiger weiterer VMs trat das Netzwerkproblem bei der SI-Z0FTL auf. Und blieb seither.

Mit 16GB freien RAM hättest du 75% des zur Verfügung stehenden pRAMs an laufende VMs vergeben und bist somit weit über die als problematisch geltende Grenze von 30% hinausgeschossen. Ab dieser bekannten Grenze werden Gäste instabil und die Netzwerkverbindung bricht aus unerklärlichen Gründen weg. Ich hatte jedoch gehofft, daß VMware diesen Bug inzwischen beseitigt hätte. Das M$' Hyper-V damit anscheinend keine bekannten Probleme hat, liegt wohl nur daran, daß zum einen VMware ein Konkurrenzprodukt und jedes Produkt abseits des M$-Horizonts einen Fremdkörper darstellt.

Ungeschickt für die allgemeine Geschwindigkeit bzw Schwuppdizität in einer VM sind natürlich die 8GB vRAM und 4 vCPUs in den VMs. Das würde ich testweise mal korrigieren, mit 2 vCPUs und 2 GB vRAM dürfte sich die Lage schon wesentlich entspannter geben. Funktionieren die problematische VMs eigentlich, wenn nur diese gestartet werden?

Die externe Netzwerkfunktion der problematischen VMs funktioniert tatsächlich, wenn die VMs separat laufen (alle weiteren VMs sind heruntergefahren). Habe dies für die "defekte" SI-Z0FTL (4 Cores) ausprobiert. Wenn ich die anderen VMs dazuschalte, steigt die 5. VM netzwerkmäßig aus. Also scheint es doch eine Anzahl-Limitierung für Netzwerk-Zugriffe der VMs zu geben?

Es gibt keine mir bekannte Grenze für Netzwerkzugriffe. Das Problem liegt meines Wissens nach nur am verwendeten Host-OS und tritt mit älteren M$-OS anscheinend nicht auf oder ältere M$-OS wurden mit neueren WS-Versionen nicht traktiert. Allerdings hat vermutlich nur selten jemand reine Server-HW mit entsprechender HW-Ausstattung mit dem Desktop-Produkt VMware-Workstation/Player im Dauereinsatz gehabt.
Unser Moderator Ulli aka continuum beispielsweise empfiehlt ja nicht ohne Grund sogar die noch ältere WS-Version 6.5.4 unter Server2k3, denn diese Version wurde noch von den ursprünglichen EW-Gruppe herausgegeben. Selbst die 6.5.5 als Bugfix-Version für W7 mit SP1 als Host-OS und die komplette WS7 wurden bereits von neuen Programmierern herausgegeben. Wenn man sich die Buglisten mal duchsieht, scheinen sowohl die Programmierern als auch die Test-Abteilung zum einen ausser Haus und mit jeder neuen Version ersetzt worden zu sein. Das ist extrem unglücklich, denn Virtualisierung muß notgedrungen tief ansetzen. Mit jedem Update, von Servicepacks oder Upgrades ganz zu schweigen, können sich daher Einschnitte ergeben. Sicherheitstechnisch hat M$ extrem viel getan, was inzwischen häufiger mal zu Lasten der Benutzbarkeit geht. Im Prinzip agiert M$ jetzt immer mehr wie der Linux-Kernel: "Ich herrsche und ansonsten teile ich nur, wenn es mir gerade danach beliebt." Davon, daß M$ in seinen eigenen Produkten gern auch mal undokumentiertes verwendet, will ich garnicht erst anfangen...

[Peter1973]

Mit 16GB freien RAM hättest du 75% des zur Verfügung stehenden pRAMs an laufende VMs vergeben und bist somit weit über die als problematisch geltende Grenze von 30% hinausgeschossen. Ab dieser bekannten Grenze werden Gäste instabil und die Netzwerkverbindung bricht aus unerklärlichen Gründen weg. Ich hatte jedoch gehofft, daß VMware diesen Bug inzwischen beseitigt hätte...

Habe nun mal den verwendeten RAM-Speicher aller VMs auf 2 GB herabgesetzt. Damit sollten bei 5 aktiven VMs nur 10 von 64 GB verwendet werden (nicht mal 16% des verfügbaren pRAM). Es bleibt der gleiche Effekt: die fünfte gestartete VM erlaubt keinen externen Netzwerkzugriff mehr, obwohl alle vorhergehenden dies problemlos tun. Auch wenn ich die Start-Reihenfolge beliebig ändere. Es ist immer die 5. VM und alle Nachfolgenden.

Ideen?

[Dayworker]

Ja.
Nach einer erneuten Durchsicht fiel auf, daß keine deiner verlinkten VMs laut den "vmware.log" über ein konfiguriertes Netzwerkinterface verfügt. Deine Netzwerk-Config für die verlinkten VMs sieht wie folgt aus:

Code: Alles auswählen

ethernet0.address = 00:0C:29:BD:37:A0
ethernet0.addressType = static
ethernet0.allowGuestConnectionControl = FALSE
ethernet0.features = 1
ethernet0.generatedAddressOffset = 0
ethernet0.networkName =
ethernet0.pciSlotNumber = 32
ethernet0.present = TRUE
ethernet0.virtualDev = e1000
ethernet0.wakeOnPcktRcv = FALSE

Auffällig ist dabei der Eintrag "ethernet0.networkName = ". Diese Einstellung macht nur auf dem ESX(i) einen Sinn, da dort die VMware-Netzwerkinterfaces anders bezeichnet werden.
Mir fehlt für die VMware-Desktopprodukte jedoch ein Eintrag wie ethernet0.vnet = "VMnet0" oder auch ethernet0.connectionType = "bridged", ethernet0.connectionType = "hostonly" und ethernet0.connectionType = "nat". Alle deine VMs laufen somit erstmal ohne eingestelltes VMware-Netzwerkinterface und das ist von VMware anscheinend mit Bridge belegt, wenn die Einstellung ethernet0.present = "TRUE" gesetzt wurde. Möglicherweise geht das bis 4 VMs gut und danach hagelt es die Verbindungsabbrüche. Poste mal bitte noch ein Bild deiner VMware-Netzwerkeinstellungen aus dem "VMware Netzwerk Editor" (vmware-netcfg). Du solltest dort zumindest sowas sehen:



Wie in dem Bild ersichtlich, verfügt dieser Host über zwei pNICs (Marvell Gig-E und Netgear W-Lan). In diesem Fall darf auf keinen Fall die Einstellung auf "Automatic" oder "Auto-Detect" gesetzt werden, da es keine festgelegte Reihenfolge gibt und dann die falsche pNIC einem unerwünschten VMware-Interface zugewiesen würde. Das ist auch deshalb wichtig, da ohne weitere Eingriffe die VMware-Interfaces "NAT" und "Host-only" immer an der dem Interface "Bridge" zugeteilten pNIC festgemacht werden.

[Peter1973]

Poste mal bitte noch ein Bild deiner VMware-Netzwerkeinstellungen aus dem "VMware Netzwerk Editor"...

http://www10.pic-upload.de/30.01.13/s8c74fqp12es.gif
(ich kann leider keine Attachments direkt einfügen, da mein Zähler für MAX_ATTACHMENTS in diesem Forum scheinbar auf NULL steht und ich auch nach Studium der FAQ keine Möglichkeit sehe, dies zu ändern. Aber so geht es ja auch.)

Es gibt bei mir scheinbar ebenfalls zwei Adapter zur Auswahl. Aber die Anzahl der Konfigurationen im oberen Frame ist bei mir wesentlich geringer.

[Dayworker]

Zeimal JA. Erstens gehen Dateianhänge hier schon länger nicht mehr, daher der Wink mit dem Freehoster und zweitens ist bei dir das bereits als nutzlos bekannte "Auto-Bridging" aktiv. Weise das Vmnet0 einfach eine deiner beiden pNICs zu und nimm für die zweite dann das nächste freie VMnet also VMnet2. Danach kannst du deinen VMs dann ein bestimmte VMnetX als Bridge zuweisen und das Routing klappt dann auch wieder.

[Peter1973]

...und zweitens ist bei dir das bereits als nutzlos bekannte "Auto-Bridging" aktiv. Weise das Vmnet0 einfach eine deiner beiden pNICs zu und nimm für die zweite dann das nächste freie VMnet also VMnet2. Danach kannst du deinen VMs dann ein bestimmte VMnetX als Bridge zuweisen und das Routing klappt dann auch wieder.

habe nun das Auto-Bridging in der von Dir beschriebenen Weise im VirtualNetworkEditor für VMnet0 durch eine pNIC ersetzt, VMnet2 auf die andere pNIC gesetzt und die anderen VMnet-Anschlüsse über "Host-Only" auf "Custom" gesetzt (der Sinn von letzterem ist mir nicht klar):



Allerdings erscheint bis auf VMnet2 (welches mit einer nicht funktionierenden pNIC verbunden ist) KEINE der neu erzeugten Netzwerke als wählbare Konfiguration für die VMs im Workstation-Konfigurator. Ich kann sie also nicht für die VMs auswählen. Wenn ich also wieder "bridged" als Netzwerk-Verbindung für jede VM auswähle, sehe ich erneut den gleichen Effekt wie vorher: Nachdem 4 VMs problemlos mit Netzwerkkonfigurationen starten, klappt es ab der 5. VM nicht mehr. Oder habe ich etwas falsch gemacht?

[Dayworker]

Falsch hast du erstmal nichts gemacht, die Auswahl des VMnetX ist bei mehr als pNICs im Host nur etwas tricky. Wenn du es aber einmal gemacht hast, hat man keine Fragen mehr...
Ich hab jetzt leider kein Bild von den Netzwerkeinstellungen der VM parat, aber wenn du der VM ein Netzwerk-Interface gibst und dieses im Pulldown-Menu auf "Custom" setzt, kannst du direkt darunter erneut das VMnetX bestimmen und hast dann die freie Auswahl zwischen allen vorhandenen VMnet-Interfaces.
Alternativ öffnest du deine VMX-Datei und fügst hinzu:

ethernet0.connectionType = "custom"
ethernet0.vnet = "VMnet0"

Danach wirfst du die VM aus der Übersicht/Inventory und nimmst aber vorher den Haken raus, der die VM unwiederbringlich von der Platte löscht. Wenn du die VM dann erneut ins Inventory aufnimmst, werden alle geänderten Einstellungen übernommen. Alternativ reicht es aber auch, die VM einfach zu starten. Dann sollte auch die WS die geänderte Config direkt starten und die VM-Einstellungen in der WS-Anwendung sichtbar werden.

[Peter1973]

...wenn du der VM ein Netzwerk-Interface gibst und dieses im Pulldown-Menu auf "Custom" setzt, kannst du direkt darunter erneut das VMnetX bestimmen und hast dann die freie Auswahl zwischen allen vorhandenen VMnet-Interfaces.

Nach (gefühlt jahrelangem) Probieren habe ich herausgefunden, dass sich die Einstellmöglichkeiten für die VM-Netzwerke signifikant erweitern, wenn man die VM nicht mehr shared betreibt. Nun sehe ich auch unter SETTINGS / Hardware / NetworkAdapter die von Dir beschriebenen Einstellmöglichkeiten.

Folgende Einstellungen habe ich nun auf dem HOST über VirtualNetworkEditor (VNE) vorgenommen:

VMnet0, BRIDGED, mit pNIC (1) diese Verbindung funktioniert
VMnet1, Host-Only
VMnet2, BRIDGED, mit pNIC (2) diese Verbindung funktioniert nicht
VMnet3, CUSTOM
...

Es tritt folgender Effekt auf:

[1] Wenn ich den jeweiligen VMs die Netzwerke "VMnet3..." zuordne, funktionieren deren externe Netzwerke NICHT (wahrscheinlich, weil diese Einstellung im VNE auch "Host-Only" heißt).
[2] Wenn ich in allen VMs die "VMnet0 (Auto-bridging)" eintrage und sie dann nach einander starte, funktionieren grob die externen Netzwerke der ersten 4 VMs mit dieser Einstellung. Die nachfolgenden wieder nicht mehr (alter Effekt).
[3] Wenn ich in allen VMs nicht "custom" sondern "bridged" auswähle, ist der Effekt entsprechend [2].

Irgendwie ist noch der Wurm drin. Vor allem verstehe ich die Verbindung der einzelnen VMnetX mit dem pNIC nicht. Wo kann ich denn dem VNE sagen, dass hier eine Verbindung bestehen soll? Wir wollen ja eigentlich eine "bridged"-Funktion darstellen.

[~thc]

Unabhängig vom "Automatic Bridging" (das ich wie Dayworker auch immer manuell "fixiere") , dass laut deiner ursprünglichen Fragestellung ja irgendwie funktioniert haben muss, interessiert mich folgendes:

- Warum betreibst du einen "Profi"-Host (Xeon E5-2640, I350 Dual-GBE-Adapter) mit einem Desktop-OS wie Windows 7 und verschwendest auch noch Ressourcen an den Snake-Oil-Virenschutz auf dem Host? Eine reine Windows-Virtualisierung, so wie du sie anstrebst, würde ich auf einem Hyper-V (Windows Server 2008 R2) oder ESX aufsetzen.

- Sind die Gast-Maschinen sauber geklont worden (über SysPrep)?

[Dayworker]

Nach (gefühlt jahrelangem) Probieren habe ich herausgefunden, dass sich die Einstellmöglichkeiten für die VM-Netzwerke signifikant erweitern, wenn man die VM nicht mehr shared betreibt.

SharedVMs brauchst du nur, wenn du VMs wie früher beim VMserver1/2 automatisch mit dem Host starten und stoppen willst. Je nach WS-Version konnte man damit aufgrund eines Bugs aber auch seine VMs komplett zerschiessen.

Folgende Einstellungen habe ich nun auf dem HOST über VirtualNetworkEditor (VNE) vorgenommen:

VMnet0, BRIDGED, mit pNIC (1) diese Verbindung funktioniert
VMnet1, Host-Only
VMnet2, BRIDGED, mit pNIC (2) diese Verbindung funktioniert nicht
VMnet3, CUSTOM
...

Im Normalfall sind nur die VMnet0 (Bridge), VMnet1 (Host-only) und VMnet8 (NAT) konfiguriert. Der Rest wird ohne weitere Einstellungen immer als Host-only geführt, da dort keine pNIC zugeordnet wurde. Du kannst jedoch jedes VMnet auch als NAT oder für spezielle Dinge als "Custom" konfigurieren. Wenn du einer VM das per "Custom" aber ansonsten unkonfigurierte "VMnet3" gibst, resultiert das in einer Netzwerkverbindung mit "Host-only" und du hast darin logischerweise keine Inet-Verbindung.
Wenn das VMnet2 nicht funktioniert, liegt entweder ein Netzwerkproblem (IP, Netmask, Gateway, Kabel defekt/fehlt) auf dem Host vor oder die Win-Firewall macht ihre Arbeit.

[1] Wenn ich den jeweiligen VMs die Netzwerke "VMnet3..." zuordne, funktionieren deren externe Netzwerke NICHT (wahrscheinlich, weil diese Einstellung im VNE auch "Host-Only" heißt).
[2] Wenn ich in allen VMs die "VMnet0 (Auto-bridging)" eintrage und sie dann nach einander starte, funktionieren grob die externen Netzwerke der ersten 4 VMs mit dieser Einstellung. Die nachfolgenden wieder nicht mehr (alter Effekt).
[3] Wenn ich in allen VMs nicht "custom" sondern "bridged" auswähle, ist der Effekt entsprechend [2].

Irgendwie ist noch der Wurm drin. Vor allem verstehe ich die Verbindung der einzelnen VMnetX mit dem pNIC nicht. Wo kann ich denn dem VNE sagen, dass hier eine Verbindung bestehen soll? Wir wollen ja eigentlich eine "bridged"-Funktion darstellen.

Dein Bild besagt doch eindeutig, daß du beide pNICs auf die "VMnet0" und "VMnet2" konfiguriert hast. Somit ist dieses bei mehreren pNICs völlig blödsinnige "Auto-Bridging" deaktiviert. Gerade dieses "Auto-Bridging" schafft mehr Probleme, als es löst. Lediglich die VMnet3-7 und die im Bild nicht sichtbaren VMnet9-10 würde ich sicherheitshalber doch wieder auf deren vorherigen Zustand (sicherlich Host-only) zurücksetzen.


Wenn du die Bridge bzw die damit bedachten VMnet's einer VM als Netzwerk-Interface zuweißt, mußt du natürlich auch den IP-Bereich und vor allem die Netzwerkmaske des Hosts im Auge haben. Ansonsten funktioniert das Routing nicht. Dazu kommt noch, daß sämtliche Win-Desktop-OS von Hause aus das IP-Forwarding abgeschaltet haben.

[Peter1973]

Warum betreibst du einen "Profi"-Host (Xeon E5-2640, I350 Dual-GBE-Adapter) mit einem Desktop-OS wie Windows 7 und verschwendest auch noch Ressourcen an den Snake-Oil-Virenschutz auf dem Host? Eine reine Windows-Virtualisierung, so wie du sie anstrebst, würde ich auf einem Hyper-V (Windows Server 2008 R2) oder ESX aufsetzen.

Prinzipiell könnte sicher auch ein anderes Host-Betriebssystem herhalten. Windows7 war halt erstmal auf dem Rechner drauf und sollte theoretisch auch funktionieren. Der Virenschutz OfficeScan ist von der Verwaltung vorgegeben worden. Zusätzlich war uns wichtig, dass man die VMs auch temporär lokal auf einem Client betreiben können muss. Hier schien VMware Server oder VMware Workstation passender als ESX.

Sind die Gast-Maschinen sauber geklont worden (über SysPrep)?

Davon gehe ich aus. Es gibt im Host-Programm "VMware Workstation" unter <RechtsKlick auf VM>, dann MANAGE und CLONE... die Möglichkeit für das Clonen, die ich für alle VMs in gleicher Weise verwendet habe.

Eine Kombination von Windows Server 2008 R2, VMware Workstation und OfficeScan könnte sicher mal ausprobiert werden, aber für den Augenblick wäre vorrangig interessant, warum sich das Netzwerk nicht in der erwarteten Weise mit mehreren VMs verwenden lässt.

[Peter1973]

SharedVMs brauchst du nur, wenn du VMs wie früher beim VMserver1/2 automatisch mit dem Host starten und stoppen willst. Je nach WS-Version konnte man damit aufgrund eines Bugs aber auch seine VMs komplett zerschiessen.

Das ist eines der Ziele gewesen. Und diese Funktionalität klappt eigentlich.

Wenn du einer VM das per "Custom" aber ansonsten unkonfigurierte "VMnet3" gibst, resultiert das in einer Netzwerkverbindung mit "Host-only" und du hast darin logischerweise keine Inet-Verbindung.

Genau das habe ich erfahren. Hatte Dich an diesem Punkt im vorherigen Posting so verstanden, als würde man eine VMnet nach der anderen den verfügbaren pNICs zuordnen können. Hatte dann bemerkt dass bei mir nach zweien bereits Schluss ist. Und bei uns ist pNIC #2 nicht einmal physikalisch verbunden.

Theoretisch könnte ich ja mal pNIC #2 mit einem Kabel versehen und ebenfalls über einen Hub/Switch mit dem Netzwerk verbinden, an dem pNIC #1 hängt. So könnte ich vielleicht trotz bleibender Problematik (nur 4 VMs mit funktionierendem NW) weitere 4 VMs über pNIC #2 laufen lassen, wenn man das irgendwie konfiguriert bekommt.

Dein Bild besagt doch eindeutig, daß du beide pNICs auf die "VMnet0" und "VMnet2" konfiguriert hast. Somit ist dieses bei mehreren pNICs völlig blödsinnige "Auto-Bridging" deaktiviert...

Ja, hier im Virtual Network Editor (VNE) schon, aber nicht in den Konfigurationen der VMs. Dort könnte man weiterhin "VMnet0 (Auto-bridging)" auswählen. Das hatte mich etwas verwirrt. Ich weiß auch immer noch nicht, woran ich dann sehen kann, dass die neuen VMnet3...VMnet9 tatsächlich physikalisch nach außen sichtbar werden. Oder ist es automatisch so, dass ALLES (virtuell und physikalisch) zusammengeschaltet wird und dann funktioniert, wenn IP-Bereich und Maske zwischen virtuell und physikalisch übereinstimmen?

Sorry, wenn ich so dämlich frage. Bin in beiden Themen (Netzwerk und Virtualsierung) absoluter Anfänger und versuche es mir irgendwie zusammenzureimen und zuzuhören.

[Dayworker]

Warum betreibst du einen "Profi"-Host (Xeon E5-2640, I350 Dual-GBE-Adapter) mit einem Desktop-OS wie Windows 7 und verschwendest auch noch Ressourcen an den Snake-Oil-Virenschutz auf dem Host? Eine reine Windows-Virtualisierung, so wie du sie anstrebst, würde ich auf einem Hyper-V (Windows Server 2008 R2) oder ESX aufsetzen.

Prinzipiell könnte sicher auch ein anderes Host-Betriebssystem herhalten. Windows7 war halt erstmal auf dem Rechner drauf und sollte theoretisch auch funktionieren. Der Virenschutz OfficeScan ist von der Verwaltung vorgegeben worden. Zusätzlich war uns wichtig, dass man die VMs auch temporär lokal auf einem Client betreiben können muss. Hier schien VMware Server oder VMware Workstation passender als ESX.

Wenn es dir um lokalen Betrieb geht, kannst du ESXi vergessen und die VMserver sind tot. Dazu kommt das beide VMserver noch vor Server2k8-R2 veröffentlicht wurden und von daher weitere nervige Probleme zu erwarten sind. Beim VMserver2 kommt noch die Problematik mit der als Browser-Plugin konzipierten VMware-Console hinzu, die meist nur sporadisch und mit älteren Browser-Versionen (IE6/7, FF2 und FF3 bis v3.5) funktioniert. Von der Warte bleibt nur die VMware Workstation übrig.

Sind die Gast-Maschinen sauber geklont worden (über SysPrep)?

Davon gehe ich aus. Es gibt im Host-Programm "VMware Workstation" unter <RechtsKlick auf VM>, dann MANAGE und CLONE... die Möglichkeit für das Clonen, die ich für alle VMs in gleicher Weise verwendet habe.

Eine Kombination von Windows Server 2008 R2, VMware Workstation und OfficeScan könnte sicher mal ausprobiert werden, aber für den Augenblick wäre vorrangig interessant, warum sich das Netzwerk nicht in der erwarteten Weise mit mehreren VMs verwenden lässt.

Bei deiner Art des Clonens werden nur die VMware-IDs geändert, für den Rest im OS bist immer noch du zuständig.

Wenn die WS9 bei dir schon nicht unter Win7 läuft, kannst du dir eigentlich auch den Versuch unter Server2k8-R2 ersparen, aber könnte ich auch daneben liegen... Was ich aber in jedem Fall mal anstrengen würde, wäre zum einen mal im offiziellen VMTN nach einer Lösung zu fragen und zum anderen deine Konstellation mal dem Support vor die Füss zu packen. Irgendwo muß da ja der Wurm drin sein und die Bugliste der WS-Version9 ist lang. Von der Warte betrachtet könntest du glatt mal die ältere WS7 ausprobieren.

Dein Bild besagt doch eindeutig, daß du beide pNICs auf die "VMnet0" und "VMnet2" konfiguriert hast. Somit ist dieses bei mehreren pNICs völlig blödsinnige "Auto-Bridging" deaktiviert...

Ja, hier im Virtual Network Editor (VNE) schon, aber nicht in den Konfigurationen der VMs. Dort könnte man weiterhin "VMnet0 (Auto-bridging)" auswählen. Das hatte mich etwas verwirrt. Ich weiß auch immer noch nicht, woran ich dann sehen kann, dass die neuen VMnet3...VMnet9 tatsächlich physikalisch nach außen sichtbar werden. Oder ist es automatisch so, dass ALLES (virtuell und physikalisch) zusammengeschaltet wird und dann funktioniert, wenn IP-Bereich und Maske zwischen virtuell und physikalisch übereinstimmen?

Ich hab nicht ausprobiert, was passiert, wenn du "Bridge" als Gast-Interface einstellst. Vermutlich nimmt dann VMware eine der beiden und probiert darüber den Netzwerkzugang, der aufgrund des fehlenden Kabels scheitert.

Verlinke mal bitte erneut ein "vmware.log" mit den vorgenommenen Änderungen im VMware-Netzwerkeditor. Wenn du immer noch "Bridge" drinsteht, sollten wir das Problem lösen können, indem wir die zugehörige VMX-Datei umschreiben. Diese Änderung mußt du dann halt auch in alle anderen VMs übernehmen.
Deine Fragen haben auch nichts mit dämlich oder so zu tun. Mich wurmt es inzwischen selber, daß wir es immer noch nicht geschafft haben.

[~thc]

Wenn die "CLONE"-Funktion, wie von Euch angedeutet, selbst kein Sysprep anwirft, dann hast du jetzt sechs Windows-Maschinen mit identischer System-ID (SID) - das solltest du dringend beheben.

Mit dem Server 2008 R2 meinte ich eine Virtualisierung über Hyper-V. Auf den Gedanken, darauf die Workstation zu installieren, wäre ich nicht gekommen.

[Dayworker]

Wenn die "CLONE"-Funktion, wie von Euch angedeutet, selbst kein Sysprep anwirft, dann hast du jetzt sechs Windows-Maschinen mit identischer System-ID (SID) - das solltest du dringend beheben.

Die SID spielt aber seit Vista meines Wissens keine entscheidende Rolle mehr. Dazu gabs/gibts wohl auch einen entsprechenden Artikel bei den Sysinternals oder verwechsle ich da wieder was...

Mit dem Server 2008 R2 meinte ich eine Virtualisierung über Hyper-V. Auf den Gedanken, darauf die Workstation zu installieren, wäre ich nicht gekommen.

Daran hätte man vorher denken sollen, bevor man die WS käuflich erwirbt. Da die WS aber auch ESX(i)-VMs verarbeiten kann, ist das die schnellste Möglichkeit einen ESX(i)-Komplettausfall zu kompensieren.

[~thc]

Die SID spielt aber seit Vista meines Wissens keine entscheidende Rolle mehr. Dazu gabs/gibts wohl auch einen entsprechenden Artikel bei den Sysinternals oder verwechsle ich da wieder was...

http://blogs.technet.com/b/markrussinov ... 91024.aspx

Wusste ich auch noch nicht. Es mag also keine Auswirkungen haben, aber Microsoft unterstützt es nicht.

[saxa]

Peter1973,

gibt es im Systemlog des Hosts Einträge, die auf die DOS-Angriffe hinweisen (EventID 2025)? Wenn ja: bitte "implementiere" die Methode 2 des nachfolgenden KB-Artikel auf dem Host:

http://support.microsoft.com/kb/898468

Berichte uns, ob das was gebracht hat.

[Peter1973]

Verlinke mal bitte erneut ein "vmware.log" mit den vorgenommenen Änderungen im VMware-Netzwerkeditor. Wenn du immer noch "Bridge" drinsteht, sollten wir das Problem lösen können...

Leider ist der Zugang zu "filecloud" von meiner Arbeit aus blockiert. Werde das LogFile heute abend nochmal senden. Sorry.

Jungs, vielen Dank für die Mühe soweit. Ich muss aber kurz zurückrudern, denn mittlerweile weiß ich bei den vielen guten Vorschlägen gar nicht, wo ich beginnen soll. Darum eine kurze Zusammenfassung, was ich gern realisieren möchte, und wie die aktuelle Konfiguration ist:

Ziel-Konfiguration


Die 5. und 6. VM erhält nach dem Hochfahren und Einloggen keinen externen (bridged) Netzwerkzugriff. Es erscheint lediglich ein Fenster am unteren Bildschirmrand mit dem Text "Es konnten nicht alle Netzlaufwerke wiederhergestellt werden". Jede der betroffenen VMs kann nur sich selbst anpingen und ist von außen nicht sichtbar.

Einstellungen
- an pNIC #1 ist das externe Netzwerk physikalisch angeschlossen
- im Virtual Network Editor (VNE) wurde VMnet0 auf pNIC #1 gesetzt (bridged)
- in jeder VM wurde der NetworkAdapter auf VMnet0 gesetzt (custom)

Wenn ich nachher zu Hause bin, werde ich die LogDatei einer funktionierenden und einer nicht funktionierenden VM hier im Forum verlinken. Die Variante mit der Verwendung von 6 unterschiedlichen VMnetX ist mir von Einstellungsseite her noch nicht klar, besonders bzgl. des Zusammenhangs mit IP-Bereich und Netzwerkmaske. Wenn ich das Vorgehen verstehe, könnte ich es gern nochmal ausprobieren.