Genau das ist das Problem. Unter Storages kannst du ja deine Mountpoints hinzufügen, aber da die ZFS Kommandos im Hintergrund mit dem richtigen ZFS-Pool Namen arbeiten müssen, ist dieser Name hinterlegt, damit die Replikation auch funktioniert.
Also dass es eine Änderung / Verbesserung ist, habe ich ja gesagt. Also ist klar, dass man dafür Code ändern muss.
Da gibt es glaube ich auch schon einen Request für, einfach mal mit anhängen und Druck machen.Btw. hätte ja auch noch gerne einen Button oder pulldown Menü für Node Maintenance Mode im Web-UI ...
Wir schon. Zudem kann man einen zpool erstellen, ohne irgendwelche zvols oder datasets anzulegen, anschliessend kann man beliebig viele Dir's und Files direkt im poll ablegen, man hat also auch mit zfs einen default Filesystem overhead, der auch bekanntermaßen deiutlich größer als bei nicht zfs Systemen ist, weil es ja u.a. die checksumm erzeugen und zusätzlich schreiben wie auch lesen und verwalten muß.
Wenn es so schön einfach wäre würde es nicht diese vielen Space und Container restore und und und Probleme mit block storage geben, der zumindest für zfs will mal sagen immer noch einfacher als bei lvm ist, aber auf keinstenfalls so einfach wie Filestorage, womit sich jeder auskennt der einen Windows, MAC oder Linux Rechner hat/betreibt. Migration von vm/lxc von einem in anderen NIcht_cluster Host ist ein scp oder mit nfs ein. Ein lxc restore kann bei uns rein technisch niemals ein Größenproblem beim restore von einem snapshot oder vom backup haben. Wir haben auch prinzipbedingt keine lxc mount sicher- oder nicht-sichern Probleme. - das ist einfach !!
Kann meinerseits auch gerne so bleiben wie es ist, wenn denn einfach alle Möglichkeiten wie derzeit gegeben, also freie Wahl der Storage Einbindung, auch weiterhin geben sind.
Naja hier wirfst du einiges durcheinander, Klar kannst du in dem Dataset (nicht dem Pool) schön Dateien ablegen, aber wozu wenn man nur VMs betreibt?
Welche Probleme meinst du? Block macht in der Regel deutlich weniger Probleme, außer man kommt mit der gewohnten Dateisystem Denke und psilt das System kaputt, weil man sich nicht mit der Technik auseinandersetzt. Ich habe noch nie ernsthafte Probleme mit Block storage gesehen.
Klar ist das einfach wenn man gewohnte Tools benutzen möchte und im Homebereicht ist das eventuell auch besserr so. Ich betreue eigentlich fast nur Enterprise Kunden und da gibts in der Regel auch keine LXC und Migrationen sind mit block storage oft noch einfacher als kopieren per scp.
Du hast ja alle Möglichkeiten, nur nicht alles in der GUI. Sonst ist die GUI wieder komplett überladen wie bei anderen Projekten.
Ich will nichts durcheinander werfen, man legt dort ja auch nichts an !!), es geht nur um die Aussage "da ist nix mit overhead" im pool mit Bsp,
Dann lies mal die endlosen threads bzgl. block storage, egal ob zfs oder lvm, dann weißt du was ich meine.
Genau, ist mir teilweise jetzt schon zuviel ..., aber kann damit leben so einiges nicht zu drücken
Klar bringt ein Dataset Overhead mit. Deshalb nutzen wir ja nur das Pooling. Liegt in der Natur der Sache, dass ein Dateisystem auch overhead erzeugt.
Klar lese ich immer wieder wie Leute zuhause aus Unwissenheit ihr Storage kaputt basteln. So lernt man auch ganz viel, aber im Enterprise Bereich wo man weniger bastelt und eher mal jemand mit Ahnung fragt oder ein Support Ticket aufmacht, gibt es die Probleme gar nicht.
Und lernen schadet auch nicht, zumal wenn es wie mit Proxmox soviel Spaß macht !!
Ohne Dataset bekommst du keine Dateien abgelegt. In einen Blockpool kannst du nun mal keine Dateien ablegen, dafür brauchst du ein Dataset.OHNE dataset ... OHNE !!!
Und lvm ist beileibe nicht einfach, zfs macht es recht einfach, ist aber für viele immer noch zu abstrakt, der Mensch denkt halt "zum Anfassen" und das sind halt Files und Dir's ...
