[Win7] Virtuelle Maschine for Beginners

[Lokheizer]

Hallo!


Ich hätte ein paar Fragen bezüglich VMs, die ich durch googlen nur unzureichend beantworten konnte (eventuell auch falsch gesucht). Die ganze Nacht habe ich mich damit beschäftigt, bin aber nicht wirklich zu einem Ergebnis gekommen.
Der Hintergrund:
Ich würde gerne eine VM installieren, in der ich Software gefahrlos testen kann weil es einfach mühsam ist, eventuelle Reste dieser Software vom Produktivsystem zu entfernen. Auch würde ich gerne einmal Linux ansehen, der Neugier wegen. Dabei stellen sich mir folgende Fragen:

• Wenn ich Win7 in der VM installiere, müsste ich dieses ja irgendwann aktivieren lassen. Kann ich dann einfach Win7 neu installieren und ich hab wieder ein wenig Zeit?
• Belastet eine VM die SSD sehr (allgemein gefragt, damit sind keine aufwändigen Dateioperationen in der VM gemeint)?
• Ist es sinnvoll eine VM in eine RAMDisk zu installieren?
• Kann ein Programm aus einer VM ausbrechen (ich hab natürlich nicht vor absichtlich Viren zu installieren, aber die Frage stellt sich trotzdem)
• Gibt es sonst noch Dinge, die ich unbedingt beachten sollte?

Vielleicht sind die Fragen bescheuert, aber VMs sind Neuland für mich.

 

[think_pad]

Nein, das ist kein Router.

Ein DHCP-Server ist immer ein Router, da TCP/IP (Layer 3). Die Bridge wird quasi nur benutzt, um diese IP-Adressen auf die VM-Adapter zu verteilen.

Nein es gibt keine zwei DHCP-Server. Keine Ahnung woher du das hast, aber das ist einfach nicht der Fall.

Es gibt einen DHCP-Server im Access Point und einen DHCP-Dienst der VM auf dem Host-PC: Sind diese per Bridge verbunden, macht das zwei...

 

[schoerg]

Ein DHCP-Server ist immer ein Router, da TCP/IP (Layer 3). Die Bridge wird quasi nur benutzt, um diese IP-Adressen auf die VM-Adapter zu verteilen.

Ein DHCP-Server ist ein DHCP-Server. Kein Router und auch nicht sonstirgendwas. Ein DHCP-Server kann auf einem Router laufen, das ist aber schon alles. Du wirfst hier die Begriffe wild durcheinander.

Es gibt einen DHCP-Server im Access Point und einen DHCP-Dienst der VM auf dem Host-PC: Sind diese per Bridge verbunden, macht das zwei...

Den DHCP-Server von Virtualbox ist nicht aktiv wenn du Bridge auswählst.

 

[think_pad]

Ein DHCP-Server ist ein DHCP-Server. Kein Router und auch nicht sonstirgendwas. Ein DHCP-Server kann auf einem Router laufen, das ist aber schon alles. Du wirfst hier die Begriffe wild durcheinander.

Na gut, korrekt: Ein DHCP-Server verteilt auf Layer 3 innerhalb eines Subnetzes IP-Adressen an Netzwerkclients und kann nur auf einem physischen oder virtuellen Gerät reallsiert werden, dass ebenfalls Layer 3 verwendet. Geräte, die auf Layer 3 arbeiten, nennt man Router. Ihre Aufgabe ist es, Daten zwischen verschiedenen IP-Netzen zu transportieren.

Den DHCP-Server von Virtualbox ist nicht aktiv wenn du Bridge auswählst.

Der DHCP-Server (bei VMWare) wird als unabhängiger Dienst auf dem Host-PC gestartet und kann IP-Adressen innerhalb des vordefinierten Subnetzes verteilen. Aktiviert/Deaktiviert man DHCP auf einem virtuellen Bridge-Adapter, kann dieser Dienst theoretisch auch IP-Adressen außerhab des PC verteilen, insofern diese Adapter auf DHCP-Empfang gestellt sind.

 

[schoerg]

Geräte, die auf Layer 3 arbeiten, nennt man Router. Ihre Aufgabe ist es, Daten zwischen verschiedenen IP-Netzen zu transportieren.

Leider nicht ganz richtig. Mein PC ist auch ein Layer 3-Gerät. Ist aber kein Router.

Der DHCP-Server (bei VMWare) wird als unabhängiger Dienst auf dem Host-PC gestartet und kann IP-Adressen innerhalb des vordefinierten Subnetzes verteilen. Aktiviert/Deaktiviert man DHCP auf einem virtuellen Bridge-Adapter, kann dieser Dienst theoretisch auch IP-Adressen außerhab des PC verteilen, insofern diese Adapter auf DHCP-Empfang gestellt sind.

Es geht um Virtualbox. Da gibt es keinen Virtuellen Bridge-Adapter.

 

[think_pad]

- Leider nicht ganz richtig. Mein PC ist auch ein Layer 3-Gerät. Ist aber kein Router.
- Es geht um Virtualbox. Da gibt es keinen Virtuellen Bridge-Adapter.

Dein PC ist ein Layer 2-Gerät: Netzwerkkarte auf Ethernet-Basis. Erst wenn Du den zweiten Netzwerk-Adapter für andere Computer als Internetverbindung freigibst, wird er zum Router (Layer 3).

Der Themenersteller hat einen solchen Adapter per Bild gesendet:

​

 

[schoerg]

Dein PC ist ein Layer 2-Gerät: Netzwerkkarte auf Ethernet-Basis. Erst wenn Du den zweiten Netzwer-Adapter für andere Computer für die Internetverbindung freigibst, wird er zum Router (Layer 3).

Der Themenersteller hat aber in solchen Adapter per Bild gesendet:

Und die Layer 3-Adresse hat jeder PC nur so zum Spaß?

Ja der TE hat das Bild gepostet, aber was soll es bringen? Der Adapter der da eingestellt wird betrifft die VM, nicht den Host.

Übrigens gibt es auch bei VMware keinen Bridge-Adapter.

 

[plan_b]

think_pad du bist nicht zufällig Berufsschullehrer in BW? Selten so viel Bullshit gehört, könntest mein ehemaliger Telekommunikationssysteme Lehrer sein.... Unglaublich. DHCP sind Router und Computer mit einer Netzwerkkarte sind keine Layer 3 Geräte.... Bitte das Osi Modell nochmal genau anschauen und verstehen.

 

[think_pad]

think_pad du bist nicht zufällig Berufsschullehrer in BW?

Nein, bin ich nicht...

Geschichten wie diese:
Eigentlich machte Michi alles richtig. Als erfahrener Anwender war er ausgesucht worden, eine neue Software vor der Einführung zu testen. Um in der Produktionsumgebung kein Unheil anzurichten, installierte er eine virtuelle Maschine, darin Windows und darin die Software. Weil das Programm keine Internetverbindung herstellen konnte, vermutete Michi einen Fehler in den Einstellungen des Wirts-PC, den er allerdings nicht finden konnte. Um nichts Vernünftiges unversucht zu lassen, bevor er einen Admin mit seinem Problem belästigte, startete Michi den "Netzwerkassistenten" von Windows, der allerdings das Problem auch nicht löste.

Ratlos versuchte er nun, einen Admin zu Hilfe zu rufen, doch die waren alle im Panik-Modus, denn seit wenigen Minuten meldeten sich immer mehr Anwender, deren Rechner den Netzwerkkontakt verloren hatten. Michi fasste sich in Geduld, nur um nach einer halben Stunden von einer Horde schimpfender Admins überfallen zu werden.
Denn sein Rechner war schuld am Ausfall der anderen: Der Windows-Netzwerkassistent hatte nichts Besseres zu tun gehabt, als verschiedene Netzwerkschnittstellen zu überbrücken; unter anderem hatte er eine Bridge zwischen der physischen Netzwerkkarte des PC und einem der virtuellen Interfaces der virtuellen Maschine gebaut. Dummerweise läuft auf diesem ein DHCP-Server, der nun dank der Bridge auch die anderen PC im LAN mit – vollkommen unsinnigen – Netzwerkeinstellungen versorgte.

Moral 1: Getrennte Test-Netzwerke sind trotz virtueller Maschinen kein hohler Wahn.

Moral 2: Wer beizeiten übt, die CAM-Tabelle aus seinem Switch auszulesen, braucht keine halbe Stunde, um seinen Michi aufzuspüren.

http://www.heise.de/netze/artikel/D...Schicken-Sie-uns-Ihre-Geschichten-221726.html

Und was den "Bullshit" angeht:

DHCP sind Router und Computer mit einer Netzwerkkarte sind keine Layer 3 Geräte

1. DHCP-Server verteilen IP Adressen und arbeiten damit auf Layer 3.
2. Die Schnittstelle am Computer heißt "Ethernetschnittstelle", und nicht "TCP/IP-Schnittstelle". Sie arbeitet auf Layer 2. (Wenn man z.B. Token Ring statt TCP/IP verwendet, ist es immer noch eine Ethernetschnittstelle.)
3. TCP arbeitet auf Schicht 4.

 

[plan_b]

Das gilt für die Schnittstelle. Allerdings hat der Rechner nicht nur eine Schnittstelle sondern auch ein Betriebsystem hinten an. Zudem Routet ein DHCP Server nicht, mit der Schicht im Modell hat das ganze nichts zu tun.

EDIT: In deinem Beispiel routet übrigens der Client von michi, diesem wird nämlich gesagt er soll die Pakete der virtuellen Schnittstelle an das physikalische routen.

 

[think_pad]

Das gilt für die Schnittstelle. Allerdings hat der Rechner nicht nur eine Schnittstelle sondern auch ein Betriebsystem hinten an. Zudem Routet ein DHCP Server nicht, mit der Schicht im Modell hat das ganze nichts zu tun.
EDIT: In deinem Beispiel routet übrigens der Client von michi, diesem wird nämlich gesagt er soll die Pakete der virtuellen Schnittstelle an das physikalische routen.

So einfach ist es nicht:

1. Die Netzwerkkarte samt Treiber für den Gerätemanager stellt Layer 1.
2. Die Implementierung des Ethernetprotokolls stellt Layer 2. (So kauft man die Hardware als Ethernetschnittstelle: Man kriegt ein Stück Hardware, einen Treiber und dazu das Protokoll Ethernet.)
3. Nun kommt das Betriebsystem und implementiert Layer 3 und 4: IP und TCP oder IPX/SPX oder IPv6 oder etwas anderes....

Ein DHCP-Server "routet" selbst nicht, braucht aber einen Router auf Layer 3, um seine IP-Adressen auszuliefern. In unserem Beispiel des TE haben wir mit der Bridge in Wirklichkeit einen Ethernet-Switch (Layer 2), der als Nebentätigkeit zusätzlich über einen Dienst auch noch als DHCP-Server (IP) fungiert, also Layer 3.

Der Fehler des TE tritt auf, weil seine Bridge mit dem vermutlich aktiven und gebridgten DHCP-Server den physischen Access Point "lahmlegt". Der Access Point des Handys kann dagegen ungestört arbeiten, weil er sich selbst als einzigen DHCP-Server betrachtet und alle anderen Signale verwirft.

 

[schoerg]

Der Fehler des TE tritt auf, weil seine Bridge mit dem vermutlich aktiven und gebridgten DHCP-Server den physischen Access Point "lahmlegt". Der Access Point des Handys kann dagegen ungestört arbeiten, weil er sich selbst als einzigen DHCP-Server betrachtet und alle anderen Signale verwirft.

Hör auf diesen Blödsinn zu erzählen. Das stimmt einfach nicht was du da schreibst.

 

[think_pad]

Hör auf diesen Blödsinn zu erzählen. Das stimmt einfach nicht was du da schreibst.

Bitte keine Beschimpfungen!

Es liegt doch auf der Hand: Mit einem Access Point vom Handy funktioniert die Bridge, mit dem Pirelli-Access Point offenbar nicht. Es gibt also etwas, was den Pirelli-Access Point stört. Beide verwenden TCP/IP, also liegt der Fehler offenbar auf IP-Ebene. In der heise-Geschichte steht genau das, dass eine aktive Bridge einer VM das physische Netz versucht, mit IP-Adressen zu versorgen, was den IP-Verkehr stört. Das wird hier auch so sein, aber bestätigen kann das nur der TE.

Entweder verwendet man den DHCP der Bridge weiter und trennt die Subnetze, oder man vergibt alle IP-Adressen von Hand.

 

[schoerg]

Bitte keine Beschimpfungen!

War keine.

Es liegt doch auf der Hand: Mit einem Access Point vom Handy funktioniert die Bridge, mit dem Pirelli-Access Point offenbar nicht. Es gibt also etwas, was den Pirelli-Access Point stört. Beide verwenden TCP/IP, also liegt der Fehler offenbar auf IP-Ebene. In der heise-Geschichte steht genau das, dass eine aktive Bridge einer VM das physische Netz versucht, mit IP-Adressen zu versorgen, was den IP-Verkehr stört. Das wird hier auch so sein, aber bestätigen kann das nur der TE.

Die Heise-Geschichte hat nichts mit dem hier zu tun. Es liegt am Pirelli. Der kann offenbar keine 2 MAC-Adressen von einem WLAN-Client handhaben. Das Smartphone aber schon.

Entweder verwendet man den DHCP der Bridge weiter und trennt die Subnetze, oder man vergibt alle IP-Adressen von Hand.

Der Fehler hat absolut nichts mit DHCP oder IP-Adressen zu tun.

 

[think_pad]

Der Fehler hat absolut nichts mit DHCP oder IP-Adressen zu tun.

Das wäre auch eine Möglichkeit, ist aber noch nicht bewiesen! MAC-Adressen sind Layer 2, der Fehler träte auf Ethernetebene auf, und das lässt sich sehr schwer beweisen. Die einzige Möglichkeit wäre, einen anderen Router auszuprobieren.

 

[schoerg]

Das wäre auch eine Möglichkeit, ist aber noch nicht bewiesen! MAC-Adressen sind Layer 2, der Fehler träte auf Ethernetebene auf, und das lässt sich sehr schwer beweisen. Die einzige Möglichkeit wäre, einen anderen Router auszuprobieren.

Natürlich ist das bewiesen. Ich betreibe meine VMs nur Bridged und da hat noch nie ein DHCP-Server dazwischengefunkt der da nicht hingehört hätte.

Ich rate dir dringend die richtigen Begriffe zu studieren. Ein anderer Router ist da nämlich fachlich falsch. Ein anderer AP gehört her.

 

[think_pad]

Der Fehler hat absolut nichts mit DHCP oder IP-Adressen zu tun.

Wenn man den DHCP-Dienst auf dem Host und auf dem Pirelli abschaltet, und einmal Router-, Host- und VM-Adapter-Adresse von Hand vergibt, und es immer noch nicht geht, (er kann dann noch nicht mal pingen), dann ist es ein MAC-Fehler (Layer 2).

Man kann auch im Host in der CMD-Box "ipconfig /all" eingeben und dann nachschauen, ob MAC- und IP-Adressen korrekt dargestellt werden, für den Router/AP reicht ein ping. Werden die MAC-Adressen korrekt angegeben, aber falsche IPs, ist es ein Layer 3- Fehler.

Mit einem Router meine ich in diesem Fall natürlich den AP. Ein laufender DHCP-Server ist völlig belanglos, wenn er in einem anderen Subnetz arbeitet, dann findet er halt keinen Adapter, den er mit der IP beglücken kann. Problematisch ist nur wie in der Geschichte, wenn ein DHCP-Server wildfremde Adapter erreicht, die auf eine IP-Adresse von jemand ganz anderes warten.

Es ist also beides möglich...

 

[schoerg]

Wenn man den DHCP-Dienst auf dem Host und auf dem Pirelli abschaltet, und einmal Router-, Host- und VM-Adapter-Adresse von Hand vergibt, und es immer noch nicht geht, (er kann dann noch nicht mal pingen), dann ist es ein MAC-Fehler (Layer 2).

Wird nicht gehen, da DHCP nichts damit zu tun hat.

Man kann auch im Host in der CMD-Box "ipconfig /all" eingeben und dann nachschauen, ob MAC- und IP-Adressen korrekt dargestellt werden, für den Router/AP reicht ein ping. Werden die MAC-Adressen korrekt angegeben, aber falsche IPs, ist es ein Layer 3- Fehler.

Was soll da inkorrekt dargestellt werden? Die MAC-Adresse ist fix, dieser Wert ändert sich nicht. (Außer man macht es manuell, davon gehe ich jetzt mal nicht aus)
Zumal auch mehrere IP-Adressen einer MAC-Adresse zugewiesen sein können.

Mit einem Router meine ich in diesem Fall natürlich den AP. Ein laufender DHCP-Server ist völlig belanglos, wenn er in einem anderen Subnetz arbeitet, dann findet er halt keinen Adapter, den er mit der IP beglücken kann. Problematisch ist nur wie in der Geschichte, wenn ein DHCP-Server wildfremde Adapter erreicht, die auf eine IP-Adresse von jemand ganz anderes warten.

Nein, hier widersprichst du dir selber. Ein DHCP-Server vergibt eine IP in dem von ihm definierten Subnetz. Ein DHCP-Client benutzt 255.255.255.255 als Ziel-IP. Auf die dann ein oder mehrere Server antworten können.

Es ist also beides möglich...

Nein. Ich wiederhole mich: Virtualbox stellt keinen DHCP-Server im Bridge-Modus. VMware genausowenig.

 

[Lokheizer]

Kriegt euch bitte nicht in die Haare.

Verstanden habe ich das alles eigentlich nicht, was ihr da so ausdiskutiert. Aber anscheinend ist es fakt, dass unser Router Bridged eben nicht will.

 

[think_pad]

Verstanden habe ich das alles eigentlich nicht, was ihr da so ausdiskutiert.

Ganz einfach:

• Schoerg behauptet, der Pirelli mag es nicht, wenn neben der MAC-Adresse Deines WLAN-Adapters am Laptop noch eine andere virtuelle MAC-Adresse eines Adapters läuft. (Layer 2)
• Ich behaupte, dass vermutlich ein DHCP-Server auf der Bridge mitläuft und den Pireli mit falschen IP-Adressen versorgt. (Layer 3)

Was wir brauchen, ist Folgendes:

1. Zunächst verbindest Du Deinen Laptop mit dem Handy und sorgst dafür, dass die VM Internet hat.
2. Dann öffenst Du auf dem Host die CMD-Box und gibst "ipconfig /all" ein. Danach kopierst Du das Ergebnis in eine Textbox und postest es hier.
3. Das gleiche machst Du noch einmal mit dem Pirelli-Access Point, und postest auch dieses Ergebnis.

Anhand der unterschiedlichen IP- und der MAC-Adressen können wir hoffentlich sehen, was da los ist....

Danach ist der Streit beendet und einer von uns wird "Administrator des Monats"...

 

[martina]

Das Problem liegt ganz einfach im WLAN Standard, der nur eine Peer-to-Peer Verbindung auf Layer 2 definiert. Damit erlauben standardkonforme Geräte nur eine MAC-Adresse auf der Client-Seite.
Wenn jetzt der Bridge-Mode aktiviert wird, erscheint eine zweite MAC-Adresse auf dieser Verbindung, die MAC-Adresse des (virtuellen) Ethernet-Adapters der VM, welche auch auf Layer 2 "mitspielen" will. DHCP oder Routing hat hiermit nichts zu tun.

Es funktiert oft, da sich viele AcessPoints an dieser Stelle (zum Glück für den Benutzer) an dieser Stelle nicht ganz an den Standard halten und mit mehreren MAC-Adressen umgehen können.