VDR Server unter VMware ESX

  • Danke für die interessante Diskussion :)
    Xen hatte ich vor Jahren schonmal laufen (nicht mit VDR) - lief gut, war mir aber dann doch zu viel Handarbeit. Anlässlich der Threads von "fnu" zu diesem Thema, habe ich es nochmal versucht, weil ich die Hoffnung hatte, dass es inzwischen besser ist. Ist es definitiv auch. ESX ist aber immer noch einfacher - meines Erachtens v.a. weil die logischen Ebenen nicht so vermischt werden: Ebene VM-Verwaltung und die VM selbst sind sehr sauber getrennt. So habe ich z.B. einen Linux-Fileserver auf 2 physischen Platten am Laufen, die ich ohne Änderung im ESX-Server laufen lassen kann und in einer HW-Maschine. (Das ist nicht das Ziel, aber es macht die gute Trennung deutlich.)


    Ich habe mir nun HW bestellt und werde es erstmal mit ESX ausprobieren :) Wenn es interessiert, werde ich hier meine Erfahrungen (v.a. mit dem Durchreichen der Grafik) berichten.


    Dirk

  • Ja, ich finde ESXi konfigurationstechnisch auch schöner gelöst. Leider verpuscht es VMWare in letzter Zeit ein wenig.


    So wird der Client für die Konfiguration des kostenlosen ESXi nicht mehr weiterentwickelt. D.h. alle Möglichkeiten die nach VMWare Hardware Version 8 hinzu gekommen sind, lassen sich mit dem Client gar nicht konfigurieren. Wir sind inzwischen bei Hardware Version 10. Und insbesondere gibt es inzwischen auch einen virtuellen SATA-Controller, der sich aber mit dem Client gar nicht nutzen lässt.
    Ein kostenloses alternatives Frontend mit allen Möglichkeiten gibt es (noch) nicht.
    Man kann es über VMWare Workstation machen oder über den Web Client. Der Web Client verwaltet aber wieder nur die Demoversion von ESXi oder einen vSphere Server. Nicht aber das kostenlos lizensierte ESXi. Und Workstation kostet Geld. Man kann sich nur mit der Demoversion behelfen.
    Was die Sache noch schlechter macht ist, das man eine VM mit Hardware Version 10 (z.B. eine über den Web Client angelegte) im normalen Client gar nicht mehr konfigurieren kann. Man kommt einfach nicht mehr in die Config rein.
    Auch da gibts Möglichkeiten. Aber es ist schon ein ganz schönes Gebastel.


    Bleibt nur zu hoffen, das VMWare bald den WebClient auch für den kostenlosen ESXi nachschiebt oder einen neuen Client auflegt.


    Ein weiteres Problemchen ist der Umgang mit RAW-Devices. Mit einem Trick ist es zwar möglich eine SATA-Platte als RAW-Device an eine VM durchzureichen. Jedoch sieht die VM dann eine SCSI-Platte. Problem daran ist, das sich damit kein Platten-Standby nutzen lässt. Mithin drehen die Platten dann permanent. Was auch im Sinne des Stromverbrauches nicht ideal ist.
    Die bisherige Lösung dafür war, das man einen Controller direkt per Passthrough an die VM durchgereicht hat. Das geht mit Onboard-Controllern aber nur, wenn das Board mehrere Controller hat. Weil man ja noch Platten direkt am ESXi braucht für den Datastore. Und der Passthrough funktionierte bei weitem nicht mit allen Boards. Alternativ ist einen SAS-HBA dazu zu stecken. Der dann wiederum den Stromverbrauch erhöht (je nach Modell um die 10 Watt).


    Die neue VM Hardware Version 10 könnte über den neuen SATA-Controller einen Ausweg bieten. Ein RAW-Device an diesem müsste dann auch wieder in den Standby gehen können. Da bin ich gerade am Austesten was möglich ist. Aber dann hat man halt das Gebastel wegen dem VMWare Client.



    Bei Xen hat man die Probleme nicht, weil erstens die Dom0 die Platten in Standby schicken kann. Und sich außerdem auch eine Platte problemlos RAW an eine DomU durchreichen lässt und dort dann auch als SATA-Platte ansprechbar ist.


    Klasse 2 Hypervisoren wie VirtualBox oder KVM haben die Probleme natürlich nicht. Sie laufen ja selbst unter Kontrolle eine Wirts-Systems.

  • Eine Option ist z.B. Intel® Xeon® Prozessor E3-1220LV2 (nur 17W)

    Nicht immer den TDP mit der tatsächlichen Leistungsaufnahme verwechseln, gerade bei Intel ist da auch immer ganz viel Marketing drin ...


    TDP = Thermal Design Power => Ist eine Einstufung für welchen Wert an abgegebener Verlußtleistung in Wärme die Kühlung im Maximalfall ausgelegt sein muß. Diese kommt nicht hoffentlich nicht dauerhaft vor und wenn, hat man das System falsch ge-size-d. Die CPU wird hier mehr Leistung aufnehmen als diese 17W. Hier halte ich das für eine echte spezielle Einstufung, keine Schublade, wie bei den anderen CPUs 78W, 65W, 55W, 45W, 35W usw. In diese stecken die Marketingleute diese der Einfachheit halber, obwohl die am niedrigsten getaktete Version in der Realität viel wenige Verlußtwärme abgibt, als der schnellste der Klasse bzw. ist der Unterschied im realen Leben, selten Vollgas, zwischen "T" und "nicht-T" Modellen quasi nicht existent. Der ohne hat aber dank höherem Maximaltakt mehr Leistung wenn's drauf ankommt ...


    Fnu hatte vor nicht allzu langer Zeit mal getestet YaVDR als Dom0 laufen zu lassen. Das hat ohne Schwierigkeiten funktioniert, wenn ich mich recht erinnere.

    Natürlich, funktioniert einwandfrei, yaVDR 0.5 als DOM0, sonste hätte ich davon nicht berichtet. Es ist ein Mähr das irgendeine der Lösung immer problemlos läuft, weil dafür werden zu vielfältig verschiedene HW Basen genommen. Im Prinzip stolpert jeder irgendwann in ein Problem, aber deshalb gleich zu behaupten dies oder jenes wäre besser, sorry Quark.


    Für Xen spricht schlicht die Tatsache, PCI Virtualisierung ist erwünscht, freigegeben und funktioniert auf beliebiger HW, man benötigt für PVs kein VT-d (!) ...


    Xen schiebt sich noch unter den Kernel. Von daher hat es Einfluss.

    Eben, die DOM0 ist die erste virtuelle Maschine ...


    Regards
    fnu

    HowTo: APT pinning

    Einmal editiert, zuletzt von fnu ()

  • Zitat

    Für Xen spricht schlicht die Tatsache, PCI Virtualisierung ist erwünscht, freigegeben und funktioniert auf beliebiger HW, man benötigt für PVs kein VT-d (!) ...


    Für teilweise Paravirtualisierung braucht ESXi auch kein VT-d. PV-SCSI geht z.B. auch so. Nur wenn man PCI/PCIe Passthrough aka DirectIO bei ESXi verwenden will, dann gehts nicht mehr ohne. Wenn man ein System aufbaut, dann ist das aber in meinen Augen keine Hürde. Man kann ja die Hardware so anschaffen, das VT-x/VT-d unterstützt werden.
    Übrigens ist der Passthrough unter Xen auch nicht immer einfach. Ich hab noch einen Phenom II Rechner hier, bei dem bekomme ich es nicht geregelt, eine PCI-Karte an eine VM durchzureichen.


    Jede Lösung hat echte Vor- und Nachteile. Man muss halt abwägen, was in der eigenen Situation am besten ist.
    Xen hat einen riesen Vorteil beim Durchreichen von Festplatten-Devices und damit wenn man z.B. einen Fileserver in einer DomU betreiben will. Unter ESXi sind da viel mehr Verrenkungen nötig.
    Dafür hat ESXi große Vorteile bei der Einfachheit der Konfiguration und Verwaltung der VMs. Wobei VMware da wie oben geschrieben leider inzwischen auch Abstriche macht.

  • Für teilweise Paravirtualisierung braucht ESXi auch kein VT-d. PV-SCSI geht z.B. auch so.

    Angesichts des Themas dieses Threads "VDR Server unter VMware ESX" hat das wohl keine Relevanz, hier geht es um Virtualisierung von DVB Karten.


    Aber Dein Argument hört sich nach einem "VMWare Jünger" an, der wie z.B. Torsten73 weiter oben "seine Lösung" verteidigt ... :rolleyes: ... ich bin da in keiner Schublade, jede Lösung hat Vor- und vorallem Nachteile. Aber thematisch ist hier die problemlose und stabile Virtualisierung der DVB Karten ein wichtiger Punkt, den z.B. Xen mit Bravur auf wahlfreier HW meistert.


    Nur wenn man PCI/PCIe Passthrough aka DirectIO bei ESXi verwenden will, dann gehts nicht mehr ohne.

    Nun für Windows in HVM braucht es das bei Xen auch ...


    Wenn man ein System aufbaut, dann ist das aber in meinen Augen keine Hürde. Man kann ja die Hardware so anschaffen, das VT-x/VT-d unterstützt werden.

    Ein Hürde nicht, aber wenn man keine oder wenig Rücksicht nehmen muß, hilft das ungemein. Gibt viele gute Angebote an fertigen Home-Servern, die in der Regel nicht mit Directed-I/O ausgestattet sind. Und den VDR interessiert es nicht, in welcher Art VM er läuft, das ist scheinbar nur ein mentales Problem der Nutzer ...


    Regards
    fnu

    HowTo: APT pinning

    Einmal editiert, zuletzt von fnu ()

  • Zitat

    Aber Dein Argument hört sich nach einem "VMWare Jünger" an...


    Nein, sicher nicht. Auch war es weniger eine Argumentation für oder gegen irgendetwas. Sondern einfach die Klarstellung, das Paravirtualisierung bei ESXi nicht unbedingt VT-x/VT-d voraussetzt. Das wird erst zwingend, wenn man Hardware direkt an eine VM durchreichen will (was etwas anderes ist als Paravirtualisierung). Natürlich ist es richtig, das man für das Durchreichen einer DVB-Karte beim ESXi VT-x/VT-d benötigt.


    Ich sehe bei beiden Systemen Vor- und Nachteile. Wenn bei ESXi nicht die sehr viel einfachere Verwaltung des Systems wäre, dann hätte ich wohl keinen ESXi-Host. Und selbst aktuell überlege ich noch auf Xen umzusteigen. Und wenn Du weiter vorne nochmal liest, dann hatte ich ebenfalls eher Xen empfohlen.


    Wie gesagt, das einzige Problem dieser Lösung für mich ist die Konfiguration. Klar kann man das alles lernen, wenn man sich damit befasst. Allerdings muss man eben auch den Fall sehen, das man mal 1 Jahr lang nichts an der Konfiguration gemacht hat (was zumindest bei mir durchaus vorkommen kann). Dann fängt man auf der Kommandline praktisch wieder von vorne an und braucht recht lange für eine u.U. einfache Konfigurationsänderung. Ich meine das nicht mal so sehr in Bezug darauf eine einfache VM auszusetzen. Dafür geht Virt-Manager ganz gut. Mit Passthrough-Geschichten sieht dann schon wieder anders aus. Dafür gibts kein Frontend und man muss manuell in die Konfiguration eingreifen.


    So richtig verstehe ich auch nicht warum es kein gutes Frontend für Xen gibt. Es gab einige Ansätze. Viele sind dann einfach wieder verschwunden. Andere driften dann zu sehr in die professionelle Richtung und eignen sich eher um ganze Serverparks zu verwalten.


    XenServer bringt leider auch keine so endgültige Lösung. Das hat zwar ein Frontend. Aber wenns in die Details geht, dann findet man sich auch sehr schnell auf der Kommandline wieder.


    ESXi hingegen hat den Nachteil mehr in technischen Gegebenheiten. VT-x/VT-d sehe ich da weniger als Problem.
    Echt bescheuert ist die oben schonmal angerissene Problematik mit dem Durchreichen von Festplatten. Ich habe da die Tage nochmal dran gespielt. Vor allem weil es seit VM Hardware Version 10 nun auch endlichen einen virtuellen SATA-Controller gibt. Leider gibt es dennoch keine Möglichkeit eine Festplatte so als RAW-Device durchzureichen, das man anschließend diese auch in den Standby schicken kann. Smart-Kommandos und so bekommt man alles ohne Probleme zum funktionieren. Nur eben Standby funktioniert schlicht und ergreifend nicht. Und in meinen Augen sind bei einem Home-Server dauerlaufende Festplatten ein NoGo. Die einzige Lösung dafür ist den ganzen Controller an die VM durchzureichen. Das funktioniert mit Onboard Controllern nur sehr bedingt. Also hat man ganz schnell noch einen SAS HBA im Rechner stecken. Kostet Geld und braucht auch wieder Strom.
    Solche Probleme hat man mit Xen natürlich gar nicht.

  • Nun für Windows in HVM braucht es das bei Xen auch ...


    Sorry fnu, das verstehe ich nicht. Es geht mit Linux Gäste, aber für W ist es nicht verfügbar? Warum das? Kannst Du es bitte erklären!?


    Albert

  • Unter Xen wir zwischen paravirtualisieren Gästen (kurz PV für Paravirtualized) und vollvirtualisierten Gästen (kurz HVM für Hardware virtualized Machine) unterschieden. PV-Gäste zeichnen sich dadurch aus, das der Gast "weiß" das er unter einem Hypervisor läuft. Dazu braucht der Gast aber einen dafür angepassten Kernel. Der Vorteil ist, das der Gast quasi mit dem Hypervisor beim Hardwarezugriff "zusammenarbeiten" kann. Er hat teilweise direkten Hardwarezugriff. Bei Linux Distributionen ist es inzwischen Standard, das die Xen-Unterstützung im Kernel enthalten ist.
    Der Windows-Kernel weiß natürlich nichts von Xen und kann deshalb nicht als PV-Gast laufen. Windows muss als HVM-Gast laufen und sieht damit nur komplett virtualisierte Hardware. Ein Durchreichen echter Hardware ist in dem Falle nur noch mit VT-x/VT-d Unterstützung möglich.

  • HTPC-Schrauber, danke für die Erklärung.


    PV-Gäste zeichnen sich dadurch aus, das der Gast "weiß" das er unter einem Hypervisor läuft.


    Das erscheint mir aber bedenklich, denn es ist doch kein Desktop-Virtualisierung. Mein Favorit ist immer: der Hypervisor weißt alles, die Gäste schuften. Sie müssen nichts von der Virtualisierung wissen, allgemein gesagt.


    Albert

  • ATD


    Xen HVM ist das was Du und eigentlich alle von VMWare, Virtualbox, Qemu oder KVM/Proxmox kennen, wie beschrieben eine Vollvirtualisierung. D.h. es wird eine PC Standard-HW emuliert auf welcher man ohne spezielle Trieber ein OS installieren kann in der Regel mit Grafik, weil diese auch emuliert wird, Standard-VGA. Die HW von Xen HVM basiert auf den Qemu Definitionen


    Installiert man nun in der VM das zugehörige Treiberpaket, VMWare Tools, XenTools, VirtualBox Gasterweiterung etc., dann ist es technisch gesehen schon keine Vollvirtualisierung mehr, sondern eher eine Paravirtualisierung, weil die VM durch die Treiber direkt an den Hypervisor angebunden werden und die Performance verbessert. Bei Virtualbox sogar inkl. einer speziellen Grafikausgabe.


    Bei Xen PV (Paravirtualization) werden die VMs von Haus aus mit passender Anbindung an den Hypervisor installiert, die nötigen Treiber sind seit Kernel 2.6.17 oder so in Kernel Upstream enthalten. Die VM weiß nicht das sie eine VM ist, sie läd nur die passenden im Kernel enthaltenen Treiber für Block und Net Devices direkt ab Installation. Dieser Modus ist der traditionelle Xen Weg, beinhaltet auch PCI Virtualisierung und stammt aus einer Zeit, da hatten selbst die wenigsten CPUs VT-x eingebaut, von VT-d keiner Spur ...


    Generell funktioniert Paravirtualization nur mit vorab angepasster Software, dazu gehören aber auch solche Spielarten wie chroot, OpenVZ, User Mode Linux, etc. und eines haben alle gemeinsam, sie sind auf cmdline beschränkt, keine Grafik-Emulation. Diese gäbe es bei Xen PV nur, wenn man eine Grafikkarte virtualisiert ...


    Regards
    fnu

    HowTo: APT pinning

    3 Mal editiert, zuletzt von fnu ()

  • So wie Du es beschreibst, klingt es so, als gäbe es keinen Unterschied zwischen einem Gast mit einigen PV-Treibern und einem echten PV-Gast.
    Nach meinem Verständnis ist das aber nicht so. Und Xen selbst sieht das offenbar auch nicht so:
    http://wiki.xenproject.org/wiki/Xen_Overview#Guest_Types


    Zitat

    However, paravirtualized guests require a Xen-PV-enabled kernel and PV drivers, so the guests are aware of the hypervisor and can run efficiently without emulation or virtual emulated hardware


    Für mich heißt das zum einen, das es mehr braucht als nur PV-Treiber. Und zum anderen, das der Gast durchaus "weiß" das er eine VM ist. Was sonst heißt "are aware of"?


    ATD:
    Ich hatte oben ja auch nur die beiden Reinformen beschrieben. Fnu hat noch die "Mischform" ins Spiel gebracht: HVM mit PV-Treibern. D.h. es ist erstmal eine vollvirtualisierte VM, bei der aber einzelne Treiber (z.B. Netzwerk und Platten-Controller) paravitualisiert sind. Im Unterschied zur PV muss hier aber nicht der ganze Kernel PV-fähig sein, sondern es betrifft nur den einzelnen Treiber. Deshalb gibt es sowas auch mit Windows-Gästen.


    Neu in Xen 4.3 ist noch PVH. Damit hab ich mich noch nicht weiter befasst und kann daher nichts dazu sagen.


    Ob ein PV-Gast nun gut oder schlecht ist, das ist eine eher philosphische Frage. Der Vorteil eines PV-Gastes ist, das er erstens keine speziellen Virtualisierungsfunktionen bei der Hardware benötigt und zweitens das die Performance höher ist als bei einer HVM.
    Es spricht übrigens auch nichts dagegen eine Linux-VM als HVM zu betreiben. Kann man problemlos machen, wenn man den PV-Gast aus irgendwelchen Gründen nicht mag.

  • So wie Du es beschreibst, klingt es so, als gäbe es keinen Unterschied zwischen einem Gast mit einigen PV-Treibern und einem echten PV-Gast.

    Gibt es im Prinzip auch wenig zwischen einer PV und einer HVM mit "PV to HVM" Treibern, letztere hat eine Grafikausgabe. Der Unterschied ist nur, bei PV wird der Gast mit Treibern installiert, ohne würde die Installation nicht funktionieren, bei "PV to HVM" erstmal ohne Treiber in generische HW, aber das OS hat hier ja auch schon Treiber für diese generische HW.


    Es werden bei den diversen Tool-Sets nicht nur Treiber installiert, sondern in der Regel auch "Kern-Erweiterungen" und Services welche die eigentlich vollvirtualisierte VM ebenso "aware of Hypervisor" macht. Aber der Ausdruck "er weiß von" ist IMHO falsch, das sind Computer, die wissen nix ... 8o


    Niemand der einen VM Host betreibt, läßt die Maschinen ohne Tools Paket also vollvirtualisiert ohne Optimierung laufen, die Xen Leute nennen es einfach nur "PV to HVM", ist aber tatsächlich entweder die XenTools bei XenServer (XCP/XAPI) oder das GPLPV Paket von Univention bei Xen ohne XenServer ...


    Die Tools dienen ja auch zur Überwachung und Steuerung z.B. memory usage , ballooning, shutdown, restart, etc. Installier mal Windows Server in eine Xen HVM, das installierte Windows erkennt sofort, das es in einer VM installiert wurde und das ganz ohne Tools. Diese helfen nur die VM nachher noch optimaler darin zu betreiben.


    Bei KVM ist das sehr ähnlich, die installierte Linux VM ist, da KVM auch schon lange im Kernel enthalten ist, bei der Installation "aware of Hypervisor", obwohl es sich um eine vollvirtualisierte VM handelt. Nur Xen kennt diesen PV Modus ...


    Regards
    fnu

    HowTo: APT pinning

    2 Mal editiert, zuletzt von fnu ()

  • Zitat

    Aber der Ausdruck "er weiß von" ist IMHO falsch, das sind Computer, die wissen nix ...


    Ja, das ist natürlich richtig. Die Kisten wissen nichts. Daher stand das wissen ja auch in Anführungszeichen.
    Es war natürlich eher so zu verstehen, als das der Kernel es feststellen kann und somit für die Virtualisierung optimierten Code nutzen kann (nicht nur Treiber).


    Dennoch m.E. ist HVM mit PV-Treibern durchaus etwas anderes als PV. Und aus dem oben verlinkten Xen-Wiki glaube ich auch genau das herauszulesen.


    Um Hardware (wie eine PCI-Karte) an eine HVM mit PV-Treibern durchzureichen brauchst Du auch immer noch die Virtualisierungsfunktionen in der Host-Hardware. Wie oben schon als großer Vorteil von Xen festgestellt braucht man das bei PV-Gästen nicht. Auch emuliert die HVM mit PV-Treibern auch immer noch ein komplettes Bios und die Hardware für die keine PV-Treiber vorhanden sind.
    Ein PV-Gast läuft ganz ohne emulierte bzw. virtuelle Hardware. Er hat über den Xen-Stack Durchgriff auf die Hardware. Was bei einem HVM-Gast mit PV-Treibern nur teilweise der Fall ist. Eben für genau die Geräte, für die PV-Treiber vorhanden sind.


    Und ja, in der Praxis wir kaum eine VM komplett vollvirtualisiert laufen. Sondern immer PV-Treiber zur Performanceverbesserung und auch Extensions damit der Hypervisor die VM steuern kann zum Einsatz kommen. Auch bei VMWare ist das der Fall.


    Aber ich glaube auch wir verlieren uns langsam ein bißchen in Details ;)

  • Wie oben schon als großer Vorteil von Xen festgestellt braucht man das bei PV-Gästen nicht

    Interessant! Das heißt ja im Umkehrschluss, ich könnte mir in diesem Fall das ganze komplizierte Gedöns mit Durchreichen usw. ersparen. Ich nehm z.B. Proxmox, eine PV Vorlage wie Debian oder Ubuntu und kann von dieser direkt z.B. auf eine TV-Karte zugreifen? Das müsste doch eigentlich auch performanter laufen, oder? Sehen diese PV-Maschinen automatisch immer die komplette Hardware des Hosts oder muss man das vorher festlegen?


    Markus

    Streamingclient 1:
    [-] RaspiVDR MLD 5.x an Panasonic TV mit CEC :D


    Streamingclient 2:
    [-] RaspiVDR MLD 5.x - Samsung TV mit CEC


    Streamingserver:
    [---] Proxmox Server PVE7
    [- ] MLD 5.x Server - OctopusNet 4 Tuner

  • Nicht das Durchreichen braucht man nicht. Sondern die Hardware muss dafür keine Virtualisierungsfunktionen (VT-x/VT-d bzw. AMD-V/IOMMU) unterstützen. Sprich es geht auf jeder Hardware.
    Man muss dennoch z.B. eine TV-Karte vom Host "abkoppeln" und an die VM durchreichen. Sonst bekommt der Gast die Karte nicht zu sehen. Wie das genau geht, das hatte Fnu im Server-Bereich des Forums schon einmal Schritt für Schritt beschrieben.
    Und die Gäste bekommen nicht die komplette Host-Hardware zu sehen. Das geht auch nicht. Beispielsweise eine TV-Karte kann ja nur immer von einem Gast zur gleichen Zeit genutzt werden.
    Auch greift der Gast bei PV nicht wirklich direkt auf die Hardware zu. Sondern er tut das durch eine Zwischenschicht, die Xen bildet. Deshalb muss ein PV-Gast auch einen Xen-aware Kernel haben. Der Punkt ist aber, das dadurch die Performance nahe an einen direkten Hardwarezugriff heran kommt. Im Gegensatz zu einem vollvirtualisierten Zugriff, wo der Gast nur emulierte Hardware sieht.
    Beim Durchreichen einer Karte an einen Gast bekommt der Gast dann jedoch wirklich direkten Hardwarezugriff auf genau diese Karte. Daran ist dann auch nichts mehr virtualisiert, weshalb diese Karte dann auch immer nur von einem Gast zur Zeit genutzt werden kann.


    Ob das mit Proxmox so geht, das weiß ich nicht. Ich dachte bisher das die Virtualisierung bei Proxmox mit KVM läuft. KVM ist im Grunde erstmal eine Vollvirtualisierung. Außerdem ist es ein Klasse 2 Hypervisor (läuft also unter Kontrolle des eigentlichen Betriebssystems), wohingegen ESXi, XEN und XenServer Klasse 1 Hypervisoren (laufen direkt auf der Host-Hardware) sind.

  • Moin,


    habe an einem Regentag in der Woche ein Update von ESXi 5.1 auf 5.5 gemacht.
    Die 1-2 Miniruckler bzw. Verpixelungen pro Aufnahme sind jetzt weg.


    Bei mir kommen die DVB-S2 Tuner über USB zu der vm, es schein das an dem
    USB Handling was verbessert wurde.


    Es läuft immer noch das kleine Intel Server Board (S1200KP) bei mir...
    Ein Upgrade z.B. auf das Asus P9D-I ist nicht wirtschaftlich für mich.


    Munter bleiben, Rossi

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!