Could not activate storage 'XXX', zfs error: cannot import 'XXX': no such pool available (500)

[Wikinger85]

Du bist ja zu einer unschönen Zeit wach.

root@Proxmox:~# qm config 100

balloon: 0

boot: order=scsi0;ide2;net0

cores: 4

ide2: none,media=cdrom

kvm: 0

memory: 12288

meta: creation-qemu=6.2.0,ctime=1658016654

name: PlexOMV

net0: virtio=56:D6:4D:2B:67:3F,bridge=vmbr0,firewall=1

numa: 0

ostype: l26

parent: PlexFinal

scsi0: local-lvm:vm-100-disk-0,size=32G

scsi1: /dev/disk/by-id/ata-WDC_WD40EFAX-68JH4N0_WD-WX12D108N8ZL,backup=0,size=3907018584K

scsi2: /dev/disk/by-id/ata-WDC_WD40EFAX-68JH4N0_WD-WX12D108NYS1,backup=0,size=3907018584K

scsihw: virtio-scsi-pci

smbios1: uuid=b5f8d1e4-0c0b-4b30-b60f-729cc586e44f

sockets: 1

vmgenid: cbab3772-f52a-4331-91c2-5aac4fbec46c

root@Proxmox:~#

Habe jetzt noch testweise scsi rausgenommen, da dies noch eine Änderung war, aber hat auch nichts bewirkt.

 

[Neobin]

Du mountest also den ZFS-Pool gleichzeitig sowohl in der OMV-VM, als auch auf dem PVE-Host selbst?
Das führt früher oder später zu Dateisystem-Fehlern, vermutlich genau wie du sie gerade erlebst.
Weder der Host weiß, was die VM gerade mit dem Storage macht, noch weiß die VM, was der Host gerade damit macht.
Sollte man so auf gar keinen Fall machen!

 

[Wikinger85]

Verstehe ich dass (aufgrund meiner offensichtlichen Wissensdefizite) richtig, dass ich den Pool im Proxmox entfernen müsste (unter Storage, dass er in der Proxmox GUI nicht mehr ersichtlich ist), diesen dann aber per Konsole durchreichen müsste?`Befehl dazu

qm set 100 -scsi2 /dev/disk/by-id/ata-WDC_WD40EFAX-68JH4N0_WD-WX12D108NYS1

? Oder bin ich da komplett auf dem falschen Pfad damit?

Gibt es bei LXC dabei keine Probleme? Diese sind ja auch im Proxmox ersichtlich.... Oder war es jetzt Glück, dass mein System seid über 3 Jahren rund läuft bzgl Plex in der VM?

Oder könntest mir da sonst eine Empfehlung geben.

Sorry für mein fehlendes Wissen.

Cheers

 

[Neobin]

Verstehe ich dass (aufgrund meiner offensichtlichen Wissensdefizite) richtig, dass ich den Pool im Proxmox entfernen müsste (unter Storage, dass er in der Proxmox GUI nicht mehr ersichtlich ist), diesen dann aber per Konsole durchreichen müsste?`Befehl dazu

qm set 100 -scsi2 /dev/disk/by-id/ata-WDC_WD40EFAX-68JH4N0_WD-WX12D108NYS1

?

Genau, wenn du die Netzwerk-Shares usw. für die Platte weiterhin über OMV verwalten willst, dann kann man das mit dem Passthrough der kompletten Platte an die VM so machen, aber du müsstest sie aus PVE rausnehmen.
Allerdings kannst du dann auch keine Bind-Mounts o.Ä. mehr mit deinen LXCs auf diese Platte benutzen. Von den LXCs müsstest du dann per Samba- oder NFS-Share auf die Platte zugreifen. Es sei denn, du mountest die Netzwerk-Shares direkt auf dem PVE-Host, dann würden auch wieder die LXC-Bind-Mounts funktionieren. Da müsste aber jemand anderes was zu sagen, wie man das am besten umsetzt, da die OMV-VM, wenn du den Host z.B. neustartest, anfangs ja noch nicht gestartet ist und somit die Shares auch noch nicht da sind. Ich weiß nicht wie gut oder sinnig das funktioniert.
So oder so musst du mit einer Startup-Order und -Delay der OMV-VM arbeiten.

Gibt es bei LXC dabei keine Probleme? Diese sind ja auch im Proxmox ersichtlich....

Das kann jemand anderes sicherlich auch besser erklären, aber LXCs nutzen ja sämtliche Ressourcen des Hosts. Da der Host die volle Kontrolle über den Storage hat (sollte er in dem Fall zumindest) und, im Gegensatz zu einer VM, auch weiß was innerhalb des LXCs vor sich geht, kommt es da zu keinem Problem.

Oder war es jetzt Glück, dass mein System seid über 3 Jahren rund läuft bzgl Plex in der VM?

Die Gefahr, dass etwas korrumpiert, ist sicherlich geringer, wenn nur eines der beiden Systeme hauptsächlich auf die Platte schreibt und das Andere (z.B. Plex) hauptsächlich oder sogar ausschließlich nur von der Platte liest.
Je mehr beide Systeme (umso mehr gleichzeitig) auf die Platte schreiben, umso höher die Chance für korrupte Daten oder gar ein korruptes Dateisystem.
Wundert mich nur, dass das gleichzeitige Mounten überhaupt so lange (scheinbar problemlos?) funktioniert hat.

TL;DR: Platte(n) ausschließlich in die eine OMV-VM durchreichen und nur da mounten. Alles was ausserhalb der OMV-VM Zugriff auf die Daten der Platte(n) haben soll, nur über Netzwerk-Shares.

Vielleicht mag @Dunuin etwas dazu sagen. Er kann das alles wesentlich besser erklären.

 

[Wikinger85]

Danke für Dein Feedback. Ja, Dunuin sein Wissen konnte ich schon anderweitig nutzen, bzw. habe ich dann vlt. dass mit dem Passthrough nicht vollständig korrekt umgesetzt oder es ihm richtig erklärt. Sehe da die Fehler bei mir.

Ich habe das System so aufgesetzt, dass wirklich die Festplatten nur für eine VM/LXC gedacht sind, bzw. 1 Festplatte für 2 LXC, 1 weitere für noch 2 LXC. 2 Festplatten nur für die VM. Aber LXC und VM ist bisher nicht vermischt gewesen. Also diese Anpassung sollte dann machbar sein, sofern es nicht an meiner Inkompetenz scheitert während der Umsetzung . Bzw. korrekterweise muss ich sagen, hatte ich den LXC für Teamspeak auf einen HDD der VM am laufen, was ich aber dank Dunuin mir als Ziel gesetzt habe, dies auch in eine VM zu packen bzw. zu korrigieren. Da waren 90% der HDD für die VM vorgesehen und die restlichen 10% für Apps wie TS.

Bzgl. der fehlenden Probleme vorher muss ich dazu sgen, mit dem Passthrough hatte ich erst vorige Woche umgesetzt, bis dahin hatte ich nur einen Teil der HDD in die VM gepackt und der Folge wenn ich Probleme bei Plex hatte, die Daten weg waren. Dank Dunuins Erklärungen habe ich aber wieder was gelernt, welchen Vorteil der Passthrough mit sich bringt und das nicht alles verloren ist (bereits getestet).

Ich hoffe es ist verständlich was ich hier von mir gebe.

 

[Dunuin]

Wenn du die gleichen Ordner einer physischen Disk zwischen VMs und LXCs teilen willst, dann solltest du die ganze Disk in deine NAS VM durchreichen und nicht auch auf dem Host mounten, da dir wie schon gesagt ein gleichzeitig schreiben die Daten korrumpiert. Willst du dann die Daten von der Disk auf dme Host oder im LXC benutzen, dann solltest du die per SMB/NFS über die NAS VM bereitstellen. PVE Host und unprivilegierte LXCs könnten dann die NFS/SMB Shares mounten und erhalten so indirekt zugriff auf die Daten der Disk. Bei unprivilegierten LXCs wird es etwas komplizierter, da diese wegen fehlenden Rechten bzw wegen erhöhter Isolation keine SMB/NFS Shares mounten dürfen. Hier kann man sich aber behelfen, indem man den NFS/SMB Share auf dem Host mountet und dann per bind-mount in den unprivilegierten LXC bringt.

Sofern sich die LXCs und VMs die Daten nicht teilen sollen könntest du auch 2 Partitionen auf der Disk erstellen. Die eine Partition mountest du dann am Host um sie in LXCs per bind-mount nutzen zu können, die andere Partition könntest du per Disk Passthrough an die VM durchreichen. Wäre dann z.B. qm set 100 -scsi2 /dev/disk/by-id/ata-WDC_WD40EFAX-68JH4N0_WD-WX12D108NYS1-part2 für die zweite PArtition statt qm set 100 -scsi2 /dev/disk/by-id/ata-WDC_WD40EFAX-68JH4N0_WD-WX12D108NYS1 für die ganze Disk. das habe ich aber nur gehört und nicht selbst verifiziert ob es wirklich geht. Aber soll wohl gehen mit Durchreichen von einelnen Partitionen.

Tipp:
Ich persönlich schreibe mir auch gerne die Befehle zum Hinzufügen des Disk Passthroughs in das "Note" Feld der VM. Weil nach einem Restore aus einem Backup sind die Einträge für die druchgereichten Disks nicht mehr da und man muss sie erneut durchreichen. Macht es dann einfacher, wenn einem die Notes der VMs bereits sagen, was man dann nach einem Restore auszuführen hat.

 

[Wikinger85]

Danke schon einmal und sorry für meine späte Antwort. Ich werde versuchen dies schnellstmöglich umzusetzen und würde gern ein Feedback dann da lassen ob es geklappt hat.