Von ultimasephrioth am Di, 20. Dezember 2005 um 14:21 #
Ich weiss, es ist Off-Topic, aber ich wollte wissen, ob man mit Xen auch gewisse Hardware direkt nutzen kann, z. B. die 3D-Beschleunigung einer Grafikkarte?
Von Frank Burkhardt am Di, 20. Dezember 2005 um 21:56 #
Das sollte kein Problem sein, da unter XEN ein relativ direkter Zugriff auf PCI-Devices möglich ist (wenn man das will) und damit auch die Grafikkarte direkt angesprochen werden kann.
Von Jörg W Mittag am Di, 20. Dezember 2005 um 18:06 #
Hi,
die Formulierung im Artikel ist etwas missverständlich. Es ist richtig, dass das von Fabrice Bellard geschriebene KQEMU keine freie Software ist. Nicht richtig ist jedoch, dass alle Accelerator Module nicht frei sind, denn QVM86 steht unter der GPL. Das steht zwar auch nicht im Artikel drin, aber man könnte den letzten Satz so interpretieren, dass es keine freien Accelerator Module gibt.
Von Stefan Becker am Di, 20. Dezember 2005 um 23:23 #
In der Qemu Mailing Liste findet man einige Patches, aber das ist sehr mühselig. Momentan ist die parallele Installation von gcc 3.x die einfachste Lösung.
Von Stefan Becker am Di, 20. Dezember 2005 um 18:37 #
-- Im Gegensatz zu Xen oder VMWare stellt Qemu keine virtuelle -- Maschine, sondern einen Emulator dar. Es emuliert die Hardware und -- stellt nicht wie im Falle der oben genannten Applikationen eine -- virtualisierte Schicht der Hardware bereit
Das stimmt so bei VMWARE nicht.
Bei VMWARE wird aus Sound sb16/es1371 und aus Grafik Nvidia, egal was drinne steckt. So viel anders ist das Konzept nicht als bei VMWARE, der Hauptunterschied liegt eigentlich in der Emulation der CPU. Die schaltet VMMWARE wirklich transparent durch.
Von Will der Hein am Di, 20. Dezember 2005 um 18:57 #
Dafür, dass du eine deinen Angaben nach eine "klasse Anleitung" geschrieben hast über Qemu, würfelst du ziemlich viele Sachen durcheinander VMware ist eine virtuelle Maschine, während Qemu ein Emulator ist. Das sind zwei Paar Schuhe. Vereinfach gesagt, ist VMware eine virtuelle Schicht eines PCs. Qemu dagegen emuliert einen kompletten Rechner/Architektur. Richtig ist, dass VMware manche Hardwarekomponenten dem Guest nicht bekannt gibt. Ist auch nicht nötig bzw. möglich, denn zwei Zugriffe auf eine und dieselbe HW von zwei verschiedenen Treibern, tödlich währen für das System. Aus diesem Grund stellt VMWare für den Sound einen Abstraktionslayer dem Guest-BS zur Verfügung. Man sollte allerdings diesen Layer nicht mit Emulation gleichsetzen, wie du es tust. Dies sind zwei Paar Schuhe, auch wenn es auf den ersten Blick gleich aussieht. Vorteil? Erheblich schneller als eine Emulation. Nachteil? Die Guest Architektur muss mit der Host-Architektur übereinstimmen.
Von Frank Burkhardt am Di, 20. Dezember 2005 um 22:05 #
> Aus diesem Grund stellt VMWare für den Sound einen Abstraktionslayer dem > Guest-BS zur Verfügung.
Gerade der Sound erfüllt bei VMWARE alle Vorraussetzungen, um Emulation genannt zu werden. Es werden dem Guest-System handfeste Hardwarekomponenten vorgegaukelt, die es im Host-System nicht gibt bzw. nicht geben muss. Dabei muss das Guest-System nicht wissen, dass es gerade nicht auf einem physischen Rechner läuft. Das selbe gilt für Netzwerk, VGA, CDROM, USB - also praktisch die gesammte Peripherie, die unter VMWARE zur Verfügung steht.
Eine zusätzliche Abstraktionsschicht wäre das, was z.B. Xen mit Blockdevices für die nicht-privilegierten Systeme macht. Die DomUs muessen auf eine Xen-typische Weise auf Blockdevices zugreifen (Hardwarezugriffe gehen da nicht) und werden auf beliebige Blockdevices der privilegierten Domain gemappt.
Von Will der Hein am Di, 20. Dezember 2005 um 23:02 #
Nur weil das System dem Guest etwas vorgaukelt, ist es noch lange keine Emulation. Siehe dazu Wine, das ebenfalls dem System, in diesem Fall der Applikation, eine nicht vorhandene Umgebung vorgaukelt. Wine ist trotz allem keine Emulation, sondern bildet nur die API von Windows nach um Emuliert keine Aufrufe. Das selbe gilt auch für VMware. Auch hier wird nichts emuliert, sondern die Aufrufe nur an die weitere Schicht geleitet. Im Gegensatz dazu emuliert Qemu die CPU-Instruktionen. Das ist zwar aus der Sicht des Users ein kleiner Unterschied, der aber das ausmacht, warum VMware und Xen schnell sind und Qemu durch seine Langsamkeit überzeugt.
Wo Du schon Xen ansprichst. Xen ist auch keine wirkliche virtuelle Maschine, sondern ein VMM. Dank Intels Vanderpool (VT) und AMDs Pacifica wird natürlich Xen alle Voraussetzungen einer VM erfüllen. Per Definition ist es aber im Moment ein Monitoring-Programm. Das sagt auch Xeon über sich: "Xen is a virtual machine monitor (VMM) for x86-compatible computers." Siehe: http://wiki.xensource.com/xenwiki/XenFaq
VMware ist ein Zwischending zwischen Virtualisierung und Emulation. Die CPU wird virtualisiert, aber Hardware wie der Intel 440BX Chipsatz, Symbios Logic 53c1030 SCSI-Controller, ES1371-Soundkarte (aka SB 64/128 PCI), AMD PCnet NIC und eine Matrox MGA G400 werden emuliert, was man auch daran sehen kann, dass das Guest-System die entsprechenden Treiber (bzw. Kernelmodule) lädt, und bis auf den BX-Chisatz habe ich nichts davon auf der echten Maschine. Es besteht bei einigen Betriebssystemen natürlich die Möglichkeit, spezielle VMware-Treiber zu nehmen (z.B. bei Grafikkarte und NIC), die dann tatsächlich mittels einer Kompatiblitätsschicht arbeiten, was sich aufgrund des zu erwartenden Geschwindigkeitszuwachs auch anbietet. Grundsätzlich ist es aber möglich, auch ohne spezielle VMware-Treiber zu arbeiten, was bei Exoten wie Zeta sehr praktisch ist.
Von Stefan Becker am Di, 20. Dezember 2005 um 23:35 #
"klasse" bezog sich auf die Software "Qemu".
Ehrlich gesagt ist das ganze Thema "Virtualisierung" / "Emulation" aus Anwendersicht (und das bin ich) Schall und Rauch.
Egal wie es sich nennt, sowohl bei Qemu als auch VMWARE startet ein kompletter PC mit eigenem Bios und Hardware, die nicht der Originalhardware entspricht.
Wäre das anders, würde ein VMWARE Image nicht auf beliebigen Rechnern laufen.
Ausnahmen bilden in beiden Fällen (bei Qemu inzwischen) die an externen Schnittstellen angeschlossenen Geräte. Dies, weil die Schnittstelle und nicht die externe Hardware nachgebildet wird.
Auch die Einschränkungen sind gleich, im echten PC eingebaute Hardwware kann eben nicht mit "echten" Treibern verwendet werden. Das die jeweilige Techniken auf verschiedenen Schichten beruht, ist richtig. Aber das Ergebnis ist für den Betrachter das gleiche.
Yoa! Ehrlich gesagt ist es mir "wurscht" wie das unter der Haube funktioniert (ob Paravirtualisierung, API-Virtualisierung, Interface-Virtualisierung...).
Es kommt doch nur auf folgende Punkte an: -einfach zu Bedienen / zu installieren, kein gefrickel (VMware) -wenig Overhead (Xen) -von Applikationsanbietern (SAP, Oracle...) akzeptiert/zertifiziert (Vmware[!], Xen?, Quemu?) -im Datacenter- und Enterprise-Bereich brauchbar --> derzeit nur VMware
Meine Meinung: Für zu Hause kann man all die Dinge verwenden. Auch als V-Host produktiv für Webserver usw. Aber bei ERP-Applikationen brauche ich außer mit VMware-ESX-Server nicht anfangen.
Meine Fragen: Hat jemand etwas anderes als VMware-ESX im Einsatz im Datacenter für SAP/Oracle/DB2? Wenn ja wie sind eure Erfahrungen?
Grüße, Pipe
PS: Eine gute Übersicht viele Virtualisierungen findet man hier: http://en.wikipedia.org/wiki/Comparison_of_virtual_machines
Von Dr. Tuxracer am Mi, 21. Dezember 2005 um 12:23 #
Ich denke, es macht derzeit im Einsatz einer Testumgebung Sinn. Ich nutze es z. B. für mein XP-HomeOffice. Xp läuft zwar langsam, kann mich aber nicht beklagen.
die Formulierung im Artikel ist etwas missverständlich. Es ist richtig, dass das von Fabrice Bellard geschriebene KQEMU keine freie Software ist. Nicht richtig ist jedoch, dass alle Accelerator Module nicht frei sind, denn QVM86 steht unter der GPL. Das steht zwar auch nicht im Artikel drin, aber man könnte den letzten Satz so interpretieren, dass es keine freien Accelerator Module gibt.
jwm
ist es möglich Qemu mit gcc >= 4 zu übersetzen?
Danke Jan
Ich habe spasseshalber meinen USB-Scanner unter Win98 mit OCR damit betrieben, das geht sogar.
-- Maschine, sondern einen Emulator dar. Es emuliert die Hardware und
-- stellt nicht wie im Falle der oben genannten Applikationen eine
-- virtualisierte Schicht der Hardware bereit
Das stimmt so bei VMWARE nicht.
Bei VMWARE wird aus Sound sb16/es1371 und aus Grafik Nvidia, egal was drinne steckt. So viel anders ist das Konzept nicht als bei VMWARE, der Hauptunterschied liegt eigentlich in der Emulation der CPU. Die schaltet VMMWARE wirklich transparent durch.
> Guest-BS zur Verfügung.
Gerade der Sound erfüllt bei VMWARE alle Vorraussetzungen, um Emulation genannt zu werden. Es werden dem Guest-System handfeste Hardwarekomponenten vorgegaukelt, die es im Host-System nicht gibt bzw. nicht geben muss. Dabei muss das Guest-System nicht wissen, dass es gerade nicht auf einem physischen Rechner läuft. Das selbe gilt für Netzwerk, VGA, CDROM, USB - also praktisch die gesammte Peripherie, die unter VMWARE zur Verfügung steht.
Eine zusätzliche Abstraktionsschicht wäre das, was z.B. Xen mit Blockdevices für die nicht-privilegierten Systeme macht. Die DomUs muessen auf eine Xen-typische Weise auf Blockdevices zugreifen (Hardwarezugriffe gehen da nicht) und werden auf beliebige Blockdevices der privilegierten Domain gemappt.
Gruss,
Frank
Wo Du schon Xen ansprichst. Xen ist auch keine wirkliche virtuelle Maschine, sondern ein VMM. Dank Intels Vanderpool (VT) und AMDs Pacifica wird natürlich Xen alle Voraussetzungen einer VM erfüllen. Per Definition ist es aber im Moment ein Monitoring-Programm. Das sagt auch Xeon über sich: "Xen is a virtual machine monitor (VMM) for x86-compatible computers." Siehe: http://wiki.xensource.com/xenwiki/XenFaq
Ehrlich gesagt ist das ganze Thema "Virtualisierung" / "Emulation" aus Anwendersicht (und das bin ich) Schall und Rauch.
Egal wie es sich nennt, sowohl bei Qemu als auch VMWARE startet ein kompletter PC mit eigenem Bios und Hardware, die nicht der Originalhardware entspricht.
Wäre das anders, würde ein VMWARE Image nicht auf beliebigen Rechnern laufen.
Ausnahmen bilden in beiden Fällen (bei Qemu inzwischen) die an externen Schnittstellen angeschlossenen Geräte. Dies, weil die Schnittstelle und nicht die externe Hardware nachgebildet wird.
Auch die Einschränkungen sind gleich, im echten PC eingebaute Hardwware kann eben nicht mit "echten" Treibern verwendet werden.
Das die jeweilige Techniken auf verschiedenen Schichten beruht, ist richtig. Aber das Ergebnis ist für den Betrachter das gleiche.
Ehrlich gesagt ist es mir "wurscht" wie das unter der Haube funktioniert (ob Paravirtualisierung, API-Virtualisierung, Interface-Virtualisierung...).
Es kommt doch nur auf folgende Punkte an:
-einfach zu Bedienen / zu installieren, kein gefrickel (VMware)
-wenig Overhead (Xen)
-von Applikationsanbietern (SAP, Oracle...) akzeptiert/zertifiziert (Vmware[!], Xen?, Quemu?)
-im Datacenter- und Enterprise-Bereich brauchbar --> derzeit nur VMware
Meine Meinung: Für zu Hause kann man all die Dinge verwenden. Auch als V-Host produktiv für Webserver usw. Aber bei ERP-Applikationen brauche ich außer mit VMware-ESX-Server nicht anfangen.
Meine Fragen:
Hat jemand etwas anderes als VMware-ESX im Einsatz im Datacenter für SAP/Oracle/DB2? Wenn ja wie sind eure Erfahrungen?
Grüße, Pipe
PS: Eine gute Übersicht viele Virtualisierungen findet man hier:
http://en.wikipedia.org/wiki/Comparison_of_virtual_machines
Xp läuft zwar langsam, kann mich aber nicht beklagen.
Gruß
Dr. Tuxracer