Welchen Hypervisior nutzen?

Pheenix

Enthusiast
Thread Starter
Mitglied seit
25.07.2006
Beiträge
2.895
Ort
Offenbach (Hessen)
Hallo,

ich möchte gerne ein wenig anfangen zu virtualisieren, bisher schweben mir drei System vor die ich virtualisieren möchte:

1.) Router mit OPNSense
2.) FreeNAS mit ZFS
3.) Web/Datenbankserver
4.) Minimales Debian für jDownloader und ähnliches

Zur Verfügung habe ich dafür einen Pentium G3250, das Asus P9D-C sowie 16GB ECC Ram. Der Hypervisior soll auf einem USB Stick laufen (USB Port dafür ist sogar direkt auf dem MoBo), die einzelnen virtuellen Maschinen sollen ihren Platz auf einer 128GB SSD finden. Jetzt stehe ich nur vor der großen Frage: Welchen Hypervisior soll ich nehmen? Mein Plan war grundsätzlich ESXi (oder vSphere?) zu nutzen. Mittlerweile gibt es ja aber diverse verschiedene Lösungen, welche empfiehlt sich den? Der Hyper-V fällt eher raus, weil ich kein Windows virtualisieren möchte.

Vielen Dank,
Sebastian
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Proxmox hat den Vorteil, dass es auch Container-Virtualisierung kann, was wesentlich weniger Resourcen als eine VM benötigt. VM brauchst Du dann nur noch für andere OS (Windows, Solaris). Insbesondere, da Du ZFS machen willst, empfiehlt es sich möglichst viel RAM für den ZFS-Cache zur Verfügung zu haben und ihn nicht an VMs zu "verschwenden", wenn die Sache auch im Container läuft.

Außerdem kannst Du das ZFS damit schon im Wirts-System betreiben, was den Vorteil hat, dass es sich Verzeichnisse daraus direkt an einen Container durchreichen (mounten) lassen ohne über ein Netzwerk-Protokoll (NFS, iSCSI) gehen zu müssen. In der Web-UI fehlt zwar die NAS-Funktionalität (Freigaben, einrichten usw.) wie bei FreeNAS, aber für Samba-Shares könntest Du da z.B. auch die Turnkey-Fileserver-Appliance gehen.

Der dritte Vorteil ist das mächtige Web-UI, in dem 90% aller Use-Cases abdeckt (aber eben nur Virtualisierung, keine NAS-Funktionen), d.h. Du brauchst kein Windows zum administrieren.

Achso, USB-Stick ist vielleicht nicht so optimal, da viel ins Filesystem geschrieben wird und dieser dann schnell sterben wird, aber eine kleine SSD über USB-Adapter wäre gut machbar.
 
Zuletzt bearbeitet:
ESXi läuft sehr gut ab USB Stick.

Aber ein vernünftiges Storage bauen ohne zusätzlichen RAID Controller wird schwierig.
Weil

1) Du reichst den Onboard Controller durch (benötigt VT-d?!), dann sind aber alle SATA-Ports auf dem Mainboard nur für die VM's zugänglich
oder
2) Du musst z.B einen USB Stick als Storage für eine minimalistische, weitere VM nutzen, auf der du dann ein Storage baust welches du per iSCASI oder what ever über das interne, virtuelle Netzwerk frei gibst.

Die erste Lösung wäre super, kostet jedoch Geld und braucht mehr Strom.
Die zweite Lösung klappt zumindest bei deiner Konfiguration, ist aber ein bisschen basteln.

Du kannst es dir auch einfacher machen und z.B Proxmox einsetzen.
Da hast du ein vollwertiges Debian-Basiertes Linux.

Auf dem Host kannst du dann z.B ein vernünftiges und schnelles Storage mit schnellem Software Raid bauen (was unter ESXi soweit ich weiss nicht machbar wäre).
Das erspart dir das direkte Durchreichen (was übrigens deine CPU sowieso nicht kann).

Und wie schon vom Vorredner erwähnt, Container-Virtualisierung spart schön Ressourcen.
Kritische Systeme wie den Router würde ich jedoch in einer vollwertigen Virtuellen-Instanz betreiben. Der braucht sowieso kaum Ressourcen.
 
Zuletzt bearbeitet:
und der Pentium hat afaik kein VT-D → entweder kein ZFS oder der Host muss ZFS können ;); welchen Vorteil es hat, eine separate SSD für die VM-Images zu verwenden, weiß ich auch nicht (v.a. wenn man sich dann einen USB-Stick für Linux heranzieht). 2 Partitionen, einmal Host und einmal VMs und gut ist es (falls der Sinn dahinter seinsoll, den Host neu installieren zu können)
 
Verdammt, also mal wieder alles falsch gemacht :-/

Ja, mein Plan war definitiv von Anfang an die Platten komplett an FreeNAS durchzureichen, da dies die einzige wirkliche Instanz ist die Sie nutzt. Gerade, oder insbesondere, die Nutzung von FreeNas ist mir wichtig. Ohne das kann ich das gesamte Projekt quasi so oder so auf Eis legen.

Aber gut - wenn das nicht klappt heißt es wieder warten und sparen auf eine größere CPU. Teures Hobby :fresse:

Danke euch!
 
Ein Skylake Pentium kann VT-D.
Bei ZFS solltest du ECC Speicher verwenden wenn du den RAM als Schreibache verwenden willst.
Weiss aber nicht ob der Skylake Pentium das auch packt.
Oder du kaufst dir einen RAID Controller mit Schreibcache (i.d.R ist dann auch ein BatteryPack drauf im Fall des Stromausfalles).

Minimal kannst du natürlich entweder auf den Hyper-Visor verzichten und dein Traum-NAS Betriebssystem (FreeNAS) einsetzen oder baust dein NAS auf dem Host-OS (Stichwort Proxmox).
Deine Probleme kann man auch mit (kostenloser) Software lösen wie du siehst.

Allerdings fehlt dir dann ein schönes Web-UI zur Verwaltung der NAS-Funktionalität.

Immer gleich andere Hardware kaufen ist nicht die klugste aller Lösungen...
 
Ein Skylake Pentium kann VT-D.
Bei ZFS solltest du ECC Speicher verwenden wenn du den RAM als Schreibache verwenden willst.
Weiss aber nicht ob der Skylake Pentium das auch packt.
Oder du kaufst dir einen RAID Controller mit Schreibcache (i.d.R ist dann auch ein BatteryPack drauf im Fall des Stromausfalles).

Minimal kannst du natürlich entweder auf den Hyper-Visor verzichten und dein Traum-NAS Betriebssystem (FreeNAS) einsetzen oder baust dein NAS auf dem Host-OS (Stichwort Proxmox).
Deine Probleme kann man auch mit (kostenloser) Software lösen wie du siehst.

Allerdings fehlt dir dann ein schönes Web-UI zur Verwaltung der NAS-Funktionalität.

Immer gleich andere Hardware kaufen ist nicht die klugste aller Lösungen...

Ein Großteil der Hardware habe ich erst gekauft, mal schauen was ich davon noch retournieren kann. Skylake Pentium kann eventuell ECC, jedoch ist das Problem das es kaum Skylake-Mainboards gibt die ECC unterstützten bzw. abnormal teuer sind (noch). Habe auch extra 16GB ECC-Ram gekauft, wegen ZFS.

Mein Ziel war es eben eine schöne übersichtliche Web-UI für den NAS zu haben. Wenn ich das nicht bekomme kann ich auch bei meiner alten Lösung bleiben. Will endlich von dieser ekelhaften Samba-Config-File-Frickelei wegkommen :heul:
 
Zuletzt bearbeitet:
Mal eine andere theoretische Idee: ZFS auf Host laufen lassen, und dann durchreichen an FreeNAS/OMV mit einer Virtual Disk? Oder eventuell FreeNAS den Zugriff per NFS/iSCSI auf den Host ermöglichen? Ist aber wahrscheinlich irrsinnig inperformant oder?
 
Zuletzt bearbeitet:
Ein Großteil der Hardware habe ich erst gekauft, mal schauen was ich davon noch retournieren kann. Skylake Pentium kann eventuell ECC, jedoch ist das Problem das es kaum Skylake-Mainboards gibt die ECC unterstützten bzw. abnormal teuer sind (noch). Habe auch extra 16GB ECC-Ram gekauft, wegen ZFS.

Mein Ziel war es eben eine schöne übersichtliche Web-UI für den NAS zu haben. Wenn ich das nicht bekomme kann ich auch bei meiner alten Lösung bleiben. Will endlich von dieser ekelhaften Samba-Config-File-Frickelei wegkommen :heul:

FreeNAS ist doch auch SAMBA.

Ein SMB Server ohne Config File alles in ZFS enthalten) gibts aber unter Solarish, der Quelle von ZFS (Oracle Solaris, NexentaStor, OmniOS). Da läuft auch Snaps als "Windows voreherige Version" out of the Box sowie Windows NTFS artige ACL und Windows SID statt Unix uid/gid. Solarish läuft auch perfekt virtualisiert unter ESXi.
 
Zuletzt bearbeitet:
FreeNAS ist doch auch SAMBA.

Ein SMB Server ohne Config File alles in ZFS enthalten) gibts aber unter Solarish, der Quelle von ZFS (Oracle Solaris, NexentaStor, OmniOS). Da läuft auch Snaps als "Windows voreherige Version" out of the Box sowie Windows NTFS artige ACL und Windows SID statt Unix uid/gid. Solarish läuft auch perfekt virtualisiert unter ESXi.

Samba ist nicht das Problem, ich bin einfach nur das konfigurieren Leid. Ich möchte gerne mal ein einfach komfortabel eine Freigabe erstellen über WebUI, darum geht es mir.

Was verstehst du unter einem SMB-Server ohne Config-Files? Aber auch irgendein Solaris-Derivat würde mir ja nichts nutzen, wenn ich so oder so kein pass-through der Hard Drives machen kann.

€dit: Weitere Idee: Durchreichen per virtio. Benötigt man dazu VT-d?
 
Zuletzt bearbeitet:
Noch eine Alternative, bei der du deine vorhandene Hardware weiternutzen kannst, auch ohne VT-d und extra SATA Controller:

1) Du installierst ein minimales Debian Wheezy
2) Darauf installierst du Openmediavault (OMV) als NAS-Lösung nach
3) Unter Openmediavault installierst du die OMV-Extra Plugins
4) Jetzt kannst Du komfortabel aus OMV heraus ZFS als Plugin nachinstallieren und hast dann eine bewährte und komfortabel per Web-GUI konfigurierbare NAS-Lösung, die auf Bare-Metal ZFS Storage zugreift. In der OMV Web-GUI kannst du einfach deine ZFS Pools, Datasets und ZVOLS anlegen und verwalten. Für komplexere Aufgaben kannst du natürlich auch die Debian Kommandozeile nutzen, du hast den vollen Funktionsumfang von ZFS on Linux zur Verfügung.
5) Für deine weiteren oben skizzierten Dienste kannst Du dann entweder vorhandene OMV-Plugins nutzen (z. B. pyload, nginx, mysql), oder du installierst das Virtualbox-Plugin für Virtualisierung nach, und/oder du installierst auf der Kommandozeile die Debian-Pakete für Qemu-KVM/libvirt/virt-manager nach und hast damit zusätzlich noch eine mächtige und Hardware-nahe Virtualisierungslösung zur Verfügung.
 
Hyper-V Server kann übrigens einzelne Harddisks direkt durchreichen, ohne VT-d soweit ich weiss.
VirtIO ist ja in der Regel auch (fast) eine Emulierte Hardware. Ich weiss nicht wie die Performance dort wirklich ist.

Dein Vorhaben mit dem Router ist ohne VT-d auch nicht optimal.
Zwar kannst du die benötigten Netzwerkkarten virtuell nach Belieben basteln, jedoch erzeugen diese unnötig viel CPU Last verglichen zu einer echten Netzwerkkarte.
Für zuhause wird's wohl reichen (je nach Traffic), reale Werte habe ich jetzt auch nicht zur Hand.

An deiner Stelle würde ich das ganze mal ausprobieren und die Leistung und den Verbrauch gut beobachten.
Unter ESXi ist Stromsparen sowieso eher schwer und du wirst durch die viele Virtualisierte Hardware auch etwas mehr CPU-Last generieren.

Wenns dann nicht gut läuft, hast du immer noch die Möglichkeit andere Hardware zu kaufen.
 
CPU-Last ist in Zeiten paravirtualisierter Netzwerktreiber (z. B. virtio) absolut kein Thema mehr, der Durchsatz der virtualisierten NICs ist nahe Bare Metal. Hardware-Passthrough von Ethernet-Controllern hat sich praktisch erledigt.

Das "Durchreichen" von HDDs ist auch mit KVM oder vSphere als RAW-Devices möglich, aber für ZFS nicht empfehlenswert, da sich die Caching-Mechanismen von ZFS und Hypervisor/Betriebssystem in die Quere kommen.
 
Zuletzt bearbeitet:
@oelsi

Das klingt gut, freut mich eigentlich dass die letzten Jahre viel gegangen ist. Aber die Bandbreite ist immer noch physikalisch limitiert.
Also vernünftigerweise müssten in so einem Szenario wie hier schon eine gewisse Anzahl physikalischer Netzwerkkarten da sein.

Eine exklusiv für den WAN Traffic zum "Router-OS" (da ist eine physikalische Trennung einfach notwendig) und zwei für die VM's.
Gute Netzwerkkarten teilen die Last in Hardware dann über die Ports auf und erstellen sinnvolle Queues.

Klar, das ganze geht auch ohne VT-d prima.
 
Auch ESXi kann einzelne Platten durchreichen (ohne vt-d), nennt sich physical raw disk mapping.
Die Platte wird dann z.B. per ZFS formatiert aber über den ESXi Controller angesprochen.

Muss man halt per CLI einstellen.
 
Nun, sein P9D-C hat ja schon mal vier Intel GigE-NICs, das ist ein guter Start :)
Davon ab limitiert eher die CPU im (virtualisierten) Router/Firewall den Durchsatz als ein GigE-Interface. Je nach Netztopologie können die Router-Interfaces auch komplett virtuell sein, da limitiert dann nur noch die CPU den Durchsatz, kein physikalisches Interface.
 
Zuletzt bearbeitet:
Samba ist nicht das Problem, ich bin einfach nur das konfigurieren Leid. Ich möchte gerne mal ein einfach komfortabel eine Freigabe erstellen über WebUI, darum geht es mir.

Was verstehst du unter einem SMB-Server ohne Config-Files? Aber auch irgendein Solaris-Derivat würde mir ja nichts nutzen, wenn ich so oder so kein pass-through der Hard Drives machen kann.


Samba wird über ein Textfile konfiguriert und kennt zunächst die Besonderheiten von ZFS nicht. Für Samba sind ZFS Dateisysteme zunächst auch nur einfache Ordner genau wie bei ext4 oder XFS. Man muss Samba alle ZFS Besonderheiten per Konfigurationsfile beibringen.

Bei Solaris ist ein SMB oder NFS Share eine Eigenschaft eines Dateisystems. Es gibt kein Textfile zum Konfigurieren. Man setzt bei dem Dateisystem die Eigenschaft SMB share=on oder off und das wars. Zum Konfigureiren gibts da nichts, Snaps sind dann automatisch "Windows previous versions" und Datei-Rechte sind im Dateisystem als ntfs kompatible nfs4 ACL verankert. Windows share-permissions sind auch nur ACL auf ein Share Control File. In dem Punkt ist Solaris halt einfacher weil ausschliesslich auf ZFS ausgelegt.
 
Noch eine Alternative, bei der du deine vorhandene Hardware weiternutzen kannst, auch ohne VT-d und extra SATA Controller:

1) Du installierst ein minimales Debian Wheezy
2) Darauf installierst du Openmediavault (OMV) als NAS-Lösung nach
3) Unter Openmediavault installierst du die OMV-Extra Plugins
4) Jetzt kannst Du komfortabel aus OMV heraus ZFS als Plugin nachinstallieren und hast dann eine bewährte und komfortabel per Web-GUI konfigurierbare NAS-Lösung, die auf Bare-Metal ZFS Storage zugreift. In der OMV Web-GUI kannst du einfach deine ZFS Pools, Datasets und ZVOLS anlegen und verwalten. Für komplexere Aufgaben kannst du natürlich auch die Debian Kommandozeile nutzen, du hast den vollen Funktionsumfang von ZFS on Linux zur Verfügung.
5) Für deine weiteren oben skizzierten Dienste kannst Du dann entweder vorhandene OMV-Plugins nutzen (z. B. pyload, nginx, mysql), oder du installierst das Virtualbox-Plugin für Virtualisierung nach, und/oder du installierst auf der Kommandozeile die Debian-Pakete für Qemu-KVM/libvirt/virt-manager nach und hast damit zusätzlich noch eine mächtige und Hardware-nahe Virtualisierungslösung zur Verfügung.

Sehr gute Idee, vielen Dank! Du hast ja auch bereits geschrieben das dass durchreichen mit ZFS nicht einwandfrei funktioniert, also sollte ich davon wohl so oder so Abstand halten :)

Was ist von der Option mit ZFS auf Host + virtio für OMV zu halten? Im OMV Forum habe ich gelesen das der ein oder andere das ganz erfolgreich und zufrieden nutzt.

zu Punkt 5) Könnte ich auch Proxmox nachinstallieren oder gibt das irgendwelche Kompatibilitätsprobleme bzw. etwas anderes das dagegen spricht (zuviel Overload oder so?)? Afaik ist ja Proxmox auch einfach nachinstallierbar.
 
Zuletzt bearbeitet:
ZFS sollte entweder Bare-Metal oder, wenn virtualisiert, nur mit dediziertem, per VT-d durchgereichtem Hardware-Controller verwendet werden. Das Problem mit virtio ist, dass der paravirtualisierte Treiber ein eigenen Write-Cache-Management mitbringt, vom dem ZFS in der virtuellen Maschine nichts mitbekommt. ZFS glaubt, es hat erfolgreich die Caches auf Disk geflushed, obwohl in der Realität die Writes noch im Write-Cache des Betriebssystems hängen...

Proxmox nachzuinstallieren wäre mir zu riskant, da Proxmox einen eigenen angepassten Kernel nachinstalliert und schwer vorhersagbar ist, ob OMV damit läuft. KVM hingegen ist Bestandteil des Standard Debian-Kernels.

EDIT: ZFS auf Host und ZVOLS per virtio an OMV-VM könnte wohl klappen, wobei ich nicht weiss, wie da die Performance so ist.
 
Zuletzt bearbeitet:
ZFS sollte entweder Bare-Metal oder, wenn virtualisiert, nur mit dediziertem, per VT-d durchgereichtem Hardware-Controller verwendet werden. Das Problem mit virtio ist, dass der paravirtualisierte Treiber ein eigenen Write-Cache-Management mitbringt, vom dem ZFS in der virtuellen Maschine nichts mitbekommt. ZFS glaubt, es hat erfolgreich die Caches auf Disk geflushed, obwohl in der Realität die Writes noch im Write-Cache des Betriebssystems hängen...

Proxmox nachzuinstallieren wäre mir zu riskant, da Proxmox einen eigenen angepassten Kernel nachinstalliert und schwer vorhersagbar ist, ob OMV damit läuft. KVM hingegen ist Bestandteil des Standard Debian-Kernels.

EDIT: ZFS auf Host und ZVOLS per virtio an OMV-VM könnte wohl klappen, wobei ich nicht weiss, wie da die Performance so ist.

Der Unterschied wäre also ob ich nun die einzelnen Devices (/dev/sda ... /dev/sdz) durchreiche und dann den ZFS Pool erstelle innerhalb des Gastes (was nicht zu empfehlen wäre) oder den Pool im Host erstelle und dann den Pool durchreiche mit /dev/zfspool (oder wie auch immer das heißt) - das wäre okay?

Falls ja, werde ich das mal so testen, insbesondere mit Augenmerk auf Performance!

Danke,

Sebastian
 
Kleine Zwischenmeldung: ZVOL über VirtIO geht nicht. QM verabschiedet sich immer mit "400 parameter verification failed".

Neija, dann doch größere CPU. Danke euch trotzdem für Tipps & Hilfe :-)

- - - Updated - - -

Ich nehme alles zurück! Proxmox ist selbst so intelligent und legt automatisch ZVOLS an über die Web-GUI. Habe es vorher die ganze Zeit selbst über die CLI versucht.
 
Nur ein kurzer Einwand:

Der Hyper-V fällt eher raus, weil ich kein Windows virtualisieren möchte.
Mit Hyper-V kann nicht nur Windows virtualisiert werden, sondern auch Linux/FreeBSD: siehe Technet.
Klappt in der Praxis auch gut, auch wenn man hier und da etwas beachten muss.

Wenn also bereits eine Windows-Infrastruktur vorhanden ist, ist Hyper-V auf jeden Fall eine Überlegung wert.
 
Hardwareluxx setzt keine externen Werbe- und Tracking-Cookies ein. Auf unserer Webseite finden Sie nur noch Cookies nach berechtigtem Interesse (Art. 6 Abs. 1 Satz 1 lit. f DSGVO) oder eigene funktionelle Cookies. Durch die Nutzung unserer Webseite erklären Sie sich damit einverstanden, dass wir diese Cookies setzen. Mehr Informationen und Möglichkeiten zur Einstellung unserer Cookies finden Sie in unserer Datenschutzerklärung.


Zurück
Oben Unten refresh