VM startet nicht automatisch

[bforpc]

Hallo,

auf einem Proxmox Server soll eine VM beim booten starten. Das System nutzt ZFS als storage (Basis des OS ist Debian auf ext4).
Die Fehlermeldung im Log lautet:

zfs error: cannot open 'store': no such pool
cannot mount 'store/bh/freigaben/homes/julia': mountpoint or dataset is busy
TASK ERROR: could not activate storage 'vm', zfs error: cannot mount 'store/bh/freigaben/cam': mountpoint or dataset is busy

Was mich jetzt wundert:
Der Storge Part "store/bh/freigaben/homes/julia" und "'store/bh/freigaben/cam" haben nichts mit der VM zu tun.
Der 1. Teil Meldung "zfs error: cannot open 'store': no such pool" wäre ein Problem, da der Pool "store" das "Hauptsorage" ist. Andererseits ist dieses "store/" aber nach dem booten des Hostes verfügbar.

bfo

 

[fireon]

Manuell lässt sich die VM nach dem Booten starten? Poste auch bitte die Config der VM + deinen Stores

qm config <vmid>
pvesm status

 

[bforpc]

Ja, die VM lässt sich später sowohl in der Konsole als auch per Web starten.
Das Problem ist offensichtlich, dass das ZFS Dateisystem "noch nicht soweit" ist und deshalb die VM nicht startet. Die VM hat keine spezielle Konfig. Das PVE ist die letzte aktuelle Version.

cat /etc/pve/storage.cfg
dir: local
    path /var/lib/vz
    content vztmpl,iso,snippets
    prune-backups keep-all=1
    shared 0

zfspool: vm
    pool store/proxmox/vm
    content images
    sparse 1

zfspool: lxc
    pool store/proxmox/lxc
    content rootdir
    sparse 1

zfspool: ssd
    pool ssd/proxmox/vm
    content images
    mountpoint /ssd/proxmox/vm
    sparse 1

Bfo

 

[fireon]

Verstehe. Event. hilft dir ein Delay in der Grubconfig: /etc/default/grub (rootdelay=13)

GRUB_CMDLINE_LINUX="root=ZFS=rpool/ROOT/pve-1 boot=zfs rootdelay=13"

Danach ein "update-grub" machen. Teste mal.

 

[bforpc]

Aber mein root fs ist *nicht* ZFS wie ich schrieb, sondern ext4. Das Storage ist ZFS.

Bfo

 

[fireon]

Das weis ich natürlich, wäre viel. trotzdem einen versuch wert. Ansonsten würde ich ein delay in das systemdscript zum Einhängen des Pools ergänzen. Wie das geht, findest du hier: https://deepdoc.at/dokuwiki/doku.php?id=server_und_serverdienste:systemd

 

[fabian]

bitte den kompletten "journalctl -b" output bis zum fehlgeschlagenen start posten..

 

[bforpc]

Das muss dann warten, bis der Fehler wieder auftritt .. Heute hat er sauber gestartet. Melde mich dann halt wieder.

 

[fabian]

du kannst auch mit "-b-X" (X entsprechend durch 1, 2, .. ersetzen) die logs von vorherigen bootvorgaengen auswaehlen

 

[bforpc]

Hallo,
anbei das Log. Dort ist aber auch nichts anderes zu erkennen. Relevant ist dann diese Zeile:
Jul 26 07:33:01 cb3 pvesh[2054]: Starting VM 2165 failed: could not activate storage 'vm', zfs error: cannot mount 'store/sweet/proxmox/lxc/subvol-10>
wobei wir wieder bei meiner ursprünglichen Frage wären: Das Storage "store/sweet/proxmox/lxc/subvol-10" hat nichts mit der VM 2165 zu tun.
Anbei auch die cfg der VM.

cat 2165.conf
boot: order=scsi0;ide2;net0
cores: 4
ide2: none,media=cdrom
memory: 4096
meta: creation-qemu=8.0.2,ctime=1687853708
name: web
net0: virtio=EA:70:59:19:CF:21,bridge=vmbr0,firewall=1
numa: 0
onboot: 1
ostype: l26
scsi0: vm:vm-2165-disk-0,iothread=1,size=32G
scsihw: virtio-scsi-single
smbios1: uuid=5e29f256-40f4-4730-a79c-e9407642cb50
sockets: 1
vmgenid: 134e41ea-a0fe-45e4-995c-e7ee155b031d

Das Image liegt in store/proxmox/vm/vm-2165-disk-0
Hier die storage cfg:

cat storage.cfg
zfspool: vm
    pool store/proxmox/vm
    content images
    mountpoint /store/proxmox/vm
    sparse 1

dir: local
    path /var/lib/vz
    content snippets,vztmpl,iso
    prune-backups keep-all=1
    shared 0

zfspool: lxc
    pool store/proxmox/lxc
    content rootdir
    mountpoint /store/proxmox/lxc
    sparse 1

Bfo

 

[fabian]

der log ist abgeschnitten.. es geht mir um die interaktion/reihenfolge von zfs import/mount services und pve-guests, die ist leider nicht sichtbar (oder sind alle zfs services ausser zfs-zed und zfs-share disabled?)

 

[bforpc]

Zur Erklärung meinerseits: dieser Proxmox Server hat nur eine VM, die dort laufen soll. Das Storage selbst ist aber ein backup eines anderen zfs storages, daher ist auf dem "store" viel mehr drauf. Es ist kein LVM installiert.
Habe jetzt das Log seit "start" des Rechners angefügt.

Grüße aus dem Norden
Bfo

 

[fabian]

meine vermutung ist dass hier zweimal storage aktivierung parallel laeuft.. du koenntest probieren das "zfs-import@store.service" systemd service zu enablen, damit sollten import + mount schon beim boot selbst passieren, und nicht erst durch PVE spaeter..

 

[bforpc]

Das klingt plausibel. Ist auch nur genau an diesem einen Proxmox (wir haben ~25 Proxmox Server mit fast identischer Hardware im Einsatz).
Grundsystem ist wie gesagt Debian. Dieser eine Rechner wurde vor längerem upgedatet. Ob das Problem dann erst auftrat oder vorher schon bestand, kann ich leider nicht sagen.

Der zfs-import.target ist übrigens maskiert und kann nicht verändert werden.

Kannst du vielleicht etwas dazu sagen, wie es zu dieser "doppelten" storage Aktivierung kommen kann und ob ich diese nicht anderweitig korrigieren kann?

Bfo

 

[fabian]

du hast 2x storages die auf denselben pool zeigen (aber auf verschiedene datasets), der pool wird nicht importiert beim boot, der erste zugriff von irgendeinem PVE service wird die storages dann aktivieren. aktivieren heisst

- schauen ob "pool" dataset vom storage schon gemounted ist, falls nicht
- schauen ob schon importiert, falls nicht
- pool importieren
- zfs mount -a

sowohl der import als auch das mount laufen dabei auf den ganzen pool. das ist natuerlich inherent racy (weil verschiedene services oder prozesse das parallel triggern koennen), und eigentlich auch nur als fallback da, wenn der import beim boot aus irgendwelchen gruenden nicht hinhaut..

 

[bforpc]

du hast 2x storages die auf denselben pool zeigen

Wie kommst du darauf?

zfspool: vm
    pool store/proxmox/vm
    content images
    sparse 1

zfspool: ssd
    pool ssd/proxmox/vm
    content images
    mountpoint /ssd/proxmox/vm
    sparse 1

das eine liegt in store/proxmox/vm, das andere im ssd/proxmox/vm - das sind 2 vollkommen getrennte pools, nur dass sich die Pfade nach dem root Verzeichnis ähneln. Das Einzige was mir auffält ist, dass der ssd Store einen mountpoint in der storage.cfg hat und die anderen nicht.

Die obige Storage Konfiguration habe wir zig fach (wirklich) im Einsatz. Da gibts die Probleme nicht (ok, die Booten auch nicht jeden Tag).

Bfo

 

[fabian]

zfspool: lxc
    pool store/proxmox/lxc
    content rootdir
    mountpoint /store/proxmox/lxc
    sparse 1

liegt auch auf dem pool store. aber auch ohne doppelt konfigurierten pool kann es zu races kommen, wenn mehrere services parallel versuchen den storage zu aktivieren.. den zpool beim boot zu importieren funktioniert im normalfall besser - du kannst ja auch nochmal gegenchecken, ob dass auf den anderen systemen nicht vielleicht aktiv ist und deswegen dort funktioniert

 

[bforpc]

Hallo Fabian,

Dazu zwei Fragen:
1.) würde ein fstab Eintrag mit z.B.
store /store zfs defaults 0 0
den Pool beim booten korrekt mounten?

2.) (ein wenig offtopic): Ist das ein Problem, wenn 2x storages auf den selben pool zeigen (aber auf verschiedene datasets)?

Bfo

 

[fabian]

Hallo Fabian,

Dazu zwei Fragen:
1.) würde ein fstab Eintrag mit z.B.
store /store zfs defaults 0 0
den Pool beim booten korrekt mounten?

nein. wie weiter oben beschrieben - die import services sorgen dafuer dass pools importiert werden (gibt drei varianten - cache file, scan, oder explizit nur ein bestimmter pool). solange sie vor dem zfs-mount service gestartet worden sind, sollten die datasets dieser pools dann auch schon automatisch gemounted sein.

2.) (ein wenig offtopic): Ist das ein Problem, wenn 2x storages auf den selben pool zeigen (aber auf verschiedene datasets)?

nein, abgesehen vom speziellen fall von pool noch nicht importiert, parallele storage activation dann schlaegt aber auch nur einmal ein activate fehl..

 

[bforpc]

Danke für die Klarstellung.

Da ich wenig Einfluss auf die import Services habe (oder nicht wüsste, wie ich diese für meine Zwecke anpassen sollte), habe ich jetzt einfach einen Eintrag erstellt, welcher beim booten ausgeführt wird:
"echo "/usr/sbin/qm start 2165"|at now + 2 min"

Bfo