Posts by HTPC-Schrauber

    Hallo,


    vor einiger Zeit hatte ich im XenServer-Thread bereits einmal das Thema Performance der Virtualisierungslösungen angeschnitten. Nach einigen Versuchen wollte ich es genauer wissen und einmal einen Benchmark machen. Leider führten synthetische Benchmarks nicht unbedingt zu plausiblen Ergebnissen. Also suchte ich nach einer Möglichkeit möglichst unter Anwendungsbedingungen zu testen. Ich kam dabei auf die Phoronix Test Suite. Das ist eine Zusammenstellung von verschiedenen Benchmarks aus verschiedenen Bereichen. Teilweise synthetisch, größtenteils aber Anwendungsbenchmarks. Das erschien mir am sinnvollsten.
    Phoronix fasst mehrere Tests zu Suiten zusammen. Ich habe also die Testsuiten Server, Encoding, Compilation, Network, Disk, Memory und Database laufen lassen. Dieser erschienen mir am zutreffendsten für einen VM-Host. Ich habe bewußt sämtliche Tests weggelassen, die sich auf die grafische Ausgabe beziehen. Dies ist in meinen Augen kein Szenario für eine Virtualisierungsplattform.


    Zum Testablauf:


    Alle Tests erfolgten auf demselben System.
    Die Hardware sieht wie folgt aus:
    - Core i5 4570
    - Board Asrock H87 Pro4
    - 8 GB RAM (2 x 4 GB Riegel)
    - 320 GB Notebook-Platte für das System, von dieser bootet aber nur der Hypervisor
    - 500 GB Western Digital Black für die VM


    Als Betriebssystem für die VM wurde ein Ubuntu Server 13.10 installiert und auf diesem die Phoronix Test Suite. Es wurde jeder Testlauf mit derselben Installation durchgeführt und nicht jedes Mal neu installiert. Zu diesem Zweck wurde die ganze 500 GB WD Black an die VM durchgereicht und darauf das System installiert. Für den Baremetal-Vergleich wurde dann einfach direkt von dieser Platte gebootet. Während des Tests lief natürlich immer nur die eine VM. Bei Xen natürlich neben der Dom0.
    Für den Xen Hypervisor wurde ebenfalls Ubuntu Server 13.10 mit Xen 4.3 genutzt. Hier wurde dann das ganze Device der WD Black (/dev/sdb) an die VM durchgereicht. Bei der Xen HVM hat Ubuntu automatisch die PV-Treiber für Netzwerk, Festplatte usw. geladen.
    Für den ESXi Hypervisor wurde ESXi 5.5 genutzt. Hier wurde von der WD Black ein RDM erzeugt und dieses an die VM durchgereicht. Das ist im Prinzip das Äquivalent zum Durchreichen des Devices unter Xen. Allerdings hängt hier immer noch der ESXi bei den Zugriffen dazwischen. Bei Xen bekommt die VM dann direkten Durchgriff auf die Platte.


    Da die Phoronix Test Suite die Ergebnisse als Website zur Verfügung stellt, habe ich das einfach mal auf meinen Webspace gestellt. Die Ergebnisse sind hier einsehbar.


    Es gibt dabei mehrere Ausreißer, die ich mir wie folgt erkläre:
    Beim IO-Zone Benchmark ist die echte Maschine unplausibel viel schneller als die VMs. Das dürfte am Hauptspeicher liegen. Die physische Maschine hatte volle 8GB während die VMs nur 4 GB zur Verfügung hatten. Da das Testfile 4 GB groß ist passt es bei der physischen Maschine komplett ins RAM und damit ist der Test viel schneller. Leider konnte ich das nicht vermeiden, da ich keine 4 GB RAM in zwei Modulen hier habe. Wenn ich von den 8 GB einen Riegel raus nehme, dann ist die physische Maschine bei allen RAM-Tests nur noch halb so schnell, weil es dann kein Dual-Channel mehr gibt.


    Die anderen Ausreißer betreffen ESXi. Der ist bei einige Filesystemtests und beim SQL-Benchmark sogar schneller als die physische Maschine, was ja nicht sein kann. Ich gehe davon aus, das ESXi die Plattenzugriffe puffert und somit die Zugriffe nicht bis auf die Platte gehen. Das ist natürlich schneller.


    So, dies waren nun die Unschärfen.


    Bei den meisten Tests liegen die Systeme überraschend dicht beieinander. Oft im Bereich der Messtoleranz. Für mich überraschend ist, das XenPV in vielen Bereichen keinen Vorteil gegenüber XenHVM mit PV-Treibern hat. In wenigen Bereichen bringt XenPV einen Vorteil. In überraschend vielen schneidet XenPV aber sogar schlechter ab als XenHVM.
    Abgesehen von den Ausreißern schneidet ESXi in vielen Bereichen gleich ab wie XenHVM. Teilweise etwas schlechter, wobei es nicht gravierend ist.
    In vielen Bereichen haben die VMs kaum Performancenachteile gegenüber der physischen Maschine.


    Mein Fazit:
    Man kann eigentlich kaum einen klaren Sieger ausmachen. Wenn man nicht spezielle Anforderungen hat dürfte es in der Praxis kaum eine Rolle spielen welchen Hypervisor man nutzt.

    Quote

    ProjectX ist mir geläufig, doch es das so genau nimmt, wußte ich nicht. Werde es mal ausprobieren. Aber wie man nachlesen kann, ist das Ergebnis wohl nicht ganz befriedigend.


    Inwiefern?
    Erkannt werden Fehler mit ziemlicher Sicherheit. Allerdings kann man in den Einstellungen auch Vorgaben machen, wie tolerant ProjectX sein soll. Man kann es natürlich auch so einstellen, das es viele Fehler ignoriert. Wenn die Einstellungen also zu locker sind, dann kommt man nicht zum gewünschten Ergebnis.
    Außerdem ist wichtig wirklich zu demuxen. Beim Umpacken in ein anderes Stream-Format werden nicht alle Fehler erkannt.


    Quote

    Aber leider nur bei SD ,HD kann Projektx nicht.


    Ja, das ist leider korrekt.


    EDIT: Ich habe gerade nochmal in dem verlinkten Thread gelesen. Die am Anfang gemachte Empfehlung alle PIDs abzuwählen kann man so nicht stehen lassen. Damit werden nämlich dann viele Fehler nicht mehr erkannt. Man sollte schon den Viedeostream und die Audiostreams drin lassen, damit diese auch vollständig geprüft werden.

    Eine sehr intensive Prüfung auf Fehler macht ProjectX beim demuxen. Das könnte man benutzen. Man muss halt die dann erzeugten Elementarströme danach wieder löschen. ProjectX schreibt auch ein Log das man dann prüfen könnte.


    Wobei aber auch zu sagen ist, das nicht jeder Fehler im Transportstrom die Aufnahme gleich unbrauchbar werden lässt. Es gibt halt auch den Fall, das der Aussetzer sehr kurz war und es beim Anschauen nur ein kurzes Aufblizen von ein paar Artefakten gibt oder es ist nur ein kurzer Tonaussetzer. Manche Fehler sind so winzig, das man sie gar nicht wahr nimmt, wenn man nicht weiß das da was ist. Deswegen kann man die Aufnahme ja trotzdem noch anschauen.


    ProjectX findet halt absolut jeden Fehler. Aber bei der Auswertung des Logs könnte man natürlich auch mit Schwellwerten arbeiten oder so.


    Davon abgesehen korrigiert ProjectX auch manche Fehler. Natürlich nicht in der Originaldatei sondern in den resultierenden Elementarströmen. Wenn man die wieder muxed, dann hat man einen absolute sauberen Transportstrom. Allerdings werden aus unkorrigierbaren Fehlern dann Aussetzer (aber ohne Artefakte).

    Neue VM-Versionen unterstützen andere Features. Z.B. sind größere virtuelle Platten möglich. Meistens ist das aber nichts, was für den Privatanwender besonders wichtig wäre.
    Bei VM-Version 10 kam allerdings SATA-Unterstützung hinzu. D.h. es ist möglich die virtuellen Platten als SATA-Gerät an die VM weiter zu reichen. Das wäre durchaus ein Punkt für VM Version 10.


    Aber wie gesagt, mit dem freien ESXi lieber nicht upgraden. Die VM lässt sich zwar noch starten, stoppen usw. Aber eben nicht mehr bearbeiten.

    Bitte komm nicht auf die Idee ein Upgrade Deiner VMs auf Version 10 vorzunehmen (über Rechtsklick auf die VM).
    Das Ergebnis wird sein, das Du mit dem vSphere Client diese VMs nicht mehr verändern kannst. Du kannst sie nur noch stoppen, starten, löschen. Aber die Konfiguration nicht mehr bearbeiten.


    Leider hat vmware den vSphere Client an der Stelle nicht mehr weiterentwickelt. Es gibt nun keine Möglichkeit mit dem freien ESXi VMs in Hardware Version 10 zu nutzen. Außer die Config-Files manuell zu editieren.


    Wieviel Strom verbraucht Deine Kiste im Leerlauf?

    Nur mal als Vorschlag: Vielleicht solltest Du es mal mit einem anderen Hypervisor versuchen. Am Anfang des Threads war ja schonmal Xen ein Thema. Allerdings, wenn ich mich recht erinnere, wolltest Du eine Web-Oberfläche. Und die gibts bei Xen nicht so einfach.
    Ich habe mich die letzten Tage stark mit Xen und Archipel als Oberfläche beschäftigt. Archipel ist zwar noch Beta, aber zumindest in Verbindung mit dem XM Toolstack funktioniert es recht gut. Leider ist die Einrichtung komplett Handarbeit. Ich bin nach der Archipel-Doku zum Ziel gekommen. Ich wollte auch noch eine Step-by-Step Anleitung machen, aber die braucht noch eine Weile.
    Jedenfalls könnte die Kombination auch Deine Anforderungen treffen.


    Der Vorteil ist, das Xen auch ohne Virtualisierungsfunktionen Hardware an PV-Gäste weiterreichen kann. Und auch bei HVMs hatte ich bislang keine Probleme (allerdings auf Intel-Hardware).


    Ich habe Archipel auf Ubuntu Server 13.10 aufgesetzt.

    Jo, mir waren die Werte schon weiter oben suspekt. 64 Watt minimal erscheint wirklich sehr hoch. So viel nimmt auch bei mir selbst der Server nicht. Und das trotzdem zusätzlichem HBA mit 6 Platten und Quad-Tuner (ok, ist DVB-C also keine LNBs zu versorgen). Dennoch der Server liegt mit den Platten im Standby immer noch deutlich unter 50 Watt.


    Ich würde mal die TV-Karte raus nehmen oder zumindest die Kabel abziehen, um den LNB-Verbrauch raus zu kriegen. Eine Messung ganz ohne TV-Karte würde dann auch noch den Eigenverbrauch der Karte raus bringen.


    Wieviele Platten stecken in dem System?

    OK, abgezogenes Kabel hab ich natürlich nicht probiert ;)


    Die Frage zielte auch eher darauf was es sonst ggf. noch für Vorteile gibt, abgesehen von möglicherweise höherer Performance.
    Wobei die Performance für mich das Hauptthema ist. Da es nur eine Fileserver-VM gibt und sich alle andere von dieser die Daten holen.
    Wie gesagt, ich hatte auch angenommen, das bei einer einfachen Bridge alles durchs physische Netzwerk läuft. Scheint ja aber nicht der Fall zu sein.

    Quote

    Eines darfst Du nie vergessen, die Dom0 ist immer die erste VM einer Xen Installation. Sie dient zur Kontrolle des Hypervisors, an welchen Du nicht direkt rankommst. Das schlägt sich sicher auch in den Benchmarkwerten nieder und ist bei KVM oder VMWare anders ...


    Das ist mir klar. Deswegen war der Memory-Durchsatz in der DOM0 genauso schlecht wie in einer PV DOMU.
    Für die Vergleichmessungen der nativen Performance wurde komplett ohne Xen gebootet.
    Gemeint war das von Dir zitierte so:
    Bei Messungen in einer DOMU lief keine andere DOMU. Bei Messungen in der DOM0 lief keine DOMU.



    Noch eine andere Frage zu einem Beitrag weiter vorne in diesem Thread:
    Du hast auf Open VSwitch umgestellt.
    Da hattest Du auch geschrieben das bei einer einfachen Bridge die Daten erst ins Hausnetz laufen und dann zur anderen VM zurück kommen. Das dachte ich bisher auch.
    Da ich aber schonmal am benchmarken war, habe ich gleich nochmal einen iperf zwischen verschiedenen VMs laufen lassen. Der wirft mir zwischen PVs ca. 25 GBit/s aus und zwischen HVMs ca. 20 GBit/s.
    Das wiederum spricht aber gegen ein Durchlaufen des normalen Netzwerkes. Das hat bei mir nur 1 GBit. Kann also den Durchsatz nicht bringen.
    Ich frage mich nun, ob sich für mich der Aufwand noch lohnt auf Open VSwitch umzustellen.

    Quote

    Ich empfinde da eher das Gegenteil, hatte beides inzwischen mehrfach auf dem selben Blech installiert, um genau das mit ein paar Standardaufgaben zu prüfen, hab aber nie Benchmarkstools genutzt.


    Darauf einen Benchmark zu machen bin ich auch erst aus dem Gefühl heraus gekommen.
    Mir fiel das immer schon bei einer Ubuntu-Installation auf. Ich hatte immer das Gefühl die dauert länger als direkt auf dem Blech. Egal ob HVM oder PV. Und ich hatte ebenfalls das Gefühl, das sie länger dauert als unter ESXi.
    Bei Windows gleiches Spiel. Wobei ja Windows erstmal keinerlei Treiber für den Betrieb in einer VM hat. Nach Treiberinstallation wird es ja eh merklich schneller.
    Nur Linux bringt ja im Kernel bereits den treibermäßigen support mit. Oder was hast Du bei einem Linux-Gast noch zusätzlich installiert?


    Leider bin ich irgendwie nie dazu gekommen, die Installation mal zu "stoppen".
    Jedenfalls wollte ich das dann mal etwas nachmessen. Daher bin ich auf die Benchmarks gekommen. Die CPU-Performance ist unter Xen vielleicht ein wenig besser als unter ESXi. Aber die Unterschiede sind da so nahe an der native Prformance des Processors, das es praktisch keinen Unterschied macht. Die Messungen erfolgten natürlich ohne andere laufende VMs.
    Auffällig war eben nur die schlechte RAM-Performance. Wobei sowas natürlich auch speziell am Benchmark liegen kann. Je nachdem wie dieser misst.
    Aber es war schon eigenartig, nicht nur der Vergleich zum ESXi. Ich habe ja auch Messungen direkt auf dem Blech gemacht (also ganz ohne Xen). Da war es im erwarteten Bereich. Mit Xen, beim PV Gast und in der DOM0, gibts dann auf einmal nur noch 1/8 des nativen Durchsatzes. HVM bringt es immerhin noch auf die Hälfte. Aber es ist auch schräg, das der Durchsatz bei einer HVM besser ist als PV.


    Ich muss mir nochmal ein paar praxisnähere Benchmarks suchen. Synthetische Benchmarks können ja da durchaus lügen.

    Hallo fnu,


    hast Du mal Performancemessungen in den VMs gemacht?


    Ich bin gerade dabei einem Xen-Host aufzubauen. Allerdings die OpenSource Veriante. Der technische Unterbau ist ja aber der gleiche wie bei XenServer. Als Frontend verwende ich Archipel.


    Wie auch immer, irgendwie kamen mir die VMs im Vergleich zu VMs auf meinem ESXi immer etwas langsamer vor. Das veranlasste mich zu ein paar Messungen. Ich habe dazu sysbench genommen. Die CPU-Performance entspricht bei nur einer laufenden VM sowohl unter Xen als auch ESXi nahezu der nativen CPU-Performance.
    Allerdings ist der Speicherdurchsatz sehr verwunderlich.


    Auf dem ESXi-Host erreicht eine VM einen Speicherdurchsatz von ca. 3,7 GB/s. Auf dem Xen-Host direkt auf der Hardware (also ohne Xen) sind es ebenfalls ca. 3,7 GB/s. In der Xen-DOM0 werden allerdings dann nur noch ca. 500 MB/s erreicht. In einem PV-Gast ebenfalls ca. 500 MB/s. In einem HVM-Gast sind es knapp 2 GB/s.


    Die Werte wundern mich schon etwas. Sollte hier Xen so weit hinter ESXi zurück liegen?


    Der ESXi und Xen sind hardwaremäßig bei mir übrigens nicht unähnlich. Gleicher Takt, gleicher Speicher usw. Die CPU ist nur der ESXi ein Sandy-Bridge, der Xen Host ist ein Haswell.


    Vielleicht kannst Du ja mal einen Durchlauf mit sysbench auf Deinem System machen. Mich würden mal Vergleichswerte interessieren.

    Also laut Intel sollte das Board VT-d haben.
    Die Einträge im Bios können auch Intel Virtualisation Technology oder ähnlich heißen.


    Zu UCS: Kommerziell ist daran letztlich der Support. Möglicherweise sind einige Komponenten CS. Jedenfalls ist es für Privatanwender aber kostenfrei. XenServer ist ebenfalls frei verfügbar. Ich weiß nicht ob man sich da nun wegen möglicherweise ein paar CS-komponenten das Leben schwer machen muss. Aber das darf jeder selbst entscheiden.


    Für ein normales Xen unter z.B. Ubuntu oder Debian gibt es meines Wissens keine WebGUI. Und ich habe schon viel nach sowas gesucht. Was geht ist Virt-Manager. Das ist ein Programm unter X und auch recht komfortabel. Über X kann man es ja auch remote ausführen.

    CentOS unterstützt doch default-mäßig gar kein Xen.


    Für Debian gibt es meines Wissens Xen-Pakete. Für Ubuntu auf jeden Fall. Ich nutze für meien Xen-Exterimente Ubuntu Server.
    Künzlich habe ich mit Univention Corporate Server angesehen. Auch Debian/Ubuntu-basiert. Das ist eigentlich auch sehr schick gemacht und man hat eine Webobfläche. Nach der Installation läuft nach 10 Minuten die erste VM. Allerdings habe ich auf Anhieb keine Option für einen PV-Gast gefunden. Immer HVM. Und das setzt VT-d/VT-x voraus.


    Wenn Deine Hardware kein VT-d/VT-x bzw. bei AMD IOMMU unterstützt, dann ist der einzige Weg Xen. Oder eben Citrix XenServer, was letztlich ebenfalls Xen als Hypervisor nutzt. Nur Xen kann Hardware ohne entsprechende Funktionen an einen PV-Gast durchreichen.


    Du musst IOMMU ggf. im Bios noch aktivieren. Oft ist es ab Werk disabled, auch wenn es unterstützt wird. Und Board und CPU müssen es unterstützen. Es wäre hilfreich, wenn Du mal die exakte Hardware schreibst.


    VirtualBox kannst Du dafür übrigens vergessen. Das Durchreichen von USB funktioniert nur sehr hakelig. Selbst wenn es nur ein Speicherstick ist. PCI/PCIe Karten gehen meines Wissens gar nicht.

    Ich betreibe seit Jahren unterschiedliche Server mit Festplatten-Sleep. Mit der Stabilität gabs da nie Probleme.
    Auch in einem Software RAID5 Verbund legten sich die Platten problemlos schlafen.


    Mit meinen WDs hatte ich am Onboard-Controller mal das Problem, das sie gleich wieder anliefen. Geholfen hat interesanterweise eine Änderung der Idle-Zeit von 15 Minuten auf 10 Minuten. Danach schliefen sie ein und wachten auch nicht mehr auf. Inzwischen hängen sie an einem SAS HBA. Dort schlafen sie immer problemlos ein.

    Stimmt, liegt natürlich auch an der Regelung im Bios. Ich hatte es auf Standard gelassen. Damit regelt er bei meinem Board zwar runter, aber er geht nie ganz aus. Und vermutlich liegt die Grunddrehzahl dann auch immer noch zu hoch.
    Und in einem VDR-Server idled die CPU ja eh die meiste Zeit vor sich hin.

    Öhm gda, hier gehts um DVB-C. Die Cine CT selbst nimmt 2 Watt auf. Ein zusätzlicher Doppeltuner nochmal 2 Watt. Da gibts nichts groß zu kühlen.


    Wenn Du den Boxed-Lüfter leise findest, dann haben wir extrem verschiedene Ansichten von leise. Ich finde die Teile unmöglich. Er ist nicht ausgesprochen laut, aber von leise ist er weit entfernt.

    Bei dem Case bin ich nicht sicher. Wenn ich die Bilder auf der LC-Power Homepage anschaue, dann sehe ich da von hinten nur 2 Slotbleche. Damit µATX passt müssten es aber 4 sein. Das LC-1400mi sieht dagegen eher so aus als würde µATX.


    Ansonsten weiß ich nicht wo der Rechner bei Dir stehen wird und ob da besondere Ansprüche an den Geräuschpegel bestehen.
    Diesbezüglich wird vermutlich das bei LC-Power mitgelieferte Netzteil nicht ideal sein.


    Als Desktopgehäuse und wenns nicht ganz so günstig sein muss würde ich mir evtl. das Silverstone ML03 mal anschauen. Wobei da das Netzteil extra kommt. Dafür kann man dann auch ein wirklich leises nehmen. Gehäuselüfter braucht man u.U. da gar nicht, weil über dem CPU-Kühler reichlich Lüftungslöcher sind.


    Von Intertech gibts auch noch µATX Gehäuse zu recht schmalen Preisen.


    Deinen CPU-Kühler kann ich nicht beurteilen. Erscheint mir als hätte er etwas wenig "Blech". Je nach Gehäuse würde ich da evtl. etwas ausladenderes nehmen. Vielleicht auch mit 120mm Lüfter.