Hallo, ich habe eine frage zu einer virtuellen Maschine. An für sich ist das ja nur eine Software? Also kein richtiger PC. Aber wo läuft diese Software? Bei mir lokal auf meinem Rechner? Ich habe lokal eine Datei *.vmx und mit VMware Workstation kann ich auf die 'Virtuelle Maschine' zugreifen. Komme jetzt nur ich alleine darauf? Oder können andere sich mit genau der selben (gleichzeitig?) verbinden? Es sind ja Tools und Dateien darauf. Aber wenn es ja quasi nur eine Software ist und bei mir lokal ist, wie können dann andere die Selben Dateien haben? Ich weiß, dass diese Fragen wahrscheinlich für die meisten lappallop sind. Aber ich habe da doch noch etwas verständnisprobleme und dazu keine Antworten gefunden.
Jonas schrieb: > An für sich ist das ja nur eine Software? Also kein richtiger PC. Das ist aus Sicht der VM ein richtiger PC, mit geringem Leistungsverlust, was Prozessorleistung angeht. Bei AMD hat man so gesehen einen AMD Prozessor (fast der echte) mit Intel Chipsatz (simuliert). Heutige Prozessoren besitzen spezielle Befehle zur effizienteren Unterstützung des Hypervisors (die Virtualisierungs-Engine). > Aber wo läuft diese Software? Bei mir lokal auf meinem Rechner? Ja, die Workstation läuft auf Windows oder Linux. Es gibt natürlich auch grössere Virtualisierungsumgebungen für Unternehmen, VMware ESXi. Da läuft die Virtualisierung selbständig auf der Server-Hardware, ohne Windows oder Linux dazwischen. > Komme jetzt nur ich alleine darauf? Oder können andere sich mit genau > der selben (gleichzeitig?) verbinden? Es kann für ein Image nur eine aktive VM geben. Mit Tools in der VM ist aber drag-and-drop zwischen GUI-Host und VM möglich. Zudem steht in der VM auch Networking zur Verfügung, mit dem u.A. auch auf Exports des Hosts zugegriffen werden kann.
:
Bearbeitet durch User
A. K. schrieb: > Es kann für ein Image nur eine aktive VM geben. Das stimmt so nicht. Solange man nur lesend auf das Image zugreift, ist das OK. Schreibend bekommt man halt dann Datensalat.
Die VM läuft durch VMware Workstation lokal auf deinem PC. Da kommst auch erstmal nur du rauf. Derjenige der das VM Image erstellt hat kann aber ggf. in der VM ein Netzlaufwerk zu einem zentralen Server oder ein FileSync eingerichtet haben mit dem sich bestimmte Ordner synchronisieren können. Auf deinen PC (Hostsystem) Kommt allerdings niemand drauf (idR)
Mit Zb Vmware Workstation kann man auch Shared VM's anlegen. Diese kann man dann auch von einem anderen PC aus verwenden. Aber erst mal nur in deinem Heimnetz. Wenn du dir nur über die Sicherheit Gedanken machst. Das ist keine Cloud. Es liegt alles in deiner Hand. Aber jede VM ist ein eigenes System ggf mit Anbindung an das Netzwerk und Internet.
Dann ist das aber so, dass die VM von mir aus auf irgend einem Server liegt, aber nur ich drauf komme. Also als ob das wirklich ein Rechner ist, der neben mir steht. Heißt, alle Daten, die ich z.B. in Dokumente ablege sind auch nur für mich sichtbar. Da andere Leute, die die VM benutzen, quasi ihre eigene haben.
VM ist ein weites Feld, da gibt es viel zu wissen und zu unterscheiden,
wenn man will. Eine VM ist KEIN Emulator. Es gibt Virtualizer vom Typ 1
(z.B. VMWare ESXi, MS Hyper-V), die quasi direkt auf der Hardware laufen
("bare metall"). Und es gibt sie vom Typ 2 (z.B. VMWare Player oder
VirtualBox), die ein laufendes Betriebssystem als Umgebung erfordern.
Allen gemeinsam ist, dass man sie eintweder lokal "direkt" ansehen und
bedienen kann oder man sich per RDP/VNC o.ä. draufschaltet - z.B. wenn
die VM auf einem Server läuft.
Bei einer VM wird mindestens der Prozessor der Hostmaschine quasi
"durchgereicht", also z.B. Intel/AMD. D.h. man kann nur Betriebssysteme
installieren, die auch auf dem gegebenen Prozessor laufen. z.B. kann man
unter Mac OSX auf einem Mac mit Intelprozessor problemlos eine
VirtualBox mit Windows oder Linux einrichten. Oder umgekehrt.
Emulatoren (z.B. QEMU) spielen im Gegensatz dazu selbst den Prozessor in
Software nach, so dass auch völlig fremde Architekturen ausgeführt
werden können (z.B. Mobile-OS für ARM oder Spielkonsolen usw.)
Eine VM, die z.B. Windows ausführt, unterliegt den gleichen "Gestzen"
wie ein realer Computer. D.h. er verfügt über eine lokale Benutzer- und
Rechteverwaltung oder kann Mitglied einer Domäne sein. Er kann Volumes
mit verschiedenen Rechten freigeben oder sich mit solchen verbinden. Die
"Rechtslage" hängt also nur von der Konfiguration ab.
:
Bearbeitet durch User
> Eine VM, die z.B. Windows ausführt, unterliegt den gleichen "Gestzen" > wie ein realer Computer. Nicht ganz. Ich hab gestern ein WinXP auf einem Linux mit einem Ryzen3700 in Betrieb genommen. Das wuerde ohne den Linuxunterbau vermutlich nicht funktionieren weil man keine Treiber fuer die aktuelle Hardware haette. So schnell ist der olle Microsoftkram noch nie gerannt. :-) Olaf
DPA schrieb: > Das stimmt so nicht. Solange man nur lesend auf das Image zugreift, ist > das OK. Schreibend bekommt man halt dann Datensalat. Das stimmt so auch nicht. Stichwort Linked Clones.
Jonas schrieb: > Aber wenn es ja quasi nur eine Software ist und bei mir lokal > ist, wie können dann andere die Selben Dateien haben? ?? Wie könnte man das erkennen? (man kann schon mal durcheinander kommen..) Eines der einfacheren Beispiele einer "VM", wäre einen kleinen 4-Bit Compi versuchen zu simulieren. Dazu gibt es unterschiedliche Ansätze, wie Schaltkreisemulation, oder Ausgabeemulation oder noch andere. Die Software dazu (für den fertigen "Imitator") kann man sich selber schreiben, oder falls der 4-Bit Compi gute Verbreitung hat, dann kann man sich die dazu passende Software besorgen. Mit "maschine" ist eher ein Gesamtpacket gemeint also z.B. einen Rechner mit Betriebssystem, Treiber, Anwendungssoftware und sogar Netzzugriff. Wo es noch ein wenig hapert, ist 3D-Leistung. Bei Linux ist es sogar so, ohne Netzzugriff kein Linux ("Lies doch die Doku!" "Aber die ist doch Online!" ..usw.) D.h. eine "VM" die eine Linuxkiste sein soll, muss Netzzugriff haben, braucht dafür aber keine starke 3D-Leistung.
DPA schrieb: >> Es kann für ein Image nur eine aktive VM geben. > > Das stimmt so nicht. Solange man nur lesend auf das Image zugreift, ist > das OK. Schreibend bekommt man halt dann Datensalat. ... oder eine Sperre. Klar, es gibt die Möglichkeit, Images read-only anzusprechen, aber der Normalfall ist das nicht. Und für Datenaustausch ist es der falsche Weg.
Daffy schrieb: > Das stimmt so auch nicht. Stichwort Linked Clones. Für jemanden, der erst einmal eine normale VM verstehen will?
Daffy schrieb: > DPA schrieb: >> Das stimmt so nicht. Solange man nur lesend auf das Image zugreift, ist >> das OK. Schreibend bekommt man halt dann Datensalat. > > Das stimmt so auch nicht. Stichwort Linked Clones. Doch, das stimmt so. Linked Clones sind semantisch gesehen immernoch unterschiedliche Images/Festplatten. In wie viele Dateien die verteilt sind, und wie diese komprimiert & formatiert sind, ist irrelevant.
Jonas schrieb: > Ich habe lokal eine Datei *.vmx und mit VMware Workstation kann ich auf > die 'Virtuelle Maschine' zugreifen. Die *.vmx ist auch eine Virtuelle Festplatte. Die VMware Workstation verändert diese auch, wenn du die virtuelle MAschine laufen lässt. Wenn du die *.vmx auf einen anderen Rechner kopierst, ist das dann eine andere virtuelle Maschine. Wenn in der *.vmx Serverdienste angeboten werden und der Host so eingestellt ist, dass das Netzwerk raus geht, können auch andere auf die virtuelle Maschine zugreifen. Was genau die machen können, hängt von den Einstellungen ab.
Dirk B. schrieb: > Die *.vmx ist auch eine Virtuelle Festplatte. Die *.vmx, *.vmxd, *.vmxf Files enthalten diverse Infos zur Konfiguration von VM und Images. Die Disks-Images selbst heissen *.vmdk. > Wenn du die *.vmx auf einen anderen Rechner kopierst, ist das dann eine > andere virtuelle Maschine. Es sollten alle Files kopiert werden, ausser *.log.
:
Bearbeitet durch User
DPA schrieb: > Doch, das stimmt so. Linked Clones sind semantisch gesehen immernoch > unterschiedliche Images/Festplatten. In wie viele Dateien die verteilt > sind, und wie diese komprimiert & formatiert sind, ist irrelevant. Im Normalfall sind es pro Instanz exakt 2 Images: Das Baseimage, und das Differencing-Image. Das Baseimage teilen sich alle Clones die davon erstellt wurden, und ohne dieses Baseimage (üblicherweise das OS) bootet keiner der Clones. Von der Base wird nur gelesen, Änderungen sind im Diff. Daher kann man in allen Clones sehr wohl schreiben und produziert eben keinen Datensalat. A. K. schrieb: > Für jemanden, der erst einmal eine normale VM verstehen will? Mir ging es bei dem Kommentar nur um die Richtigstellung, nicht darum es OP zu erklären. Jonas schrieb: > Komme jetzt nur ich alleine darauf? Oder können andere sich mit genau > der selben (gleichzeitig?) verbinden? Es sind ja Tools und Dateien > darauf. Aber wenn es ja quasi nur eine Software ist und bei mir lokal > ist, wie können dann andere die Selben Dateien haben? Wenn Du das Netzwerk der VM wie bei jedem anderen OS auch konfigurierst, dann könnte Gott und die Welt drauf. Und zwar mit den OS-üblichen Tools, also zB RDP bei Windows, oder SSH bei Linux. Analog funktionieren auch entsprechende Dienste. So habe ich zB bei uns in der Firma einen KVM Cluster, auf dem über ein Dutzend VMs laufen. Ob die nun als VM laufen, oder Bare-Metal ist für den Benutzer irrelevant, bzw erst garnicht erkennbar (ok, mal Fingerprinting außen vor). rbx schrieb: > Bei Linux ist es sogar so, ohne Netzzugriff kein Linux ("Lies doch die > Doku!" "Aber die ist doch Online!" ..usw.) > D.h. eine "VM" die eine Linuxkiste sein soll, muss Netzzugriff haben, > braucht dafür aber keine starke 3D-Leistung. Äh, was? 'Türlich geht eine Linux-VM ohne Netzwerk.
Daffy schrieb: > DPA schrieb: >> Doch, das stimmt so. Linked Clones sind semantisch gesehen immernoch >> unterschiedliche Images/Festplatten. In wie viele Dateien die verteilt >> sind, und wie diese komprimiert & formatiert sind, ist irrelevant. > > Im Normalfall sind es pro Instanz exakt 2 Images: Das Baseimage, und das > Differencing-Image. Das Baseimage teilen sich alle Clones die davon > erstellt wurden, und ohne dieses Baseimage (üblicherweise das OS) bootet > keiner der Clones. Von der Base wird nur gelesen, Änderungen sind im > Diff. Daher kann man in allen Clones sehr wohl schreiben und produziert > eben keinen Datensalat. Diese schreiben aber eben nicht in das selbe Image. Jedes paar aus "Baseimage" und "Differencing-Image" sind hier als eigenes Image zu betrachten. In anderen Worten, jede VM hat immer noch ihr eigenes Image, und schreibt nur in ihr eigenes Image. Es schreiben eben nicht alle ins selbe Image. Das es hier ein Baseimage und Differencing-Image gibt ist aber auch vollkommen irrelevant. Auch wenn die alle in einem Zip File wären und man das als Image bezeichnen würde, oder das sonst wie formatiert & komprimiert wäre, würde ich das nicht als in das selbe Image schreiben betrachten.
DPA schrieb: > Diese schreiben aber eben nicht in das selbe Image Was ich auch nirgends behauptet habe. DPA schrieb: > Das es hier ein Baseimage und Differencing-Image gibt ist > aber auch vollkommen irrelevant. Ist es nicht, weil nur so mehrere VMs das gleiche Baseimage gleichzeitig nutzen können.
Daffy schrieb: > DPA schrieb: >> Das es hier ein Baseimage und Differencing-Image gibt ist >> aber auch vollkommen irrelevant. > > Ist es nicht, weil nur so mehrere VMs das gleiche Baseimage gleichzeitig > nutzen können. Sowas kann man auch anderweitig erreichen. Beispiel: Kopiere ein Image auf einem CoW Dateisystem. Dann hast du 2 Images, aber die Daten sind nur einmal auf der Platte. Kopiert werden auch nur die Blöcke, die sich ändern, und zusammenführen kann man übereinstimmendes auch wieder. Hier würde aber auch niemand von der gleichzeitigen Nutzung des selben Image reden, warum sollte ich die selbe Sache in einem anderen Layer mit anderem Format dann anders betrachten? Die Dateien (Base Image und Differencing-Image), bieten den VMs zusammen unterschiedliche Images, aber warum sollte nun bei der Betrachtung der Benutzung der Images, wie das ein Layer tiefer umgesetzt ist, eine rolle spielen?
DPA schrieb: > Kopiere ein Image > auf einem CoW Dateisystem. Dann hast du 2 Images, aber die Daten sind > nur einmal auf der Platte. Kopiert werden auch nur die Blöcke, die sich > ändern, und zusammenführen kann man übereinstimmendes auch wieder. Hier > würde aber auch niemand von der gleichzeitigen Nutzung des selben Image > reden Ich glaube Du vermischt hier Snapshots und Dedup. Wenn Du bei LVM einen Snapshot erstellst, wandern die Änderungen hier auch in ein extra Diff was aber direkt an die Base gekoppelt ist und ohne diese nur Müll ist. Für die VM ist das aber vollkommen egal, da das OS der Clones da keine Unterschiede sieht. Aber laß mal, ich denke wir finden hier nicht näher zueinander und Du darfst gerne Recht behalten wenn es Dir so wichtig ist :)
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.