Archiv verlassen und diese Seite im Standarddesign anzeigen : Virtualisierung - Pacifica vs Vanderpool
Da ich mich bei den Virtualisierungstechniken nicht auskenne...
was bieten die jeweiligen ansätze für Vorteile? Gibts irgendwo Benchmarks?
VMWare und auch VirtualBox unterstützen ja HardwareVirtualisierung...
inwieweit ist das schon brauchbar um z.b. unter Linux Games in einer VM laufen zu lassen und sich das lästige Rebooten ins Windows zu sparen...
Soweit ich weiß wird doch an 3d Beschleunigung gearbeitet bzw. ist schon möglich..
mir gehts nicht darum Crysis in einer VM laufen zu lassen sondern etwas anspruchslosere
Weiterhin würde mich interessieren ob Intel oder AMD CPUs (zwecks Neuanschaffung) hier Vorteile haben....
ShadowXX
2008-08-14, 02:11:15
Da ich mich bei den Virtualisierungstechniken nicht auskenne...
was bieten die jeweiligen ansätze für Vorteile? Gibts irgendwo Benchmarks?
VMWare und auch VirtualBox unterstützen ja HardwareVirtualisierung...
Die einzigen vorteile momentan sind das du unter einem 32Bit-OS ein 64Bit-OS in einer VM laufen lassen kannst.
Es gibt zwar auf dem Papier auch ein paar theoretische Geschwindigkeitsvorteile, aber die sind in real so klein das Sie vernachlässigbar sind.
Vielleicht ändert sich in der nächsten Gen was.
inwieweit ist das schon brauchbar um z.b. unter Linux Games in einer VM laufen zu lassen und sich das lästige Rebooten ins Windows zu sparen...
vergiss es.
Soweit ich weiß wird doch an 3d Beschleunigung gearbeitet bzw. ist schon möglich..
Ist im Alpha-Stadium und auch sehr low-tech.
Weiterhin würde mich interessieren ob Intel oder AMD CPUs (zwecks Neuanschaffung) hier Vorteile haben....
Momentan bezüglich Virtualisierung völlig egal.
k.a. ich hab bisher nur Intels VT getestet, welches von der Performance eigentlich ganz gut geht, sowohl in der VirtualBox OSE als auch in der VMWare
3D geht da noch nicht und das hat auch nix mit der CPU-Hardwarevirtualisierung zu tun, da müsste es GPU-Virtualisierung geben oder halt einen Grafiktriber für das virtuelle OS der das 3D von dem Host holt
Mit der VMware Workstation 6 soll aber angeblich 3D gehen
ShadowXX
2008-08-14, 02:14:26
k.a. ich hab bisher nur Intels VT getestet, welches von der Performance eigentlich ganz gut geht, sowohl in der VirtualBox OSE als auch in der VMWare
Ja, wahnsinnige 1-2% schneller als ohne.
Mit der VMware Workstation 6 soll aber angeblich 3D gehen
Vergiss es.
Da geht DX schlechter als Wine.
ja wine ist leider ziemlich buggy bei vielerlei software....einige sachen funktionieren tadellos andere garnicht und vieles dann wieder total verbuggt
gibts da irgendwo benchmarks das man sich einen überblick verschaffen kann?
also einmal was mit virtualisierungssoftware so drin wäre und dann was die hardwarevirtualisierung bringt...
1-2% hört sich ja ziemlich dürftig an
Ich verweise da gern mal auf Tecchannel.
AMD
http://www.tecchannel.de/server/virtualisierung/432777/
Intel
http://www.tecchannel.de/server/virtualisierung/402566/
Dann würde ich mir noch Xen anschauen, wo man mittels PCI Hide Optionen Hardware von der dom0 durchreichen kann.
MfG
dreas
2008-08-14, 09:30:27
Also ich habe letztens diverse Versuche unternommen mal Beyond Good & Evil unter Vista64
in ner VMWare5 in XP32 laufen zu lassen. Da das Game leider nicht unter 64bit funzt war das für mich der einzige Weg. Es lief zwar aber war ab den Bootsfahrten mit Wasserdarstellung nicht mehr spielbar. Leider! Das Spiel macht immer noch viel Spass aber extra parallel n XP32 zu installieren war mir dann doch zu viel.
mfg dreas
T4ch0n4d3l
2008-08-18, 00:44:59
Die einzigen vorteile momentan sind das du unter einem 32Bit-OS ein 64Bit-OS in einer VM laufen lassen kannst.
Dazu braucht man aber kein Vanderpool oder Pacifica.
T4ch0n4d3l
2008-08-18, 00:49:47
Die einzigen vorteile momentan sind das du unter einem 32Bit-OS ein 64Bit-OS in einer VM laufen lassen kannst.
Dazu braucht man aber kein Vanderpool oder Pacifica, der Virtual Mashine Monitor sollte ja auch mit Ring 0 Privilegien laufen und ist dem Kernel damit gleichgestellt. Im Ausführungsfalle übernimmt er die komplette Kontrolle über den PC und kann demzufolge in jeden verfügbaren Ausführungsmodi der CPU wechseln. Funktioniert auch mit VMware.
IMO machen die beiden Technologien die Umsetzung der Virtualisierung einfacher, jedoch nicht zwangsläufig schneller.
pool1892
2008-08-18, 16:36:51
es gibt schon gewichtige unterschied, an erster stelle sei nested paging genannt. der neueste (letztes update) esx server von vmware nutzt das (das feature hilft dabei, dass die cpu beim kontextwechsel die wahrscheinlichkeit für tlb-hits steigt und damit dann auch der cache nicht weggeflusht werden muss). k10 hat dafür eigene logik und vor allem vergrößerte tlb tables.
intel unterstützt nested pages erst mit nehalem.
das bringt laut amd um die 20% mehr leistung.
außerdem bringt vanderpool und pacifica sehr wohl was, allerdings nicht unbedingt auf maschinen, die eine virtuelle maschine betreiben. die beschleunigung des I/O mit geeigneter hardware ist besonders erwähnenswert...man muss einfach einsehen, dass virtualisierung primär servertechnik ist im moment.
vmware fusion kann auf macs durchaus directx 8 passabel beschleunigen.
Mich würde eher mal interessieren,was daraus geworden ist,mehrere Betriebssysteme gleichzeitig und getrennt voneinander auf einer CPU auszuführen?
Also ohne VMware und sowas, sondern zwei Betriebssysteme installieren und beide gleichzeitig laufen lassen (so wie bei Benutzeraccounts).Das soll ja angeblich gehen,nur wie?
DirectX kannst du vergessen,zumindest mit der Windows Software.
Da wäre eine schnellere CPU eigentlich sinnvoller,denn mit Swiftshader kannste das dann in Software berechnen lassen,das funktioniert wenigstens:)
Mich würde eher mal interessieren,was daraus geworden ist,mehrere Betriebssysteme gleichzeitig und getrennt voneinander auf einer CPU auszuführen?
Also ohne VMware und sowas, sondern zwei Betriebssysteme installieren und beide gleichzeitig laufen lassen (so wie bei Benutzeraccounts).Das soll ja angeblich gehen,nur wie?
Xen bietet sowas ähnliches mit Paravirtualisierung, allerdings ist dann trotzdem ein System der Hypervisor und muss zuerst booten.
Windows läuft darauf aber auch nur voll virtualisiert und ohne 3D-Beschleunigung.
Das Killerfeature wäre wirklich Linux und Windows parallel mit 3D-Support laufen zu haben, oder auch 32- und 64-Bit-Windows gleichzeitig.
ich frag mich sowieso warum man den umweg harddware-hostsystem-virtualisierung-gastsystem geht.
warum nicht hardware-virtualisierungssoftware-betriebssystem?
Aquaschaf
2008-08-18, 20:42:49
ich frag mich sowieso warum man den umweg harddware-hostsystem-virtualisierung-gastsystem geht.
warum nicht hardware-virtualisierungssoftware-betriebssystem?
Ersteres ist weniger aufwändig, weil die VM auf den APIs des Host-OS aufbauen kann. Bei Desktop-Systemen kann man mit dem Overhead der dadurch auf der anderen Seite entsteht leben.
warum nicht hardware-virtualisierungssoftware-betriebssystem?
Man erwartet üblicherweise von Virtualisierungssoftware, dass sie IO-Hardware für die Gastsysteme bereitstellt. Dafür braucht sie Treiber für den Zugriff auf die tatsächliche Hardware. Ohne Host-OS wird es schwer an Treiber zu kommen.
Nasenbaer
2008-08-18, 20:59:28
Man erwartet üblicherweise von Virtualisierungssoftware, dass sie IO-Hardware für die Gastsysteme bereitstellt. Dafür braucht sie Treiber für den Zugriff auf die tatsächliche Hardware. Ohne Host-OS wird es schwer an Treiber zu kommen.
Ich weiß nicht ob ich dich rchtig verstanden habe aber mit dem BIOS-Nachfolger EFI soll es ja auch möglich sein auf dessen Basis Treiber zur Verfügung zu stellen, also vollkommen OS-unabhängig.
Wie viel da möglich ist (also nur einfach Netzwerkanbindung oder doch weit mehr) weiß ich allerdings nicht und dank MS werden PC Nutzer wohl auch noch lange auf EFI warten dürfen.
..für DirectX i.v.m einer Windows-VM wäre ggf. noch SwitftShader eine Möglichkeit, ist aber grotten langsam.
cu
BUG
T4ch0n4d3l
2008-08-19, 00:03:32
ich frag mich sowieso warum man den umweg harddware-hostsystem-virtualisierung-gastsystem geht.
warum nicht hardware-virtualisierungssoftware-betriebssystem?
Die Virtualisierungssoftware muss aber zwangsläufig seinen eigenen Betriebssystemkern mitliefern. Irgendjemand muss sich ja um Hardwareresourcen und Prozessverwaltung kümmern. VMware ESX Server bringt zum Beispiel seinen eigenen Kernel mit, benötigt also kein 3rd party Host. Solange nicht die komplette Virtualisierung in Hardware realisiert werden kann, wird es auch dabei bleiben. Dann wären wir bei Hardware-BetriebssystemE.
Mfg,
Markus
Berni
2008-08-19, 02:48:07
Also ich habe letztens diverse Versuche unternommen mal Beyond Good & Evil unter Vista64
in ner VMWare5 in XP32 laufen zu lassen.
VMWare5 ist ja jetzt auch nicht gerade brandaktuell...
Die Virtualisierungssoftware muss aber zwangsläufig seinen eigenen Betriebssystemkern mitliefern.
natürlich, das wäre ja der sinn der sache, damit kann man einen eigenen kernel mitliefern und muss sich nicht an jenen des hostes anpassen.
Ars Technica Guide to Virtualization: Part II
When it comes to controlling write access to privileged state, the hardware's ISA can be either a huge help or a huge hindrance. The x86 ISA is the latter, a fact that makes virtualization on x86 hardware especially challenging.
Classical virtualization vs. x86-based virtualization
The trap-and-emulate technique that I've described above is an essential part of what's often called "classical virtualization." Classical virtualization is so called in order to distinguish it from the kind of virtualization that has been done on x86 systems prior to the recent introduction of Intel's VT-x technology. For reasons I'll discuss in the next installment, the trap-and-emulate technique just doesn't work on the x86 ISA, a fact that means that all virtualization on x86 hardware (pre-VT, of course) is either binary translation or paravirtualization. Even a software package like VMware, which most articles on virtualization place in the "full virtualization" category, still uses binary translation (BT) to control the OS's access to the CPU.
Why would a virtualization solution use binary translation—a technology typically reserved for translating between two separate ISAs—to run an x86-based OS on x86 processor hardware? The answer is that x86 unfortunately allows non-faulting write access to privileged state. In other words, the execution of some x86 instructions can have the side-effect of altering privileged state without triggering a fault that would alert a hypervisor to the fact that it needs to intervene and emulate the instruction. This feature of x86 makes classical, trap-and-emulate-based virtualization impossible to implement on x86 hardware prior to the introduction of VT-x.
http://arstechnica.com/guides/other/virtualization-guide-2.ars/2
Beruflich und privat beschäftige ich mich schon länger mit Virtualisierung und setzte daher selbst auf VMware Workstation und KVM (jeweils linux als host).
Anders als hier behauptet wird habe ich mit der 3D-Unterstützung unter VMware Workstation 6.5 interessante Erfahrungen gemacht. Als persönlichen proof-of-concept habe ich das mittlerweile betage Battlefield 2 in einer VM installiert und es läuft in mittleren Settings ruckelfrei. Die eingesetzte Hardware ist natürlich nicht ohne, Intel Core 2 Quad 9450, Nvidia 8800 GTS, aber es geht.
=Floi=
2008-12-14, 14:40:27
warum werden denn in den VM keine besseren grafikkarten integriert?
Eine GF7950GT als client würde ja schon dicke reichen.
warum werden denn in den VM keine besseren grafikkarten integriert?
Eine GF7950GT als client würde ja schon dicke reichen.
Wie meinst du das? Das die VM die Hardware einer G70 emuliert? Schonmal überlegt, dass die Spezifikationen davon nicht offen liegen? Und von Registerebene wieder auf OpenGL zu mappen ist auch nicht gerade einfach.
=Floi=
2008-12-14, 21:26:28
Man könnte ja mit NV oder AMD kooperieren. zumindest die leistungsfähigkeit und das featureset einer solchen karte wäre eben nicht schlecht in einer solchen VM. Das wollte ich damit ausdrücken.
Du musst ja selbst zugeben, dass eine aktuelle karte in einer solchen vm nur für anspruchslosestes 2d taugt und diese zeiten sind langsam vorbei. Virtualisierung hat auch im provaten bereich seine berechtigung und anwendungsbereiche.
Man könnte ja mit NV oder AMD kooperieren.
Nein könnte man nicht.
zumindest die leistungsfähigkeit und das featureset einer solchen karte wäre eben nicht schlecht in einer solchen VM.
eine vm die auf einem 486er host die leistungsfähigkeit eines core2duo erreicht wäre auch nicht schlecht, ist aber in etwa genau so realistisch wie deine wunschvorstellung.
Nasenbaer
2008-12-14, 22:49:55
eine vm die auf einem 486er host die leistungsfähigkeit eines core2duo erreicht wäre auch nicht schlecht, ist aber in etwa genau so realistisch wie deine wunschvorstellung.
Cool ein Perpetuum Mobile. :) Das wärs doch mal...
Im Forum von VirtualBox gibt zur 3D-Emulierung mal einen Post (http://forums.virtualbox.org/viewtopic.php?t=16) eines Entwicklers, der die verschiedenen Möglichkeiten beschrieben hat. Er beschreibt da gut die Probleme, die es dabei gibt.
Gerüchten zufolge soll es mal eine XEN-Betaversion gegeben haben, welche nativen PCI-Zugriff eines Gastsystems auf eine PCI-REssource des Hosts ermöglicht hat.
Sowas wäre IMHO ein realistischerer Ansatz 3D in eine VM zu kriegen (Man müsste dann eben den entsprechenden Grafiktreiber in der VM installieren)
Also eine SW-Emulation.
Andererseits soll es Möglichkeiten geben (VMWare Fusion z.b. nutzt AFAIK sowas ähnliches) die VM-Graka so zu bauen, dass sie von DirectX angesteuert werden kann und das ganze im Hintergrund z.b. auf OpenGL-Befehle für den Host zu übersetzen. Geht natürlich nur bis zu nem gewissen Grad.
Allerdigns sagt das nichts über die Qualität von Vanderppol/Pacifica aus.
Soweit ich weiß, sind die Phenoms in sachen Virtualisierungs-Features ein bisschen weiter als die Core2. erst der Core i7 schließt da vollends auf (nested paging etc.)
Aber inwieweit das tatsächlich irgendwo genutzt wird, ist ne andere Sache...
Allerdigns sagt das nichts über die Qualität von Vanderppol/Pacifica aus.
Soweit ich weiß, sind die Phenoms in sachen Virtualisierungs-Features ein bisschen weiter als die Core2. erst der Core i7 schließt da vollends auf (nested paging etc.)
Wenn ich das richtig verstanden habe (siehe z.B. ArsTechnica-Artikel), ist das mal wieder die "tolle" und "moderne" x86-ISA, die so etwas überhaupt braucht um auf aktuelle Anforderungen fit gemacht zu werden.
BlackBirdSR
2008-12-15, 13:35:12
Wenn ich das richtig verstanden habe (siehe z.B. ArsTechnica-Artikel), ist das mal wieder die "tolle" und "moderne" x86-ISA, die so etwas überhaupt braucht um auf aktuelle Anforderungen fit gemacht zu werden.
Niemand sagt, dass x86 toll ist ;)
Allerdings bekommt man es einfach nicht mehr los. Auf der anderen Seite: Aus der Not und Zwang entstehen meist die stärksten und besten Ideen. Niemand wird wohl bestreiten, dass die MicroArchitekturen hinter der x86-ISA mit zum besten auf dem Markt gehören, einfach weil sie es sein müssen, um mit x86 zu überleben.
Gerüchten zufolge soll es mal eine XEN-Betaversion gegeben haben, welche nativen PCI-Zugriff eines Gastsystems auf eine PCI-REssource des Hosts ermöglicht hat.
Dann steht diese Resource aber nicht mehr dem Host zur Verfügung. Gleichzeitiger Zugriff ist nicht möglich.
Wenn ich das richtig verstanden habe (siehe z.B. ArsTechnica-Artikel), ist das mal wieder die "tolle" und "moderne" x86-ISA, die so etwas überhaupt braucht um auf aktuelle Anforderungen fit gemacht zu werden.
Jain. Es geht ja darum, dass bei x86 einige Instructions ein anderes Verhalten im Kernel-Mode als im User-Mode haben, bzw. in beiden funktionieren und dabei keine Exception ausgelöst wird. Wenn man also einen Kernel im Userspace laufen lässt dann werden bestimmte Instructions nicht am ausführen gehindert und die VM kann den entsprechenden Opcode nicht emulieren. Pacifica und Vanderpool beheben dies.
Sache ist aber, dass z.B. VMWare um gute Performance zu erhalten sowieso den Code scannt und die Instructions direkt mit entsprechenden Jumps auf den Emulationscode ersetzt, weil das viel schneller ist als der Exception-Mechanismus.
Pacifica und Vanderpool sind vor allem für "faule" Virtualisierung gedacht. Xen kann damit z.B. ohne großen Aufwand auch Windows laufen lassen, ist dabei aber sehr langsam.
Deswegen gabe es auch mal nen Wissenschaftler der behauptet hat, X86 sei per definition nicht Virtualisierungsfähig ;)
Das war allerdings noch lange vor Vanderpool & co.
Der Hintergrund ist, dass es bei X86 priviligierte instruktionen gibt, die nicht getrapped werden können (wie gesagt, ohne vanderpool und co.)
Daher brauche man früher ha Code-Morphing-techniken etc. um die Virtualisierung hinzukriegen. (VMware macht das schon lange so)
Dass die Ressource dem Host nicht mehr zur verfügung steht ist klar, in dem Fall könnten z.b. SLI-Besitzer aber theoretisch eine Graka dem Host überlassen und die zweite der VM, dann wäre zumindest etwas gaming in der selbigen möglich ;)
Oder den host auf die chipsatzgrafik verdrahten un die ordentliche Graka in der VM nutzen etc.
Das Problem beim virtualisierten Zugriff auf PCI ist, dass die PCI-Geräte keine context-switches kennen. D.h. die Daten des hosts in der graka wären in dem moment futsch, wo der gast die Kontrolle übernimmt oder umgekehrt.
Übrigens ist XEN auf neuerer HW gar nicht mehr so langsam, weil durch nested paging z.b. jede Menge Verwaltungsoverhead beim Arbeitsspeicher der VM wegfällt.
Eigentlich ist die Virtuelle Maschine vom Host aus gesehen ja nur ein Prozess, der eine bestimmte Menge Speicher(-Seiten) zugeteilt kriegt.
Die VM muss das nun unter-segmentieren um das Paging für die Gäste bereitzustellen. Und genau das geht normalerweise mit jeder Menge VMEXIT-calls einher, die contextswitch zum Hypervisor auslösen.
Mit Nested paging fällt das weg, weil der Prozessor salopp gesagt, eine Speicherseite wieder in speicherseiten aufteilen kann, und das in Hardware.
Daher weniger VMExits = mehr performance.
Dass die Virtualisierungsfunktionen noch optimierungspotential haben ist wohhl unbestrietbar. Dennoch lüppt z.b. virtualbox 2.0 mit Vanderpool-Unterstützung auf den Yonah-Zwillingen in meinem Thinkpad alles andere als langsam.
Sogar KVM ist sehr flott, und das geht _nur_ mit vanderpool/pacifica.
ISA-Technisch gesehen sind z.b. PowerPC duchdachter für moderne Anwendungen, aber eben auch wesentlich jünger als X86!
Und x86 ist eben überall...
grüßchen
ich
VMware kauft Open-Source-Grafikspezialisten
"Die Tungsten-Entwickler sollen bei VMware an 3D-Fähigkeiten für Virtualisierungslösungen arbeiten"
http://www.golem.de/0812/64142.html
Pacifica und Vanderpool sind vor allem für "faule" Virtualisierung gedacht. Xen kann damit z.B. ohne großen Aufwand auch Windows laufen lassen, ist dabei aber sehr langsam.
Ja, wo der Kernel closed ist AFAIK.
Meine aber mal gelesen zu haben, dass die kommerzielle Xen-Version mit speziellen Treibern für die Windows-Virtualisierung daher kommt, so dass es von der Performance wesentlich flotter ist.
Übrigens ist XEN auf neuerer HW gar nicht mehr so langsam, weil durch nested paging z.b. jede Menge Verwaltungsoverhead beim Arbeitsspeicher der VM wegfällt.
Das bezieht sich jetzt aber auf Gäste die Xen kennen, oder? Habe ja nicht behauptet, dass das langsam wäre. Ist auch produktiv so im Einsatz bei mir ;)
Dass die Virtualisierungsfunktionen noch optimierungspotential haben ist wohhl unbestrietbar. Dennoch lüppt z.b. virtualbox 2.0 mit Vanderpool-Unterstützung auf den Yonah-Zwillingen in meinem Thinkpad alles andere als langsam.
Soweit ich weiß profitiert gerade VirtualBox auch überhaupt nicht von Vanderpool/Pacifica was die Geschwindigkeit angeht. Es wird eher langsamer.
Ja, wo der Kernel closed ist AFAIK.
Meine aber mal gelesen zu haben, dass die kommerzielle Xen-Version mit speziellen Treibern für die Windows-Virtualisierung daher kommt, so dass es von der Performance wesentlich flotter ist.
Richtig. Xen virtualisiert normal indem der Gast von Xen weiß. Die Gäste führen also schon brav von sich aus keine priviledged instructions aus, sondern fragen immer den Hypervisor nach wenn sie etwas tun müssen was Kernelrechte erfordert.
Microsoft hat mal intern eine Anpassung an Xen gemacht, diese aber nie veröffentlicht. Wohl aus lizenzrechtlichen Gründen.
Soweit ich weiß profitiert gerade VirtualBox auch überhaupt nicht von Vanderpool/Pacifica was die Geschwindigkeit angeht. Es wird eher langsamer.
Kann ich nicht bestätigen.
Eine VM mit VirtualBox ist auf meinem Notebook, welches kein VT unterstützt, unbenutzbar langsam.
Auf meinem Desktop-PC, welcher einen ähnlich starken Prozessor hat, der aber VT unterstützt, rennt die VM wie Sau.
(bis auf die 2D-Beschleunigung bei VirtualBox, die ist sowohl bei der CPU mit VT als auch mit der CPU ohne VT grottenschlecht - VMware läuft da wesentlich schneller wenns um Sachen 2D geht)
Die VirtualBox 2D-Beschleunigung ist sogar so lahm, das sie zwei Sekunden braucht um ein 8Bit/640x480 Framebuffer Bild aufzubauen
Hoffe das die das mal bessern
Das bezieht sich jetzt aber auf Gäste die Xen kennen, oder? Habe ja nicht behauptet, dass das langsam wäre. Ist auch produktiv so im Einsatz bei mir ;)
Soweit ich weiß profitiert gerade VirtualBox auch überhaupt nicht von Vanderpool/Pacifica was die Geschwindigkeit angeht. Es wird eher langsamer.
Richtig. Xen virtualisiert normal indem der Gast von Xen weiß. Die Gäste führen also schon brav von sich aus keine priviledged instructions aus, sondern fragen immer den Hypervisor nach wenn sie etwas tun müssen was Kernelrechte erfordert.
Microsoft hat mal intern eine Anpassung an Xen gemacht, diese aber nie veröffentlicht. Wohl aus lizenzrechtlichen Gründen.
Ich meinte eigentlich keine XEN-Basierenden Gäste, habe mit XEN aber auch nur rudimentär gespielt.
Ich kann mir nur nicht vorstellen dass es sooo grottenlangsam ist, wo sogar KVM (Kernel based virtual machine) unter Linux, auf VT-Prozessoren sauschnell rennt.
Übrigens kann Virtualbox sehr wohl Vanderpool, aber erst VirtualBox 2.0.
Ich kann nur von meinen persönlichen Erfahrungen reden. Ich habe ein 12-Zoll-Notebook (Thinkpad X60s) welches mit einem Yonah-Dualcore bestückt ist (2x 1,6GHZ) darin sind 2GB RAM und das ganze lüppt auf Debian Linux.
Egal ob mit KVM, welches sozusagen wie ein XEN-Lite ist, indem es den Linuxkernel des Hostsystems quasi als hypervisor nutzt (mit Vanderpools hilfe natürlich ;) ), und die restliche HW per QEMU simuliert (Festplattenimages und co.)
oder auch mti Virtualbox 2.0 mit aktiviertem Vanderpool...
welches von beidem ist egal, WinXP geht tadellos in sehr angenehmer Geschwindigkeit. Ich merke keinen Unterschied zum nativ installierten XP.
Bei Virtualbox hat der switch auf die 2.0 und das nutzen des simulierten-SATA-Festplattenadapters schon einiges gebracht gegenüber der Standard-plain-IDE-Fassung, merkt man aber auch nur bei Festplattenlastigen Programmen. CPU-Mäßig gibts jedenfalls keine Geschwindigkeitsprobleme.
Die 2D-Grafik könnte etwas flotter gehen, das ist richtig. Aber das wars dann auch mit der Kritik.
Vor allem KVM, also vertreter der "Faulen Virtualisierung", da es ohne VT oder Pacifica gar nicht geht, ist Geschwindigkeitstechnisch echt erstaunlich!
Wenn XEN da also langsam ist, hast du entweder ganz andere Anforderungen, oder XEN macht anderweitig irgendwas total anders als KVM auf Linux 2.6.27.
XEN ohne VT und co. kann ja nur paravirtualisierung, d.h. der kernel der Gäste muss gepatcht werden damit sie alle priviligierten Calls an die entsprechenden hypervisor-Funktionen umleiten. Das geht natürlich mit Win als Gast nicht wegen der redmonder Rechtsabteilung.
Ich für meinen Teil finde es jedenfalls sehr praktisch was mit VMs alles geht. einer meiner lieblings-Gags ist, einen USB-Wlan-Stick zu benutzen, per Virtualbox exklusiv dem Gast zuzuteilen und dann die VM als eigenes Gerät ins Wlan zu bringen. So spar ich mir irgendwelche komplizierten Netzwerkkonfigurationen und der Host kann brav sein internes Wlan behalten.
Habe schon mit dem Gedanken gespielt beim nächsten Desktop nur noch mit Virtuellen Maschinen zu arbeiten. Auch entweder mit XEN, oder einem minimal-Linux und KVM-Gästen. Ist nur fürs Zocken doof ;)
grüßle
ich
Sun VirtualBox 2.10 nun mit besserem VT-x- / AMD-V-Support und experimenteller 3D-Beschleunigung via OpenGL:
Download (http://www.virtualbox.org/wiki/Downloads)
Changelog (http://www.virtualbox.org/wiki/Changelog)
Nun müsste man nur noch win-Games finden die OpenGL benutzen ;)
Aber ist logischerweise die "einfachste" art und weise, 3D in die VM zu bringen, einfach durchreichen an den Host.
Nun brauchen sie nur noch transgaming und co. darum anhauen deren DirectX-Implementation ienbauen zu dürfen, welche AFAIK die DirectX-calls in Opengl-befehle umwandelt, welche die VM dann an den host übergeben kann...
Dann sollte _halbwegs_ Gaming in der VM möglich sein.
Nicht unbedingt die neuesten Kracher (Die laufen bei dem mieserablen Grafik-Treibersupport der meisten Hersteller unter Linux sowieso in den seltensten Fällen, zumindest nicht mit max. Qualität) aber zumindest der eien oder andere Klassiker oder auch neuere Titel mit reduzierten Einstellungen sollte dann möglich sein.
Ob Transgaming da mitspielt ist ne andere Frage, wäre je mehr oder weniger direkte Konkurrenz zu Cedega. Wenn auch mit deutlichem Overhead....
Mal schauen, jedenfalls ein schöner Schritt.
grüßchen
ich
Nasenbaer
2008-12-18, 10:08:11
Nun müsste man nur noch win-Games finden die OpenGL benutzen ;)
Aber ist logischerweise die "einfachste" art und weise, 3D in die VM zu bringen, einfach durchreichen an den Host.
Nun brauchen sie nur noch transgaming und co. darum anhauen deren DirectX-Implementation ienbauen zu dürfen, welche AFAIK die DirectX-calls in Opengl-befehle umwandelt, welche die VM dann an den host übergeben kann...
Dann sollte _halbwegs_ Gaming in der VM möglich sein.
Nicht unbedingt die neuesten Kracher (Die laufen bei dem mieserablen Grafik-Treibersupport der meisten Hersteller unter Linux sowieso in den seltensten Fällen, zumindest nicht mit max. Qualität) aber zumindest der eien oder andere Klassiker oder auch neuere Titel mit reduzierten Einstellungen sollte dann möglich sein.
Ob Transgaming da mitspielt ist ne andere Frage, wäre je mehr oder weniger direkte Konkurrenz zu Cedega. Wenn auch mit deutlichem Overhead....
Mal schauen, jedenfalls ein schöner Schritt.
grüßchen
ich
Man wäre gar nicht auf Transgaming angewiesen, Cedega läuft nach Aussagen vieler auch nicht wesentlich besser als WINE - letztere haben in den letzten Monaten auch sehr beim DirectX Support zugelegt. Aber WINE wie Cedega sind natürlich nicht nur einfache DX Wrapper, die man mal ebend ins eigenen Projekt überführen kann. Außerdem dürfte der DX support dann nicht in die ClosedSource-Edition wandern, wegen der GPL.
Ich würde ja folgende Variante bevorzugen aber leider spielt VirtualBox da noch nicht mit:
Windows als Host-System - Ideal für aktuelle Spiele und grafisch sehr anspruchsvolle Applikationen.
Linux als Gast - idealerweise mit OpenGL Support durch die VM um zumindestens "einfache" Anwendungen auch laufen lassen zu können, die auf OpenGL zurückgreifen.
Somit hätte man vollständigen Spielesupport und gleichzeitig nen ordentlichen Desktop mit gescheiten Programmen zur Verfügung (letzteres ist natürlich Ansichtssache).
Das Problem ist nur, das meines Wissens keine Virtualisierungslösung 3D-Beschleunigung für Linux-Gäste bei einem Windows-Host bietet. :(
puntarenas
2008-12-18, 11:33:41
Sun VirtualBox 2.10 nun mit besserem VT-x- / AMD-V-Support und experimenteller 3D-Beschleunigung via OpenGL:
Da konnte ich nicht widerstehen und habe gestern noch kurz VirtualboxBox 2.10 in Ubuntu 8.10 installiert. Auf die schnelle habe ich nur Cinebench R10 gefunden, SpecPerfView und andere schnell angetestete GL-Benchmarks liefen nicht durch. Gast war WinXP Pro auf einem E6600 und einer 8800GT:
Cinebench R10, Ubuntu 8.10, Windows XP Guest
VB mit 3D-Beschleunigung:
2756 CB-GFX
VB ohne 3d-Beschleunigung:
408 CB-GFX
Vergleichswerte
Wine:
5614 CB-GFX
Windows nativ:
5431 CB-GFX
Die Richtung stimmt und ein erster Schritt ist getan. Ich war schon ein wenig geschockt, als die Übernahme von Tungsten durch VMWare bekannt wurde. Dem Gast ausgerechnet die mittlerweile brachiale Rechenleistung einer GPU nicht zugänglich zu machen, lässt eine Virtualisierungslösung alt aussehen, ganz abgesehen davon, dass selbst "Desktopmalen" mittlerweile beschleunigt in 3D mit Klick, Bunt, Bling und Splash Gang und gäbe ist. Ich hatte befürchtet, VMWare kauft sich Know-How und Sun hat das verbummelt.
Hat wer Vorschläge für alte (-> hoffentlich geringes Featureset) Games oder Benchmarks mit OpenGL-Support und idealerweise verfügbarer Demo?
The Cell
2008-12-18, 12:10:36
Vorschlag zum Benchen: Serious Sam!
SAM I AM! ;)
Gruß,
TC
Nasenbaer
2008-12-18, 12:36:28
Quake3-Engine basierende Games: CoD1, Quake3Arena, HeavyMetalFAKK2
Wenn die nicht laufen, denn mal die Quake2 Engine testen. :)
thacrazze
2008-12-18, 14:38:57
Warcraft III, World of Warcraft
Ja, Quake3 in ner VM im Gast-windows ist ne wahnsinns Idee, wos Quake3 doch "nativ" für Linux gibt! ;)
Das dürfte die größte Hürde einer solchen lösung sein... Spiele die OpenGL schon beherrschen gibts entweder für linux oder sie laufen mit Wine recht ordentlich, Games die kein OGL unterstützen, nutzen auch in der VM nix.
übrigens lustig dass cinebench unter wine mehr Punkte bringt als unter Win nativ ;)
Übrigens kann Virtualbox sehr wohl Vanderpool, aber erst VirtualBox 2.0.
Ich habe nicht behauptet, dass es es nicht kann. Ich sagte, dass es dadurch eher langsamer wird. Lies die Dokumentation!
In fact, depending on the workload, VirtualBox’s software virtualization may even
be faster than hardware virtualization. Other virtualization products that require
hardware virtualization are usually much less sophisticated and tuned compared to
VirtualBox. With VT-x and AMD-V, a special CPU environment has to be entered in
order to execute guest code and whenever activity of the VMM is required, this environment
has to be left and then entered again. This can be an expensive operation
and in many circumstances, the benefits of hardware virtualization may not outweigh
the performance penalty.
Ich kann mir nur nicht vorstellen dass es sooo grottenlangsam ist, wo sogar KVM (Kernel based virtual machine) unter Linux, auf VT-Prozessoren sauschnell rennt.
Es ist mit Sicherheit langsamer als VMWare und VirtualBox, die entsprechend den Code patchen.
=Floi=
2008-12-18, 18:14:18
ohne AA und AF ist das ganze aber leider total sinnlos. Das ist ja der witz an der sache. Selbst professionelle programme profitieren von AA und speziellen treibern (Quadro)
AA dürfte man wohl über den Host-Treiber erzwingen können.
Ahoi,
IBM Systeme (die Servermodelle) können Hardwaretechnisch die Systeme Virtualisieren. Damit ist es möglich auf einer CPU 10 getrennte Systeme laufen zu lassen die sich die komplette Hardware im System teilen. Je mehr CPUs in einem System laufen, desto mehr getrennte Systeme kann man laufen lassen. Wie gut die Systeme dabei skalieren weiss ich leider nicht, aber somit wäre es möglich wenn diese ganzen neuen Hybriden aus Rasterizer und Raytracingtechniken an den Start gehen eventuell doch eine mehr als ordentliche Performance zu gewährleisten.
Wenn ich mich recht entsinne hat es sich hierbei um die P-Serie gehandelt.
thacrazze
2008-12-18, 23:12:55
Schade das sich PPC nicht durchgesetzt hat :/ Danke Apple
Ich habe nicht behauptet, dass es es nicht kann. Ich sagte, dass es dadurch eher langsamer wird. Lies die Dokumentation!
Der Ausgangspunkt war:
Wenn ich das richtig verstanden habe (siehe z.B. ArsTechnica-Artikel), ist das mal wieder die "tolle" und "moderne" x86-ISA, die so etwas überhaupt braucht um auf aktuelle Anforderungen fit gemacht zu werden.
Und scheint zu stimmen. Entweder braucht es "Hardware-Virtualisierung" (= VT-x bzw AMD-V) oder "Software-Virtualisierung" im Sinne, wie du beschrieben hast, dass VMware sich selber darum kümmert.
Unter non-x86 Architekturen hat man offenbar von Haus aus performante "Hardware-Virtualisierung", ohne dass erst nachträglich etwas zurecht gefrickelt werden muss.
Ahoi,
IBM Systeme (die Servermodelle) können
Soweit ich weiss können die auch den x86-Befehlssatz ausführen, ähnlich das Apple umgekehrt mit Rosetta gemacht hat.
Der Ausgangspunkt war:
Und scheint zu stimmen. Entweder braucht es "Hardware-Virtualisierung" (= VT-x bzw AMD-V) oder "Software-Virtualisierung" im Sinne, wie du beschrieben hast, dass VMware sich selber darum kümmert.
Unter non-x86 Architekturen hat man offenbar von Haus aus performante "Hardware-Virtualisierung", ohne dass erst nachträglich etwas zurecht gefrickelt werden muss.
VT-x und AMD-V bieten aber viel gezieltere Möglichkeiten als eine Architektur die alle Kernel-Mode-Opcodes trappt, weil man es für jeden Befehl einzeln einstellen kann was geschieht.
Im Endeffekt wird man wohl auch bei anderen Architekturen ähnliche Dinge entweder schon eingeführt haben oder noch einführen.
Schade das sich PPC nicht durchgesetzt hat :/ Danke Apple
Genau welchen Nachteil hast du nun deswegen?
Beispielsweise den, dass PPC von vorne herein virtualisierungsfähig ist ;)
Ohne "Kunstgriffe" wie VT oder AMD-V.
X86 war eben nur architektonisch in den 80ern nicht darauf ausgelegt. Damals war ja mausschubsen schon eine (teure) Neuheit.
Eigentlich ist der X86-Grundbefehlssatz, bzw. die Grundarchitektur nicht virtualisierbar nach Popek und Goldberg.
http://en.wikipedia.org/wiki/Popek_and_Goldberg_virtualization_requirements
Genau deswegen waren ja solche Code-Scannen und -umschreiben - Kniffe für virtualisierer nötig um das zu ermöglichen bevor es VT und co. gab.
Dadurch ist nun quasi die Funktionalität "nachgerüstet" worden die nötig ist.
Aber andere Architekturen (die allerdings auch deutlich jünger sind) erfüllten o.g. Kriterien schon von Hause aus bzw. wesentlich länger als X86 das kann.
(PowerPC zum Beispiel)
das ist wohl das was "thacrazze" damit andeuten wollte.
thacrazze
2008-12-19, 14:01:46
@ Gast: genau
Beispielsweise den, dass PPC von vorne herein virtualisierungsfähig ist ;)
Ja, langsam, ohne Code-Patching. Bringt euch genau was?
Du brauchst mir die Theorie nicht zeigen, sie ist mir wohlbekannt.
Aber andere Architekturen (die allerdings auch deutlich jünger sind) erfüllten o.g. Kriterien schon von Hause aus bzw. wesentlich länger als X86 das kann.
(PowerPC zum Beispiel)
Die Sache ist nur, dass Desktop-Virtualisierung trotzdem auf x86 seinen Anfang hatte.
@Coda ich habe nicht an deiner Kompetenz gezweifelt, dennoch gibt es bestimmt Leute, denen die Theorie nicht bekannt ist.
Dass die Desktop-Virtualisierung auf X86 ihren Anfang nahm ist auch kein Wunder angesichts der Masse an X86-Desktops.
Und da PPc z.B. eigentlich nur entweder für Server oder auf Apple eingesetzt wurde... naja...
Was hätten die Macesen denn auch virtualisieren sollen!? Windoof lüppt ja nicht auf PPC....
Ist aber eigentlich auch egal. Das soll ja keine Flamewar gegen die Architekturen werden... Aber dass X86 teilweise noch mit seinen eigenen Wurzeln zu kämpfen hat ist ja wohl unbestreitbar.
Ein moderner Core2Duo oder Athlon/Phenom hat zwar mit dem 8086 wohl nicht sehr viel mehr gemeinsam wie ein heutiger Formel 1 Bolide mit dem Patent Motorwagen von Karl Benz aber die eigenen Wurzeln lassen sich eben nicht wegwischen.
Oder will hier jemand bestreiten dass einen X86er zu virtualisieren keine ganz leichte Aufgabe ist!? wenn man alleine an so Geschichten wie den SMM denkt, der einem ganz böse dazwischenfunken kann...
Fakt ist, wenn heute jemand den X86er neu erfinden würde, würde er unter Garantie einiges anders machen. Andere Architekturen machen es vor, konnten schon lange vor dem NX-Bit den Speicher auf ähnliche art und Weise Markieren, Haben keine uneingeschränkt priviligierten (untrappable) Befehle usw.
Dennoch ist der X86er halt wie er ist... und hat maßgeblich dazu begetragen dass wir heute solche Kisten zu hause rumstehen haben und darauf daddeln können.
Code-Patching, code-Morphing oder wie auch immer, ist eine interessante Technik und hat sicher Ihre Vorteile, dennoch ist auch dort ein gewisser Overhead inklusive. Und im Falle von Virtualbox funktioniert das z.b. nicht mit OS/2 als Gast, weil dort einige "exotische" Befehlsfolgen vorkommen, für die der Code-Scanner nicht vorbereitet ist. (Ich weiß dass OS/2 soweiso keiner braucht, es geht mir mit dem Beispiel eher ums Prinzip bzw. darum klarzustellen dass auch Software-Virtualisierung ihre tücken hat)
Der Punkt ist wohl einfach, dass sauber umgesetzte und auf Virtualisierung ausgelegte Hardware, derartige Kunstgriffe nicht nötig hätte!
Wären also die Maschinen und Befehlssätze designt nach Popek und Goldbergs Vorgaben, wäre Code-Patching unnötig.
Und das ist auch das Ziel auf das Vanderpool und Pacifica zusteuern sollten...
grüßle
ich
Wären also die Maschinen und Befehlssätze designt nach Popek und Goldbergs Vorgaben, wäre Code-Patching unnötig.
Nein, eben nicht. Das wäre viel zu langsam und das ist genau mein Punkt.
Wie gesagt, es gibt einen Grund warum VT-x und AMD-V sowohl von VMWare als auch VirtualBox wenn dann nur eingeschränkt eingesetzt werden um die Kompatibilität zu erhöhen. Patchen tun sie trotzdem.
Nein, eben nicht. Das wäre viel zu langsam und das ist genau mein Punkt.
Du gehst immer von x86-"Krücke" aus. Woher weisst du, wie performant es auf einem PowerPC aussieht?
Weil ich weiß, dass es sich dort Exception-Handling auch nicht billiger ist.
Das was dort verwendet ist, ist auch nicht der "Krückenteil" von x86 sondern erst seit dem Protected Mode definiert, und der ist bis heute nicht veraltet.
Sun VirtualBox 2.10 nun mit besserem VT-x- / AMD-V-Support und experimenteller 3D-Beschleunigung via OpenGL:
mal ein kurzer test mit Doom3:
Hostsystem: 107fps
VBox-Guest: 12fps
performancemäßig also noch kaum brauchbar, aber positiv zumindest dass es keine grafikfehler gibt, auch FSAA und AF funktionieren im guestsystem einwandfrei
mofa84
2009-02-03, 21:43:52
Die einzigen vorteile momentan sind das du unter einem 32Bit-OS ein 64Bit-OS in einer VM laufen lassen kannst.hierzu noch ne Frage: ich habe einen E2140, also ohne Vanderpool - ich kann jetzt trotz XP64 keine 64-Bit-Betriebssystem unter VirtualBox laufen lassen. Liegt das daran?
[QUOTE=mofa84;7082844 Liegt das daran?[/QUOTE]
ja, alle mir bekannten VM-lösungen können nur mit aktiver virtualisierung 64bit virtualisieren.
mofa84
2009-02-03, 22:15:11
Dann frage ich mich wie T4ch0n4d3l zu dieser Behauptung kommt - aber ein ein 64-Bit-OS auf einem 32-Bit-OS kann ja schon mal gar nicht gehen...
Zitat:Die einzigen vorteile momentan sind das du unter einem 32Bit-OS ein 64Bit-OS in einer VM laufen lassen kannst.
Dazu braucht man aber kein Vanderpool oder Pacifica.Dazu braucht man aber kein Vanderpool oder Pacifica.
Eigentlich braucht man kein Vanderpool dafür, sondern nur Segmentierung. Das hatte AMD bei AMD64 am Anfang entfernt, später aber wieder eingebaut aus genau dem Grund.
mofa84
2009-02-03, 23:19:55
Und wie bekomme ich jetzt die 64-Bit-OS mit Virtualbox zum Laufen?
Gar nicht, weil deine CPU die Vorraussetzungen nicht erfüllt für VirtualBox um 64-Bit-Gäste zu ermöglichen.
Ob VirtualBox da jetzt ausschließlich Vanderpool einsetzt anstatt den Weg über Segmentierung zu gehen oder ob deine CPU beides nicht kann weiß ich nicht.
mofa84
2009-02-03, 23:41:49
Aber ich brauche doch gar keine Segmentierung?!
Die hat doch nur was mit dem Speicher zu tun - zu mir sagen aber Windows 7 64, Linux 64 und FreeBSD 64 dass meine CPU nicht 64-Bit-tauglich wäre.
Aber ich brauche doch gar keine Segmentierung?!
Doch brauchst du, weil sonst der Hypervisor-Code nicht abgeschottet werden kann.
mofa84
2009-02-04, 00:15:28
Hat PAE/NX damit was zu tun? (Physical Address Extension)
Nö. Das hat was mit Paging zu tun...
Und wie bekomme ich jetzt die 64-Bit-OS mit Virtualbox zum Laufen?
virtual-box-manual seite 16:
Starting with Version 2.0, VirtualBox also supports 64-bit guest operating systems.
Starting with Version 2.1, you can even run 64-bit guests on a 32-bit host operating
system, so long as you have sufficient hardware.
In detail, 64-bit guests are supported under the following conditions:
1. You need a 64-bit processor with hardware virtualization support (see chapter
1.2, Software vs. hardware virtualization (VT-x and AMD-V), page 10).
2. You must enable hardware virtualization for the particular VM for which you
want 64-bit support; software virtualization is not supported for 64-bit VMs.
Note: On most systems, the hardware virtualization features first need to be
enabled in the BIOS before VirtualBox can use them.
also garnicht mit deiner cpu.
mofa84
2009-02-04, 13:19:50
und noch was:
lässt in einer virtuellen Maschine eine weitere virtuelle betreiben? Nur so interessehalber.
ja, das kannst du beliebig fortsetzen.
mofa84
2009-02-04, 13:50:38
würde gern versuchen in einem virtuellen Linux ein MacOS zum laufen zu bekommen - da MacOS jedoch teilweise 64-Bit ist, könnte die CPU ein Problem werden.
wie es mit macos aussieht kann ich dir nicht sagen, offiziell wird es von keiner virtualisierungslösung unterstützt.
MacOS in einer virtualisierten umgebung ist schon deshalb schwer, da ja bis auf den prozessor nichts in hardware virtualisiert. deshalb hast du in der virtuellen umgebung auch größtenteils keine echte hardware sondern nur irgendwelche virtuellen geräte, für die es natürlich nur treiber vom hersteller der virtualierungssoftware, und nachdem diese kein MacOS unterstützen gibt es logischerweise auch keine entsprechenden treiber.
VirtualBox unterstützt neben OpenGL jetzt auch Direct3D (auf Basis von Wine):
http://www.phoronix.com/scan.php?page=news_item&px=NzAyNA
Nasenbaer
2009-02-04, 21:53:58
VirtualBox unterstützt neben OpenGL jetzt auch Direct3D (auf Basis von Wine):
http://www.phoronix.com/scan.php?page=news_item&px=NzAyNA
Jo musst dir aber die SVN sources ziehen. Das aktuell offizielle release hats noch nicht mit drin.
Jo musst dir aber die SVN sources ziehen. Das aktuell offizielle release hats noch nicht mit drin.
Wird dann wahrscheinlich mit VirtualBox 2.2 kommen, denke ich mal.
VirtualBox unterstützt neben OpenGL jetzt auch Direct3D (auf Basis von Wine):
http://www.phoronix.com/scan.php?page=news_item&px=NzAyNA
wenn OGL schon gerade mal 10% an speed erreicht will ich garnicht erst wissen wie lahm das ist ;)
interessant wäre auch zu wissen, ob damit aero möglich ist, bei der momentanen ausführungsgeschwindigkeit die einzig sinnvolle anwendung von 3d-beschleunigung in der vm.
vBulletin®, Copyright ©2000-2024, Jelsoft Enterprises Ltd.