Software Raid auf Host oder in VM ?

So, ich hab mal etwas getestet...

Als Test Raid 5x 2TB WD Red Festplatten an einem SAS3 HBA im Host.
Auf dem Server läuft eine Win11 Test vm, von der aus via Netzlaufwerk auf diese
Festplatte zugegriffen wird. Eine knapp 10GB Große Datei speichere ich vom Win PC
auf das Netzlaufwerk.

1. Test, durchreichen aller 5 Laufwerke an die openmediafault vm
Innerhalb der vm md Software Raid5 als Datenspeicher
Unbenannt-1.jpg

2. Test md Software Raid5 auf dem Host und das md Device als Festplatte an die
openmediafault vm durchgereicht

Hier ist das Bild quasi identisch, ABER mit mehr als 100MB/s weniger Datendurchsatz....
Also nach Cache etc, ca 240MB/s im Schnitt

Krass, hätte ich so nicht gedacht...

Aber, leider hat sich mein Verdacht mehr als bestätigt....
Der Host erstellt immer wieder automatisch das md device.
Heißt, host UND vm erstellen das selbe md device.
Das ist natürlich misst....

Ich würde gerne die Variante nutzen, in der alle Disks in die VM durchgereicht werden.
Dann müssen diese Festplatten (und das Software Raid) aber auf dem Host gesperrt sein.
Die Frage ist, wie man das umsetzen kann.
Ich dachte bisher eigentlich, dass, wenn ich eine Festplatte an die vm Übergebe, ist sie für den Host tabu.
Aber sie ist noch genauso verfügbar. Auch smartctl wird wohl zugriff auf die Festplatte haben, obwohl sie
in der vm aktiv ist.

Kenn jemand denn Mechanismen, wie man das auf dem Host effektiv sperren/blocken kann ?

Bzgl. Raid mit homehost, das hatte noch keinen passenden Erfolg.
Ich hatte das md Device auf dem Host gestoppt, bevor ich die vm (mit durchgereichten Platten)
gestartet habe. Ergebnis, in der vm wurde das md erstellt/aktiviert UND auf dem Host war es auch wieder aktiv....

Ich würde mich über ein paar Ideen freuen.

Grüße,
MrWeb
 
lösche mal alle Partitionen deiner Test HDDs mit wipefs -a /dev/diskX und zusätzlich mit dd if=/dev/zero of=/dev/diskX bs=1M count= 2048 status=progress
Ich denke da sind noch Reste übrig geblieben.
Des weiteren beende den mdadm Dienst auf dem Proxmox VE Host.
 
Hi news,
das verstehe ich gerade nicht so ganz. was meinst du mit Reste ?

Auf den Disks ist ein raid 5 mdadm array. Das soll ja auch drauf bleiben.
Es soll nur auf dem host nicht automatisch (bzw. eben gar nicht) gestartet/aktiviert werden.
Sobald auf den Platten, auch wenn ich diese jetzt wipe und das raid5 array neu erstelle, ein mdadm raid
drauf ist, wird das debian host os das sehen und das raid starten. (ebenso dann innerhalb der vm).
Ich muss den host irgendwie dazu bringen, das mdraid nicht zu starten, dauerhaft und sicher.
 
Normalerweise ist mdadm auch kein Bestandteil der pve Installation mehr und wenn du ansonsten auf dem Host kein md raid verwendest, kannst du mdadm auch deinstallieren, was definitiv dazu führt, daß der Host das Array nicht starten kann.
 
Doch, brauche ich schon, aber ich muss zumindest separieren können oder bestimmte Raids raus nehmen können...
 
Bzgl. Raid mit homehost, das hatte noch keinen passenden Erfolg.
Ich hatte das md Device auf dem Host gestoppt, bevor ich die vm (mit durchgereichten Platten)
gestartet habe. Ergebnis, in der vm wurde das md erstellt/aktiviert UND auf dem Host war es auch wieder aktiv....
Und deine "vm" ist auch eine echte VM und kein LXC, oder ?
 
Wenn du noch einen PCI-E Slot frei hast, kannst du extra für den Zweck einen weiteren HBA in die VM reinreichen. Wie man die PCI-ID dann für den Host verbirgt, weiß ich, aber meist braucht es das nicht...für die kurze Zeit, bis die VM dann oben ist.
Aber wahrscheinlich hilft auch das nicht mit dem mdraid.
 
Hallo mr44er, das würde schon helfen. Wenn via HBA die Platten dann ja NUR noch in der vm sichtbar sind, weiß der Host nichts davon und kann auch nicht darauf zugreifen. Hilft mir aber nicht, alle Slots sind belegt.... HBA, 4fach GPU und im Rest sitzen NVMe's ...

Bei Debian wird da wohl einiges bzgl mdadm via udev Regeln gemacht, vlt kann ich da was ändern.
Wie macht ihr denn das alle ? Mal unabhängig vom mdadm... Nutzt ihr auch in den VM's dann nur zfs oder... ?
Aber auch dann, sind die /dev/sdx devices ja im Host, ich sag jetzt mal aktiv.
Bspw. der Smart Status im Proxmox ist für alle Festplatten gegeben, auch für die, die eigentlich in einer vm durchgereicht sind.
Da sollte der Host eigentlich ja gar nichts mehr mit den Platten machen. Hm.
 
Wie macht ihr denn das alle ?
Ich hab eine vanilla FreeBSD-VM, in die reiche ich einen HBA komplett rein und damit auch alle Platten, die daran hängen.
Ja, das ist auch ZFS und der pool wird nur in der VM automatisch importiert. Die gesamte Verwaltung darauf mache ich in dieser VM, so auch SMART.

Proxmox sieht zwar den HBA und die Platten, wenn die VM aus ist, aber sie sind verschlüsselt. Proxmox könnte sie gar nicht lesen. Wenn du das unverschlüsselt machst, könnte Proxmox zwar den Pool importieren, aber ZFS importiert nicht automatisch den pool, wenn es eine andere Maschine ist, die den Pool zuletzt importiert hatte. Will man es doch, müsste man das manuell erst forcieren.

Wenn die VM gestartet ist, ist der HBA vom Host weg und die Platten dann ebenfalls.
 
Last edited:
Ok, verstehe. Dann muss aber die Hardware halt erstmal zur Verfügung stehen.
Für eine VM einen kompletten X8 Slot zu 'opfern' ist schon recht viel...
Ein X8 Slot, könnte zwei NVMe's voll anbinden...
Ich werde noch ein wenig testen, da gibt es wohl einige echt schlecht dokumentierte Option für die mdadm.conf.
Mein Problem an sich ist, die Platten/SSD's sitzen in einer 24fach Backplane, die via 2xSAS3 am HBA angebunden ist.
Da auf der Backplane ein Expander ist, kann ich da nichts trennen. Im alten (jetzigen) Gehäuse mit SAS2 Backplane,
sind alle Schächte quasi enzeln auf SFF8047 Buchsen geführt. Da hätte man das trennen können.

Auf jeden fall danke für eure Antworten.
 
Also, für das Problem, dass der Host bereits das mdadm Array startet...

In der /etc/mdadm/mdadm.conf

am Ende alle vorhandenen Raids (via --scan) erstellen lassen.
Danach vor der Array Liste ein
AUTO -all
hinzufügen und die Array's, die NICHT vom Host verwendet werden sollen mit einem
#
auskommentieren.
Danach ein
update-initramfs -u all

Danach werden die auskommentierten array's im host nicht mehr gestartet.

Soweit zu diesem Problem, falls noch jemand nach der Lösung sucht.

Ich habe mich in der Zwischenzeit aber auch 'wieder' mit ZFS beschäftigt,
und zudem habe ich TrueNAS Scale gefunden. Das kannte ich noch nicht.
Da ich ja Debian User bin und Scale eben nun auf Debian basiert war das
ein Grund sich das mal anzusehen (anstatt wie geplant OpenMediaFault).
Gefällt mir soweit sehr gut, ich nutze natürlich nur die NAS Funktionen,
keine Container, keine VM's innerhalb von Scale.

Aber auch hier nun die Frage in die ZFS Experten...
Ich reiche die Platten an die TrueNAS VM durch
(den HBA kann ich ja nicht durch reichen,
da da via Backplane alle Disks dran hängen, eben auch welche, die nicht ins NAS kommen)
Wie ist das mit ZFS auf Host (Proxmox) und innerhalb der VM.
Also gleiches Problem wie bei mdadm.
Wie stellt man sicher, dass proxmox die ZFS Disks nicht aktiviert/nutzt, die an die TrueNAS VM gehen sollen ?
Da gab es wohl einige die sich ihre Daten zerschossen haben...

Grüße,
MrWeb
 
  • Like
Reactions: waltar
Wie stellt man sicher, dass proxmox die ZFS Disks nicht aktiviert/nutzt, die an die TrueNAS VM gehen sollen ?
ZFS importiert nicht automatisch den pool, wenn es eine andere Maschine ist, die den Pool zuletzt importiert hatte. Will man es doch, müsste man das manuell erst forcieren.

Du bekommst Datenverlust, wenn du einen Pool gleichzeitig auf zwei Maschinen importierst. Man müsste also mit Zwang (zpool import -f pool) importieren wollen und das Sicherheitsfeature multihost exakt dazu händisch aktiviert haben.

Sprich, du importierst den pool einfach nicht auf dem Host und du fasst niemals das feature multihostan. Das ist nur für multipathing gedacht.
 
Last edited:
  • Like
Reactions: Johannes S
Ok, danke mr44er für die Info.
Ich hatte das oben in deinem Post schon gelesen.
Nur war ich etwas verwundert, dass ich im Netz öfter mal auf die Info gestoßen bin,
dass da Leute ihre Daten verloren haben.
Wenn man das bewusst selbst initiieren muss, dann ist das ja schon etwas.... hm...
Ok, solange das safe ist, wenn man das nicht tut passt das ja eigentlich.

Dann noch eine Frage,
wie macht ihr dass bzgl. Log ssd/nvme ? Nutzt ihr eine wenn ja,
wie macht ihr den mirror ? auf Host Seite, oder innerhalb der vm ?
Welche Art von mirror ? Softwate Raid etc.. ?
Gleiches für L2ARC, da ja ohne mirror, aber halt möglichst schnell...
Eigene NVE durch reichen, oder.... ?
Wenn ich auf dem Host ja die virtuellen disks als NVMe im Raid habe,
würde es ja eigentlich reichen da eine zusätzliche Platte zu erstellen und an die VM zu geben.
Oder eben gleich zwei, eine für's Log und eine für's L2ARC,
Der Mirror schadet ja nicht und wenn es minimal langsamer ist, fällt das eig. nicht wirklich auf.
Oder nutzt ihr keine eigenen Disk's für Log und L2Arc.
Ich bin auf eure Erfahrungen gespannt....
 
Nur war ich etwas verwundert, dass ich im Netz öfter mal auf die Info gestoßen bin,
dass da Leute ihre Daten verloren haben.
Meist ist das so, dass Leute "irgendwas mit ZFS ist das Allheilmittel" gegen Datenverlust lesen und das dann einfach halbherzig einrichten ohne irgendwas verstanden zu haben. Natürlich ist man dann zu geizig, um mehr als raidz1 zu fahren, weil "kostet ja Speicherplatz". Das rächt sich halt irgendwann, Platten sind nunmal sterbendes Verbrauchsmaterial und dagegen hilft kein "allerbestestes Dateisystem der Welt". :p

Oder nutzt ihr keine eigenen Disk's für Log und L2Arc.
Dies. Ich nutze das nicht für meine Datenhalde. Einerseits weil ich auf den Platten eh den write cache deaktiviert habe und zweitens weil das früher einen SPOF dargestellt hat. (da gabs auch Datenverlust)
Heute ist das nicht mehr so, aber ich hab das selbst noch nicht mit eigenen Augen gesehen. Auf der anderen Seite hab ich bisher noch keine Probleme zur Performance gehabt...du musst ja mit mehr als Gbit draufnageln, damit das in einen Flaschenhals läuft.
Klar, Ordner mit vielen Dateien öffnen ginge vielleicht einige Sekündchen schneller mit gecacheten Metadaten, aber bisher ging das problemlos so und war zumindest für mich nicht genug Rechtfertigung für L2ARC. Außerdem ist "L1"ARC, also RAM immer zu bevorzugen.
 
Last edited:
  • Like
Reactions: Johannes S and UdoB
Wenn man das bewusst selbst initiieren muss, dann ist das ja schon etwas.... hm...
Ok, solange das safe ist, wenn man das nicht tut passt das ja eigentlich.
Wir reden da aneinander vorbei, glaube ich. :D
Du reichst einfach die Platten in deine VM wie du das haben willst. In der VM richtest du den pool mit diesen Platten ein. Der pool ist dann in der VM automatisch "importiert" und wird es so auch wieder, wenn du die VM neu startest.
Solange du nichts auf dem Host mit diesen Platten machst, passiert auch dort nichts. Um Schaden anzurichten, müsstest du proaktiv auf dem Host irgendwas machen. Besagtes Zwangsimportieren z.B. und das machst du einfach nicht (es würde nicht funktionieren solange die VM läuft, da greift multihost off).
Ist die VM aus, und du machst zpool import poolauf dem Host, meckert er dich an, dass das nicht die Maschine ist, wo zuletzt importiert wurde. Du müsstest jetzt zpool import -f pool machen, um auf dem Host importieren zu können. Das ginge sogar und bedeutet kein Datenverlust. Aber das willst du nicht und das passiert auch nicht automatisch.
 
Meist ist das so, dass Leute "irgendwas mit ZFS ist das Allheilmittel" gegen Datenverlust lesen und das dann einfach halbherzig einrichten ohne irgendwas verstanden zu haben. Natürlich ist man dann zu geizig, um mehr als raidz1 zu fahren, weil "kostet ja Speicherplatz". Das rächt sich halt irgendwann, Platten sind nunmal sterbendes Verbrauchsmaterial und dagegen hilft kein "allerbestestes Dateisystem der Welt". :p


Dies. Ich nutze das nicht für meine Datenhalde. Einerseits weil ich auf den Platten eh den write cache deaktiviert habe und zweitens weil das früher einen SPOF dargestellt hat. (da gabs auch Datenverlust)
Heute ist das nicht mehr so, aber ich hab das selbst noch nicht mit eigenen Augen gesehen. Auf der anderen Seite hab ich bisher noch keine Probleme zur Performance gehabt...du musst ja mit mehr als Gbit draufnageln, damit das in einen Flaschenhals läuft.
Klar, Ordner mit vielen Dateien öffnen ginge vielleicht einige Sekündchen schneller mit gecacheten Metadaten, aber bisher ging das problemlos so und war zumindest für mich nicht genug Rechtfertigung für L2ARC. Außerdem ist "L1"ARC, also RAM immer zu bevorzugen.
Ok, und den Schreibcache nutzt du auch nicht ?
Wieso hast du den zudem auf deinen Festplatten deaktiviert ?
 
Wir reden da aneinander vorbei, glaube ich. :D
Du reichst einfach die Platten in deine VM wie du das haben willst. In der VM richtest du den pool mit diesen Platten ein. Der pool ist dann in der VM automatisch "importiert" und wird es so auch wieder, wenn du die VM neu startest.
Solange du nichts auf dem Host mit diesen Platten machst, passiert auch dort nichts. Um Schaden anzurichten, müsstest du proaktiv auf dem Host irgendwas machen. Besagtes Zwangsimportieren z.B. und das machst du einfach nicht (es würde nicht funktionieren solange die VM läuft, da greift multihost off).
Ist die VM aus, und du machst zpool import poolauf dem Host, meckert er dich an, dass das nicht die Maschine ist, wo zuletzt importiert wurde. Du müsstest jetzt zpool import -f pool machen, um auf dem Host importieren zu können. Das ginge sogar und bedeutet kein Datenverlust. Aber das willst du nicht und das passiert auch nicht automatisch.
Sorry, nein, da habe ich dich richtig verstanden meine Antwort nur etwas doof formuliert.
Ich meinte das auf Seite des Hosts...
Sollte quasi heißen:
Wenn man das bewusst selbst initiieren muss, dann ist das ja schon etwas doof, wenn man das tut ...
Soweit sollte man eigentlich denken können, dass, vollkommen egal welche Festplatten/Raid oder Dateisystem
genutzt wird, dass man das nicht zweimal mounten sollte... (Jetzt von Netzwerk Dateisystemen wie NFS etc. natürlich abgesehen !)
 
Ok, und den Schreibcache nutzt du auch nicht ?
Wieso hast du den zudem auf deinen Festplatten deaktiviert ?
Weil das ein kleiner Schutz gegen Stromausfälle ist. Das ACK gibts erst, wenn der Kram auch wirklich weggeschrieben ist.
Ich habe daheim keine USVs mehr, die Arbeit und Kosten mit Überprüfung etc. ist es mir nicht mehr wert, zumal hier in der Gegend in den letzten 5 Jahren nur zwei Ausfälle waren. Klar ist das ein wenig langsamer, aber lieber damit "bezahlen", als den großen Zirkus mit USVs.

Wenn man das bewusst selbst initiieren muss, dann ist das ja schon etwas doof, wenn man das tut ...
Jep

Soweit sollte man eigentlich denken können, dass, vollkommen egal welche Festplatten/Raid oder Dateisystem
genutzt wird, dass man das nicht zweimal mounten sollte.
Da draußen gibts halt Leute, die machen einfach mal drauf los und dann knirscht/weint es plötzlich. ;)
 
  • Like
Reactions: Johannes S