Storageverwaltung über VM oder Host

[fireburner]

Hallo Zusammen,

da ich auf meinem Host so wenig wie möglich Services laufen haben möchte, stellt sich mir die Frage, ob ich den Samba Server wie die anderen Services in eine VM auslagern soll, oder auf dem Host laufen lassen soll?.
Der Host ist ein Debian 9 mit XEN oder QEMU+KVM Hypervisor.
Als Storage kommt ein stripped mirror (RAID10) mit ZFS zum Einsatz.

Ich könnte jetzt entweder das ZFS am Host einrichten, dann den Pool oder Subpools an die VM weiterreichen?? und den Samba Server im Guest laufen lassen, oder die Platten direkt an den Guest weitergeben und ZFS + Samba im Guest laufen zu lassen.

Die Alternative wäre ZFS + Samba am Host einzurichten.

Ersteres hätte den Vorteil, das jeder Service seine eigene VM hätte und der Host außer dem Hypervisor und ssh nichts kaufen hat und somit möglichst wenig Angriffspunkte aus sicherheitstechnischen Überlegungen. Allerdings wird es vermutlich kompliziert, sofern ich nicht die raw Disks an die VM gebe.

Zweiteres wäre einfacher zu realisieren, allerdings wäre die Storageverwaltung dann eben nicht mehr ein eigener abgekapselter Service.
Ich mag das Konzept von 1 VM pro Service.

Danke schonmal für eure Hilfe.

[NAB]

ZFS im Guest? Das habe ich noch nie gehört. Mich würde erst mal dringend interessieren, wie zuverlässig ECC-Speicher-Fehler überhaupt vom Host an den Guest weitergereicht werden, das weiß ich nämlich nicht. Überhaupt würde ich mal nach Beispielen suchen, wo Leute "ZSF im Guest" schon ernsthaft und unter Last betrieben haben. Wenn du keine findest, möchtest du vielleicht nicht der erste sein, der die Bugs findet.

Und Sicherheit? Welche Angriffsszenarien siehst du, wenn ZFS auf dem Host läuft?

Wo du Samba parkst, ist ja nun eine andere Frage. KVM kann auch Dateisysteme durchreichen - auch read-only. Und wenn Samba eh Schreibzugriff auf den vollen ZFS-Pool hat und du Sicherheitsbedenken hast ... dann brauchst du eher eine gute Backup-Strategie statt möglichst vieler VMs.

[MSfree]

ZFS im Guest? Das habe ich noch nie gehört. Mich würde erst mal dringend interessieren, wie zuverlässig ECC-Speicher-Fehler überhaupt vom Host an den Guest weitergereicht werden

Gar nicht, das ist auch nicht Sinn des Sache.

ECC steht für Error Correcting Code. Jeder RAM-Riegel hat sozusagen ein RAID aus RAM-Chips auf seinem Riegel und einen eigenen Controller, der RAM-Fehelr selbst korrigiert. Mit anderen Worten, weder das Hostbetriebssystem noch das Gastbetriebssystem bekommen überhaupt mit, daß da ein Speicherfehler war.

OK, das ist nicht vollständig richtig, denn der Controller auf dem RAM-Riegel löst noch einen Interrupt aus, um der Software mitzuteilen, wenn ein Fehler nicht korrigiert werden konnte. Aber dann hast du sowieso ein Problem, um das du dich kümmern mußt. Denn nicht korrigierbare RAM-Fehler wirken sich letztlch eben genauso aus, sie sind nicht korrigierbar, auch nicht vom Betriebssystem.

[bluestar]

Der Host ist ein Debian 9 mit XEN oder QEMU+KVM Hypervisor.

Wenn du QEMU+KVM als Hypervisor einsetzt, dann könntest du auch noch parallel ohne all zu großen Aufwand LXC für Container laufen lassen...

Ich könnte jetzt entweder das ZFS am Host einrichten, dann den Pool oder Subpools an die VM weiterreichen??

Wenn du auf LXC setzt, dann kannst du einfach ein ZFS Dateisystem an den Samba-Container weiterreichen, so sparst du dir doppelte Dateisysteme und der Speicherplatz lässt sich leichter vom Host aus verwalten.

... ZFS + Samba im Guest laufen zu lassen.

Davon würde ich dir auch dringend abraten.

[NAB]

OK, das ist nicht vollständig richtig, denn der Controller auf dem RAM-Riegel löst noch einen Interrupt aus, um der Software mitzuteilen, wenn ein Fehler nicht korrigiert werden konnte. Aber dann hast du sowieso ein Problem, um das du dich kümmern mußt. Denn nicht korrigierbare RAM-Fehler wirken sich letztlch eben genauso aus, sie sind nicht korrigierbar, auch nicht vom Betriebssystem.

Richtig. Genau das bezeichnet man als ECC-Fehler.

Wenn die jetzt also "gar nicht" an den Guest weitergemeldet werden, wie du ohne Quellenangabe behauptest, dann kriegt das ZFS davon nichts mit und schreibt fröhlich vermeintlich korrigierten Datenmüll auf die Platten. Dann hat man den gleichen Zustand wie ohne ECC-Speicher.

[fireburner]

Die Sicherheitsüberlegungen bezogen sich einzig auf Samba (nicht auf ZFS).
Klar ist der Storagepool beim Angriff auf Samba "verloren". Wenn Samba aber dazu noch auf dem Host läuft ist dieser samt allen VMs bedroht. Aber gut Samba läuft ja nicht als Root, von daher ist da dann nochmal eine große Hürde.

Also werde ich auf jeden Fall ZFS am Host verwalten und für Samba schaue ich mir mal an, we gut der ZFS Poll/Teilpool an QEMU oder LXC Guests weitergeben werden kann.

Das ganze sind indes nur theoretische Überlegungen zum Thema Sicherheit, da ich nicht konkret von Angriffen in meinen Heimnetzwerk ausgehe. Samba wird auch nicht ins WAN freigegeben. Ein Zugriff von Außen wird nur über den VPN Server möglich sein.

[NAB]

Also werde ich auf jeden Fall ZFS am Host verwalten und für Samba schaue ich mir mal an, we gut der ZFS Poll/Teilpool an QEMU oder LXC Guests weitergeben werden kann.

Wie bescheuert ist eigentlich diese Idee, die mir gerade durch den Kopf geht?

Der Host exportiert Dateisysteme, oder teile davon, per (lokalem) NFS - das kann man sich mit bind mounts und ACLs ja sehr detailliert einrichten.
Der Guest importiert das NFS und stellt es Samba zur Verfügung.

Vorteile: das ZFS bleibt komplett unter der Fuchtel des Hosts, inklusive Snapshots, Benutzerverwaltung und ACLs. Die Backup-Strategie kann einfach auf dem Host stattfinden. Auch wenn der gesamte Guest zum "Angriff" übergeht, greifen immer noch die Kontrollmechanismen des Hosts. Man könnte sogar noch den Netzwerkverkehr loggen und analysieren.

Nachteile: vermutlich wird es langsamer. Aber wenn der Ausgang eh nur aus einem GBit-LAN besteht, sollte das bei einem Raid10 nicht stören. Und der Guest weiß, wo die IP-Adresse des Hosts wohnt.