Diskussion:VMware/Archiv

Letzter Kommentar: vor 13 Jahren von 86.103.233.46 in Abschnitt VMware Server wird eingestellt ?

VMware ACE

Gibt es VMware ACE nicht mehr oder weiß niemand etwas darüber ? --PaulK 16:19, 12. Feb 2006 (CET)

Gibt's anscheinend noch: [| VMWare Home Page (deutsche Produktinfo)]

--(nicht signierter Beitrag von 80.135.151.101 (Diskussion) 15:25‎ , 10. Mai 2006)

Mac Version

Entgegen der Aussage hier: http://de.wikipedia.org/wiki/VMware#Vergleichbare_Produkte Es existiert auch eine Version für Mac OS X für PowerPCs, deren Portierung auf OS X für Intel-Macs aber nicht geplant ist.existiert sehr wohl eine Planung sowie inzwischen auch eine Beta für Intel-Macs. Hört auf den Namen Fusion. Wollt ich nur mal sagen.

Siehe: | Beta-Download | Ankündigung auf heise.de -- 04:31, 24. Dez. 2006 (CET)

Da bringst Du VMWare mit Virtual PC durcheinander. Fusion ist der Codename für *VMWare* für Mac. *Virtual PC* wird definitiv nicht auf Intel-Macs portiert. http://www.microsoft.com/mac/default.aspx?pid=macIntelQA Oefe 17:33, 24. Dez. 2006 (CET)

Player vs. Server

Worin liegt der Unterschied zwischen dem Server und Player, was die Lauffähigkeit von VMs angeht?

Beide sind kostenlos - aber der Player kann keine Maschinen erstellen. Warum also sollte ich mir den Player installieren oder gar Workstation kaufen, wenn Server kostenlos ist?! cljk 11:20, 8. Jan. 2007 (CET)

Prominentester Unterschied dürfte sein, dass die Worksation im Gegensatz zum Server über den Snapshot Manager verfügt; der Server kann nur "independent Disks" oder *einen* Snapshot. Wenn ich das gerade richtig sehe (die Workstation liegt mittlerweile ungenutzt in der Schublade), kann der Server auch kein D&D mit dem Hostsystem (wer's braucht ...). Im Gegenzug ist die Workstation nicht in Back/Frontend geteilt, die GUI muss also immer offen bleiben, was oft ein größerer Nachteil ist. Alles in allem hat VMware IMHO eine schwierige Ausgangsbasis, um die Workstation zu verkaufen. Frilled 10:00, 15. Feb. 2007 (CET)

Nun, der Player ist das Einstiegsprodukt zu Desktop-Virtualisierung, der Server das Einstiegsprodukt zu Servervirtualisierung. So kann der Server VMs als Dienst in Windows laufen lassen. Um sowas wie "den Desktop" der VM zu sehen (so er denn einen hat), muss man sich mit der Separaten Console mit der VM verbinden. Das kostet overhead, hat aber auch den Vorteil, dass man die VM auf dem vmware server laufen lassen kann, und von einem anderen Rechner aus darauf verbindet. Das sind alles ganz nette features, aber wenn ich wirklich ein desktop-system virtualisieren will, brauche / möchte ich das viellecht gar nicht. Da ist mir möglicherweise eine möglichst ungebremste Darstellung / Interaktion mit dem Desktop wichtiger. Und das bietet der Player, da ist weniger overhead drin, der hat also durchaus seine Daseinsberechtigung.(nicht signierter Beitrag von 89.244.190.244 (Diskussion) 22:02, 14. Okt. 2007)


Weitere Produkte

VMWare VDI, Lab Manager. Erwähnenswert?

die lange Sicht?

Virtualisierung ist sicher auch für Microsoft ein extrem wichtiges und strategisches Thema. Wie ist hier die Abgrenzung zu den Microsoft Produkten? Wie sind die Opensource virtuellen Maschinen zu bewerten?


Images

wäre es nicht interessant auf ein paar existierende Imagedateien einzugehen bzw. nen Downloadlink hinzuzufügen? ne Übersicht über alle bisherigen Imagesfiles im Netz wär mir natürlich am liebsten ;)

Schließe mich diesem Wunsch an. Besonders interessant wären die Images zu den wichtigsten Betriebssystemen bzw. Linux-Derivaten. (Suse, Ubuntu, Knopix, FreeDos, etc.) Es könnte sogar ein neuer Artikel ergeben, auf den die übrigen Betriebssystem-Artikel verweisen könnten. --Luc2 13:21, 10. Apr. 2007 (CEST)

Spring

Zur Spring übernahme steht hier nichts? -- 95.89.109.51 17:53, 8. Mär. 2010 (CET)

Browser-Applikation?

Ich glaube, gemeint sind "Appliances", nicht "Applikationen"? Schließlich handelt es sich um virtuelle Maschinen mit OS *plus* Browser-Applikation. Frilled

Took the liberty of being bold :P Frilled 13:25, 15. Feb. 2007 (CET)

Geschwindigkeit

Am Anfang heißt es "Die virtualisierten Betriebssysteme sind in Abhängigkeit vom Speicherausbau etwas langsamer als vergleichbare Installationen auf identischer Hardware." Das klingt, als sei die Geschwindigkeit einzig und allein vom Speicher abhängig, was so natürlich nicht stimmt. Insbesondere müssen sich die virtualisierten Maschinen Ressourcen wie Netzwerk und (meist der kritische Punkt) die Massenspeicher-I/O des Hosts teilen. Speicher hilft dabei nur begrenzt. Frilled

So?! [1] cljk 12:52, 15. Feb. 2007 (CET)
M.E. besser. Man könnte jetzt noch über Ressourcen klugschwätzen, aber ich glaube es reicht schon, wie's ist. Frilled


Vergleichbare Produkte

Unter "Vergleichbare Produkte" ist u.a. auch User Mode Linux aufgeführt, was nicht ganz in die Kategorie passt, da es keine virtuelle Maschine zur Verfügung stellt und ein speziell angepasstes System benötigt. Frilled 08:54, 19. Feb. 2007 (CET)

Parallels Workstation

Parallels Container stellen im Gegensatz zu auf Hypervisor basierenden Techniken (VMware, XEN..) eine OS-Virtualisierung dar. Die virtuellen Container arbeiten dabei besonders performant und ressourcenschonend. Dieser Satz könnte eine Erläuterung vertragen, inwieweit Parallels auf einen Hypervisor (VM Monitor) verzichtet (und damit angeblich besonders performant ist), zumal der Parallels Artikel selbst von einem Hypervisor spricht.

Vielleicht kann hier ein einheitlicher Bezug zum Artikel Virtualisierung (Informatik) helfen. Entsprechende Links füge mal ein. Ein einheitlicher Bezug der Artikel über Virtualisierungsprodukte darauf/dorthin wäre sicher hilfreich. -- Sarge 11:31, 13. Mai 2009 (CEST)

Allgemein

Auf die aktuelle Diskussionsseite kopiert ! --FZimmerb

"Hosted" Produkte

Es steht zu lesen ESX hätte einen "eigenen Kernel", während GSX und Server "Hosted-Produkte" seien. Tatsächlich hat ESX als Basis ein vorkonfiguriertes Linux mit Kernelanpassungen/erweiterung, keineswegs einen eigenen Kernel. ESX lässt sich also nicht auf bestehende Windows/Linux-Systeme neben anderer Software installieren, sondern läuft auf einem dedizierten System - im Gegensatz zu GSX (Server). Dennoch bleibt es ein Linux.

Zudem ist der Begriff "Hosted-Produkt" (zumindest mir so wie genutzt) nicht geläufig und der ganze Satz in Bezug zu og. Erläuterung auch irrelevant.

Jemand sollte IMHO die ersten Absätze umstricken.(nicht signierter Beitrag von 80.128.222.188 (Diskussion) 08:09, 19. Aug. 2007)

Das ist falsch. Zum Beispiel braucht die ESX Variante 3i kein Linux. Sollte ESX außerdem ein von Linux abgeleitetes Produkt sein, so müsste VMware die Quellen offen legen, was es nicht tut.(nicht signierter Beitrag von 76.199.101.226 (Diskussion) 04:34, 27. Dez. 2007)

Natürlich leitet sich ESX von Linux ab und natürlich bietet VMware eine OpenSource-Version von ESX an: http://www.vmware.com/download/vi/open_source.html#VI35 -- Ch.Boesch 08:44, 3. Feb. 2009 (CET)

@Ch.Boesch: Das wird durch einen Link nicht richtiger. Aus der Datei README unter VMware-esx-public-source-3.5.0-123629\vmklinux liest man "This module contains the linux emulation layer used by the vmkernel.". Du wirst in Deinem Link die Quellen fuer den eigentlichen vmkernel nicht finden. Fakt ist, dass der VMkernel ClosedSource ist und die Linux-Kompatibilitaets Layer (da auf GPL basierend) eben als OpenSource verfuegbar sind. Aufbauend auf diesen Layer nutzt VMware die vorhandenen Linux Hardware Treiber und linkt sie gegen diesen Layer, so dass der vmkernel diese nutzt. Binaer.

@?: Es mag ja sein, dass sich im Laufe der Weiterentwicklung manche Dinge ändern, in den VMware-FAQ stand jedenfalls bis vor kurzem das genaue Gegenteil, nämlich dass ein Linux 2.4 Kernel den "ESX virtualization layer" nachlädt. Mittlerweile wurde diese Seite jedoch vom Netz genommen, weswegen wir das auch nicht weiter diskutieren müssen. Es ist traurig wie jetzt eifrig versucht wird die Spuren der freien Software (in diesem Fall Linux) zu verwischen und das ganze mit Hilfe eines ebenfalls freien Mediums. -- Ch.Boesch 08:43, 13. Mär. 2009 (CET)

@Ch.Boesch: Das hat nichts mit verwischen von Spuren zu tun. VMware hat sich legaler Weise in älteren Versionen von ESX einem RedHat Enterprise Linux (RHEL) bedient welches für den Systemstart notwendig war, dann wurde der vmkernel geladen. Dieser trennte das RHEL vom ring 0 ab, legte sich selbst auf ring 0 und das RHEL auf ring 1. Damit war das RHEL ab diesem Zeitpunkt selbst eine virtuelle Maschine! Der vmkernel selbst ist und war schon immer closed Source, nur weil sich VMware zum Teil Open Souce verwendet und dies auch veröffentlicht heißt es nicht sie hätten was geklaut. Und Hintergrund warum diese Hinweise auf das Nachladen des vmkernels aus der Doku verschwunden ist, liegt einzig und allein daran, dass dies heute anders gelöst wird. Das aktuell auf CentOS basierende Console System bei vSphere 4 ist immer eine VM, da VMware eine eigene Bootumgebung gebaut hat welche die Service Console direkt als VM booten lässt. -- Dachrissi 11:39, 21. Sep. 2009 (CEST)

VMotion

VMotion ist ein wichtiges Feature. Wer sich aber für die technischen Details interessiert, sollte in die einschlägigen Paper schauen. Wikipedia ist ja ein Lexikon, kein Fachmagazin. Ich plädiere als für ein Korrektur des Abschnitts auf einen oder zwei Sätze.(nicht signierter Beitrag von 76.199.101.226 (Diskussion) 04:37, 27. Dez. 2007)

Zumal die Beschreibung der Details falsch ist. Ein dedizierter virtueller Switch ist keine Voraussetzung, es ist nur eine Empfehlung ein eigenes VMotion-Netzwerk aufbauen. Weiter: Die Bitmap wird zuerst erzeugt. Danach findet das Kopieren des Memorys statt. Während des Kopieres ändern sich schon kopierte Seiten, weil die VM ja weiterläuft. Die Änderungen werden in der Bitmap indikiert. Die Änderungen werden nicht dort abgelegt. Eigentlich ist die Bitmap eine Liste mit Memory Pages. Ändert sich eine Page, wird ein "Kreuzchen" gesetzt und diese Page wird später nochmal kopiert. Außerdem ist ein SAN keine Voraussetzung für VMotion. Es reicht ein Shared Storage, was ein SAN sein kann aber eben auch ein NFS. Was soll ein ARP-offer sein? Der VMkernel sendet ein RARP request ins Netz, der dafür sorgt, dass der phys. Switch bemerkt, dass die Maschine mit ihrer MAC nun an einem anderen pyhs. Port zu finden ist. --84.160.232.226 00:37, 2. Feb. 2010 (CET)

Die "Inoffizielle HCL"

unter VMware#VMware_Server-Produkte und weitere Sätze drumherum sind 1A-Wikipedia:Theoriefindung. Das könnt Ihr gerne auf Eurer Website oder so veröffentlichen, aber hier muss es leider gelöscht werden, wenn keine brauchbaren Quellenangaben hinzukommen. --MopskatzeMiau! 03:59, 2. Aug. 2008 (CEST)

Alternativen

"Vergleichbare Produkte für andere Plattformen"
Hier wird nur eine genannt.
Microsoft Hyper-V könnte man nachtragen, ich werde mich mal nach Informationen umschauen. --BlueScreen-Bertrand 12:58, 15. Okt. 2008 (CEST)

ESXi soll kostenlos sein

Auf der Seite steht: "Seit Ende Juli 2008 ist der VMware ESX Server in der Version 3i auch in einer kostenlosen Version verfügbar." Ich finde das nicht ganz richtig, denn soweit ich weiss, ist es nur Trial Free, also nicht generell frei.(nicht signierter Beitrag von 84.59.25.106 (Diskussion) 13:02, 3. Dez. 2008)

Worauf stützt Du diese Aussage? Mir ist keine solche Aussage seitens VMware bekannt, weder in der Software noch in den Nutzungsbedingungen. Wenn Du eine Quelle anführen kannst, lasse ich mich aber gerne eines Besseren belehren. --BloodReaver 11:40, 31. Dez. 2008 (CET)
Zur Orientierung: [2] Viele Grüße --Marsupilami (Disk|Beiträge) 20:16, 18. Mai 2009 (CEST)

Produkte: *in* Servern

„Für den Betrieb von Servern in virtuellen Maschinen“

Hm, sollte das nicht besser „mit virtuellen Maschinen“ heißen?

Ich hab das Teil selber länger im Einsatz gehabt. Der Witz ist doch, daß man einen VMware-Server laufen hat, der dann VMs hostet, die man über die GUI oder Shell administrieren kann. Ob dann in der VM auch was läuft, das als Server im virtuellen Netz agiert, ist an anderes Paar Schuhe eigentlich, oder?

So wird - obwohl eine Kleinigkeit in der Formulierung - das wesentliche Merkmal und damit der größte Unterschied zur Workstation gar nicht deutlich (abgesehen davon, daß die Workstation keine VMs erzeugen kann, das war zumindest früher immer so...)

Dieser Server läuft ja gerade als Dienst / Daemon, innerhalb dessen dann VMs gestartet werden können - unabhängig von einem UI. OK, der Server ist eine Art Framework und damit selbst eine VM eigentlich, aber er ist doch ein Server für VMs und keine VM für Server. -- Jabo 10:36, 10. Jul. 2009 (CEST)

Ja, Du hast das richtig gesehen. Und so habe ich das Missverständnis jetzt endlich korrigiert. Gruß -- Arjeh 22:16, 12. Nov. 2009 (CET)

VM allgemein

Wie mein Chef meint, ist es "ein geiles Stueck Software". Ich bin da eher reserviert. Hebelt es doch mit der Moeglichkeit, Systemzustaende zurueckzusetzen, diverse installierte Schutzmechanismen und damit die Integritaett i.A. aus, in dem man, zb durch einem Revert zu einem Pior-Snapshot den Zustand zuruecksetzt. Dem Hacker wird's freuen, dem sozial ambitioniertem graust es. --Traute Meyer 23:05, 10. Jul. 2009 (CEST) ("--" extra Bonus)

Vorweg: Eigentlich ist die Diskussion zwar interessant (gleich ein paar Zeilen aus meiner Sicht), aber an sich gehört die hier nicht so sehr hin, weil der Artikel ja als ein enzyklopädischer seine Berechtigung aus der Existenz einer Sache und bei Software auch der Relevanz / Verbreitung heraus erlangt.
Zu deinem Punkt: Das hängt extrem von der Installion und der verwendeten Virtualisierung ab. Eigentlich sollte ein Nutzer gar nicht selber die VM verwalten, sondern nur nutzen dürfen, was sogar über's Netz geht, d.h. jemand startet in seinem Userspace eine VM, hat aber keine Möglichkeit, deren Einstellungen zu manipulieren. Gerade bei VMware könnte man den Nutzern auf ihren Systemen die Workststion zur Verfügung stellen, während der Server, der die VMs hostet, auf einem ganz anderen Rechner den dortigen Admins zur Verfügung steht. Das ist nicht vergleichbar mit dem Szenario "freien VMware-Server auf (Heim-)PC installieren und damit herum spielen". Wer das in einer Firma so tut, sollte wissen, was er tut (und evtl. die Lizenzbedingungen noch mal lesen).
Außerdem gibt es noch ganz andere Virtualisierungstechniken, die schon auf früherer Ebene einen Rechner sozusagen "aufspalten", statt in einem Rechner ein Programm laufen zu haben, das selber ganze Rechner emuliert (Stichwort Paravirtualisierung).
Sowas wie VMware-Server an einem Arbeitsplatz hat aber auch seine Anwendungsbereiche, in denen oft gerade die Möglichkeit von Snapshots wichtig sind, beispielsweise Testumgebungen aufzubauen, in denen gearbeitet werden kann, ohne a) am eigenen System herum zu fummeln und b) Fehler und Probleme beim Test reversibel zu machen. Auch das Austesten von Netzwerkszenarien vor einer physischen Installation ist möglich. Oder eine Grundinstallation eines bestimmten OS zu haben, zu der man immer zurück kann und von der aus man dann bewußt Fehler provoziert (die z.B. bei einem Kunden aufgetreten sind), um dafür die Lösung zu suchen. Hinterher kommt der Zustand in die Tonne und der Grundzustand wartet auf seinen nächsten Einsatz.
Fazit: Es hängt vom Anwendunsszenario ab, was man wo und wie installiert. Die Vorteile und Risiken sind entsprechend. Diese Szenarien hier aber zu diskutieren, führt zu weit (ich meine diese Diskussion hier schon), das wäre was für einschlägige Foren und Newsgroups.
Wenn dein "Chef" mit seiner Installation in der genannten Weise unzufrieden ist, setzt er sie in produktiver Umgebung ein, ohne sie zu verstehen - oder er vertraut euch bewußt einfach. Bei uns ist auch fast alles für so ziemlich jeden zugänglich, das geht aber nur in kleinen Firmen, in denen sich alle kennen. -- Jabo 10:16, 11. Jul. 2009 (CEST)

Abschnitt Einsatzgebiete = blabla

Der Abschnitt Einsatzgebiete enthält zuviel allgemeines über virtuelle Maschinen. Sollte man mal entrümpeln. 86.103.202.116 13:23, 11. Jan. 2010 (CET)

Trennung von hosted und bare metal Virtualisierung

Auf die aktuelle Diskussionsseite kopiert ! --FZimmerb


VMware Server wird eingestellt ?

Siehe auch http://communities.vmware.com/message/1541289. Sollte das im Artikel reffletiert sein? -- 86.103.233.46 23:36, 14. Okt. 2010 (CEST)