Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , 34 reacties
Bron: Vmware

De prestaties van hardwarematige virtualisatie zijn vooralsnog ondermaats, zo blijkt uit een rapport van Vmware. Deze fabrikant van virtualisatiesoftware heeft onderzocht hoe snel systemen met Intels Virtualization Technology zijn in vergelijking met volledig softwarematige oplossingen, en de resultaten zijn voor Intel niet erg rooskleurig. Virtualisatie, waarmee het mogelijk is om verschillende besturingssystemen naast elkaar op een machine te draaien, is over het algemeen een stuk langzamer omdat de virtualisatiesoftware niet alleen een computer moet emuleren, maar ook moet zorgen dat de verschillende besturingssystemen niet in elkaars vaarwater terecht komen. Zowel Intel als AMD kwamen daarop met hardwarematige virtualisatiesystemen die respectievelijk VT en Pacifica genoemd worden. Vmware, wiens software van dergelijke hardwareoplossingen gebruik kan maken, betwijfelt echter of Intel zijn huiswerk wel goed gedaan heeft.

Intel-logo nieuwe stijl Het compileren van een Linux-kernel op een virtueel systeem vergt bijna een kwart meer tijd wanneer Intels VT wordt gebruikt, waardoor het totale tijdsverlies door virtualisatie op ruim tachtig procent uitkomt. De vraag is dan ook gerechtvaardigd welk nut de Intel-technologie eigenlijk heeft. De processorbouwer heeft zich naar eigen zeggen geconcentreerd op het bouwen van een 'correct' systeem, waarbij nog geen aandacht aan optimalisatie van de prestaties is gegeven. Hoewel het een nobel streven is om een zo goed mogelijk product af te leveren, haalt dat het commerciële nut van VT uiteraard totaal onderuit; Intel zal flink aan de bak moeten om de virtualisatietechniek als verkoopargument te kunnen gaan gebruiken. Naar verluidt heeft AMD de zaken met Pacifica beter voor elkaar, maar objectieve benchmarks die die stelling staven zijn nog niet te vinden.

Lees meer over

Gerelateerde content

Alle gerelateerde content (23)
Moderatie-faq Wijzig weergave

Reacties (34)

Ze zeggen dus eigenlijk:

"wat de concurentie maakt suckt, koop software van ons"

:+
Nee, VMWare zegt hier alleen maar:
Onze software draait sneller ZONDER de hardwarematige virtualisatietechniek van Intel dan MET.
En hoe heeft dit met concurrentie te maken? Vmware, maker van een SOFTWARE-pakket, geeft een objectieve menig over 2 HARDWARE-producten die te maken hebben met hetzelfde concept, namelijk virtualisatie.
Beter lezen, VMWare heeft alleen de Intel-technologie getest, niet die van AMD. Dus is het wel zoals de poster waarop je reageert stelt: softwaremaker VMWare zegt dat de concurrentie (van henzelf) suckt. Beetje doorzichtig.

Sterker nog, als je de paper leest dan merk je dat overal waar AMD wordt genoemd het voornamelijk is om aan te geven dat de architectuur van AMD's Pacifica zeer veel lijkt op die van Intel.
Volgens mij moeten hardwarematige virtualisatietechnieken een hulpmiddel zijn voor softwareproducenten van virtualisatiesoftware (o.a. Xen, VMWare en Virtual Server). De één kan niet zonder de ander, je kan niet native op die hardware meerdere OS'en virtualiseren. VMWare heeft het dus volgens mij niet over een concurrent, maar over de hardwareleverancier die een toegevoegde waarde zou moeten zijn voor de toekomstige generatie virtualisatiepakketten.

Nu blijkt dus dat vooralsnog die hardware totaal geen voordeel heeft voor de software fabrikanten en dus moet er nog flink wat werk verzet worden eer men serieus naar dat soort technieken gaat kijken.

imo is het dus geen snauw naar de concurrentie, omdat VMWare en Intel dat simpelweg niet zijn van elkaar.
Vmware, wiens software van dergelijke hardwareoplossingen gebruik kan maken, betwijfelt echter of Intel zijn huiswerk wel goed gedaan heeft.
VMWare maakt toch software die gebruik maakt van deze hardware mogelijkheden?
Gezien de ervaringen die diverse mensen hebben met het pakket van Parallels (die dus ook gebruik maakt van die VT in de Core Duo proc) op de Intel macs staat de conclusie van VMware hier haaks op. De Intel mac mensen ervaren namelijk dat de snelheid van Windows middels Parallels nagenoeg hetzelfde is als wanneer die met bootcamp native wordt geinstalleerd. Een compleet tegenovergestelde conclusie dan die van VMware. Dat zou dus betekenen dat VMware aardig wat werk heeft om het fatsoenlijk werkend te krijgen zodat ze dezelfde performance weten te halen als die mac mensen ervaren met Parallels. Het gaat dus wel degelijk om de concurrentie want die liggen kennelijk voor op dit gebied.
Niets ten nadele van VMWare, maar het lijkt me belangrijker om een goed product te leveren in plaats van een snel product.

Snelheid is van secundair belang (wat niet wil zeggen dat het niet belangrijk is)

Snelheid ten koste van (mogelijke on-)betrouwbaarheid is nooit te prefereren.

Edit : Ik snap wel dat hardware virtualisatie gebeurd omdat dat (in theorie) sneller zou moeten zijn dan software. En VMWare heeft zeker geen slecht produkt, maar ik vind dat eerst moet zorgen dat het ontwerp goed is want snelheid is later altijd nog te verbeteren maar een fout ontwerp kan niet aangepast worden.
VMware heeft met ESX server een goed EN snel product in de markt staan. Wij draaien sinds iets meer dan een jaar een hele reut servers virtueel, en nog nooit problemen gehad omdat iets gevirtualiseerd was.

En "een stuk langzamer" uit het artikel klopt ook niet, ESX performt gemiddeld op meer dan 90% van de originele (fysieke) machine, en dat terwijl wij op elke ESX server minstens 15 virtuele servers hebben draaien. Enige waar je op moet letten is de virtuele disk belasting, het is niet slim op b.v. een Exchange server te virtualiseren. Maar standaard web/applicatieservertjes willen prima; sterker nog, dze leveren we niet eens meer fysiek, zonde van de processorkracht.
Dat het een jaar probleemloos werkt betekent nog niet dat het ook probleemloos is. Om het in EW Dijkstra's woorden te zeggen:
Program testing can be used to show the presence of bugs, but never to show their absence!
Exchange servers kunnen prima gevirtualiseerd worden. Als je de data op een lun op een SAN zet, is er echt geen vertraging.
Exchange(2003) kan je prima virtualiseren. Wij hebben onze Exchange server met 400+ mailboxen virtueel met nog geen 10-15% CPU belastig tijdens kantooruren(toch wel een man of 200 concurrent actief, soms meer).
Disk I/O is ook totaal geen probleem.

Wij hadden ook onze twijfels in den benginne, maar het draait echt als een trein. Beter als fysiek zelfs(oude server was een HP Proliant DL380 G3 met 2 processors op iets van 2.8 of 3Ghz). Nu is het een singleprocessor VM op een 3.4GHz Xeon(ESX), met daaraan wel een snelle SAN.
De hele reden van virtualisatie in hardware (ipv de vmware software Op P4) was dat het mogelijk sneller was dan software. Nu blijkt dus dat niet alle hardware calls versneld worden.

In de benchmarks zie je ook een aantal becnhmarks die WEL sneller sneller worden door hardware VM.

Zonder alle details te snappen zou ik zeggen dat vmware dus een hybriede model gaat toepassen: Hardware versnelling voor de delen waar hardware sneller of nodig is en software waar software aanzienlijk minder overhead opleverd.
Ze hebben ook nog wel een goede verklaring, hardware calls zijn duur, er zijn effectieve interrupts die afgehandeld moeten worden bij system calls. Bij software virtualisatie zoals die van vmware word die cheap afgevangen in software, er zijn geen echte interrupts, die er zijn worden in software "geemuleerd" zonder dat er echte interrupt requests zijn.

Jammer genoeg heb ik geen cpu met deze mogelijkheden zou er wel graag eens mee experimenteren, ik had gedacht dat het grote voordeel van software tov hw virtualization zou zijn dat in hw alle native hardware blijft, alle os'n een 3D kaart kunnen delen etc, dit blijkt nog steeds niet het geval te zijn.
Toch zijn dit goede ontwikkelingen.
Intel presteerd weliswaar ondermaats, maar ik heb er het volste vertrouwen is dat dit goed gaat komen.

Virtualisatie is enorm populiar op het moment.
Vaak als bedrijven worden "ge-insourced" stikt het van de oude "NT" bakkies die nagenoeg niks verbruiken aan performance, of oude UNIX machines die nagenoeg niets staan te doen, maar wel "nodig" zijn. (oh nee! ze kunnen echt niet weg! zegt de klant dan...)
Vaak zijn dat van die oude vergeelde machines, lomp en groot, en die passen helemaal niet in het moderne data-centre met alle rack-servers van het IT bedrijf waar de boel ge-insourced zal worden. (zo'n rukterm he... insourcen enzo..maarja weet ff niks anders te bedenken)

Dat zijn prima kandidaten om op een VMware platform te kwakken.

Maar terug "ontopic"
De theorie van Apache_ m.b.t. system calls die bij hardware VM vaker resulteren in interrupts lijkt mij een logische theorie.
die theorie klopt inderdaad. VMware vangt alle interrupts af. Tenminste, als we over VMware ESX server praten.

En dit is ook geen knauw naar een concurent. VMware zou juist de hardware van Intel goed kunnen gebruiken om hun software te offloaden. MAar als het met alleen software snelle werkt dan met hardware ondersteuning waarom zou je dan uberhaubt die hardware ondersteunen?

Het is misschien wel een indirecte knauw naar Xen. Dit opensource product kan vanaf versie 3 ook alle soorten x86 Osen virtueel laten draaien zonder dat het os aangepast hoeft te worden. Op dat moment zouden ze al een stap dichter bij echte concurrentie met VMware komen. Ware het niet dat Xen 3 dus volledig gebruik maakt van VT en dus bagge rtraag wordt :)
"Het compileren van een Linux-kernel op een virtueel systeem vergt bijna een kwart meer tijd wanneer Intels VT wordt gebruikt, waardoor het totale tijdsverlies door virtualisatie op ruim tachtig procent uitkomt."

En als ik dan de PDF lees, dan staat daar:

"In the Linux compile job, the host took 265 seconds, the software VMM took 393 seconds (67.4% of native performance), and the hardware VMM took 484 seconds (54.8% of native). Put differently, the software VMM’s overhead is 128 seconds whereas the hardware VMM’s overhead is almost twice as large at 219 seconds."

Die 'kwart meer tijd' is daar in terug te vinden... maar het tijdsverlies door virtualisatie is lang geen 80% in dat geval. Alleen in de compileWin en LargeRAM tests zie je een tijdsverlies van rond de 80%.
Het klopt wel hoor.

Er staat dat die host er 265 sec over doet, dat is zeg maar 100 % dan.
Daarna staat er dat het er met hardware VMM 484 sec over doet.
484/265 = 1,83 dus 183%

De tijd dat hij er langer over doet is dus zelfs iets meer dan 80 %
Ik heb toevallig dit stuk gelezen, paar punten eruit gelicht:

In this section, we discuss recent architectural changes that permit classical virtualization of the x86. The discussion applies to both AMD’s SVM and Intel’s VT

The resulting performance depends primarily on the
frequency of exits. A guest that never exits runs at native speed, incurring near zero overhead. However, this guest would not be very useful since it can perform no I/O. If, on the other hand, every instruction in the guest triggers an exit, execution time will be dominated by hardware transitions between guest and host modes.


Nou heb ik het gelezen maar het meeste gaat me boven de pet, vooral die 'exits' waar ze het over hebben. Iemand die de exits even in lekentaal uit kan leggen? :)

@Abom
Thanks! Dus als ik het goed begrijp is een exit het verplaatsen van een guest naar een andere ring om een actie uit te voeren. Dit verplaatsen zorgt nu voor een nieuwe overhead die zorgt dat hw virtualisatie langzamer is...
Ik ben ook geen guru op CPU architectuur, maar hoe ik het begrepen heb, heb je verschillende execution levels (ringen) in CPU's. Normaal draait een kernel in ring 0 en heeft de volledige beschikking over het systeem.

Bij software virtualisatie, draait de hypervisor in ring 0 en de guests in ring 3 volgens mij. Normaal wordt ring 3 niet gebruikt, alleen 0 en 5 volgens mij (0 kernel, 5 voor apps oid).

Met hardware virtualisatie, is ring 0 vrij en draait de hypervisor in ring -1 (die er oorspronkelijk niet was). Guests draaien nog altijd in ring 3 tenzij ze bepaalde acties uit moeten voeren. Deze acties worden bij software virtualisatie door de software geemuleerd, waardoor de guest niet verplaatst hoeft te worden. Nu kunnen de guests deze acties wel uitvoeren, maar moeten ze eerst verplaatst worden naar ring 0 en daarna weer terug naar ring 3 en dat kost veel tijd...hierdoor is hardware virtualisatie af en toe sneller maar meestal trager.
Bij VT en Pacifica is dat juist niet nodig. Dat is alleen nodig bij paravirtualisatie zonder VT of Pacifica, bijvoorbeeld met Xen.
Nou, niet altijd, maar .... dit is toch niets nieuw? :-|

edit: oh te laat zie ik
Dus als ik het goed begrijp kan ik straks de features op mijn laptop eigenlijk niet gebruiken om meerdere OS'en te draaien, maar wel om geinfecteerd te raken door iets als Blue Pill? Goedzo Intel :)
Het is dat ik deze laptop van de universiteit 'krijg', maar ik hoop dat AMD met iets beters komt voor in mijn volgende desktop/workstation :)
Je kunt het in de BIOS uitzetten als je er bang voor bent dat het misbruikt wordt...
Ah, ok, dat wist ik niet :) Wel slim ja, anders is de ramp niet te overzien bij een snelle wormuitbraak
Je kunt het in de BIOS uitzetten als je er bang voor bent dat het misbruikt wordt...
Of 't "totaal onderuit" gehaald wordt is maar net een vraag.

Een win2003 print server kan daarnaast best netjes een linux ftp server draaien. We hoeven echt niet de volgende pixar film ermee te renderen.

@ klakkie:

Begrijpelijk, zeker als zware productie servers gevirtualiseerd zijn. Mijn opmerking zit meer in de redenering dat er ook servers zijn die bijna niets doen 99% van de tijd en dus makkelijk nog wel een taak ernaast kunnen doen. Daar hoef je niet perse gelijk een ESX licentie met support tegenaan te smijten.
Als je al een keertje VMWare hebt gebruikt dan weet je dat CPU cycles belangrijk zijn.
Het gaat hier echt niet om huis tuin en keuken pc'tjes. Waar we over praten zijn 4 of 8 way machines die bv 32 virtuele machines te gelijk draaien.
Als het gebruik van Intel technologie dan wil zeggen dat je 40 % verlies hebt (maw 3 hele cpu's) kan je gerust stellen dat dit onaanvaardbaar is. Terecht dus dat VMWare dit nu aankaart want iedereen dacht dat virtualisering nu nog beter (lees sneller) zou gaan met de nieuwe technieken van Intel en AMD.
Dat de hardwarematige oplossing langzamer is: prima. Maar om het dan meteen als inferieur te bestempelen gaat me toch iets te ver.

Ten eerste bied Intels hardwarevirtualisatie de mogelijkheid aan softwareontwikkelaars om relatief eenvoudig een vorm van virtualisatie toe te voegen aan hun applicatie(s).
Daarnaast is op het gebied van veiligheid de hardwarematige oplossing potentieel beter dan een softwaremarige.

En heeft er al eens iemand aan gedacht dat virtualisatie naast OS-niveau ook op applicatieniveau mogelijk is. VMWare doet dit niet, maar misschien biedt Intel daar wel mogelijkheden voor...

Ook heeft VMWare natuurlijk al jaren ervaring met hun software, maar kan ik mij niet voorstellen dat hun hardwarematige implementatie al geoptimaliseerd genoeg is om eerlijk te vergelijken.
Ten eerste bied Intels hardwarevirtualisatie de mogelijkheid aan softwareontwikkelaars om relatief eenvoudig een vorm van virtualisatie toe te voegen aan hun applicatie(s).
Daarnaast is op het gebied van veiligheid de hardwarematige oplossing potentieel beter dan een softwaremarige.
Dit geheel klopt niet helemaal. Ja, het is eenvoudiger om virtualisatie software te maken. Het probleem is, daardoor is hardware virtualisatie onveiliger. Mede dankzij VT en Pacifica kunnen makkelijker virussen/rootkits ontwikkeld worden die gebruik maken van deze technieken, simpel weg omdat niet alle intelligentie in de software hoeft te zitten.
Ook heeft VMWare natuurlijk al jaren ervaring met hun software, maar kan ik mij niet voorstellen dat hun hardwarematige implementatie al geoptimaliseerd genoeg is om eerlijk te vergelijken.
VMware geeft in hun onderzoek ook aan dat ze denken dat dit gewoon een probleem is van de eerste generatie virtualisatie hardware.
Dus als ik het goed begrijp en als het inderdaad zo is (speculatie?) dat AMD zijn werk wel goed gedaan heeft en minimaal de software performance haalt, dan:
1. Is de Conroe in die situaties nauwelijks sneller dan die super-trage A64
2. Net aan de serverkant waar Intel al zo'n moeite had met AMD men naast de FSB/HT bus verschillen nu ook nog eens tegen de virtualisatie aanloopt, dus dubbel pech heeft...

De tijd zal het leren ;)
Ik vraag me af waar de schrijver van dit artikel vandaan haalt dat dit een probleem is wat alleen Intel heeft.

In het artikel op de website van VMware gaat het over hardware virtualisatie op in het x86 architectuur in het algemeen, er wordt niet specifiek naar VT of Paficia gewezen. Ook zie ik nergens de claim dat ze bij AMD de zaakjes beter voor mekaar hebben.

Journalistiek van likmevessie.

Het probleem ontstaat volgens mij (ik weet er ook niet het fijne van) doordat de hardware verschillende VM's van ring 3 naar ring 0 moet plaatsen om bepaalde acties uit te kunnen voeren en er weer uit halen (exits) om plaats te maken voor een andere guest. Dit lost zowel VT als SVM op deze manier op. Hierdoor is het multi-tasken tussen verschillende VM's veel minder efficient dan hoe VMware het met hun software oplost.

Waarschijnlijk is het dus, hoe meer guests, hoe minder efficient de virtualisatie hardware is.

Op dit item kan niet meer gereageerd worden.



Apple iOS 10 Google Pixel Apple iPhone 7 Sony PlayStation VR AMD Radeon RX 480 4GB Battlefield 1 Google Android Nougat Watch Dogs 2

© 1998 - 2016 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Carsom.nl de Persgroep Online Services B.V. Hosting door True