Alle LXC (ZFS) Container starten nicht nach Update, FS leer.

[JohnD]

Hallo zusammen,

ich hab gerade eine meiner Maschinen auf Proxmox 6 geupdated. Es lief alles gut durch und die KVM Maschinen starten brav.

Die LXC Container hingegen starten nicht:

lxc-start -n 105
lxc-start: 105: lxccontainer.c: wait_on_daemonized_start: 856 No such file or directory - Failed to receive the container state
lxc-start: 105: tools/lxc_start.c: main: 330 The container failed to start
lxc-start: 105: tools/lxc_start.c: main: 333 To get more details, run the container in foreground mode
lxc-start: 105: tools/lxc_start.c: main: 336 Additional information can be obtained by setting the --logfile and --logpriority options

Wenn ich die Volumes manuell mounte sind sie bist auf den Ordner dev leer.
ZFS zeigt mir aber an, dass da jede Menge Platz belegt ist.

 zfs list 
NAME                         USED  AVAIL     REFER  MOUNTPOINT
nvme1                        263G   597G       96K  /nvme1
nvme1/subvol-101-disk-0     55.6G  44.4G     55.6G  /nvme1/subvol-101-disk-0
nvme1/subvol-102-disk-0     5.53G  2.47G     5.53G  /nvme1/subvol-102-disk-0
nvme1/subvol-103-disk-0     3.08G  60.9G     3.08G  /nvme1/subvol-103-disk-0
nvme1/subvol-105-disk-0     54.4G   138G     54.4G  /nvme1/subvol-105-disk-0

Habt ihr irgendeine Idee wie ich die wieder zum Leben erwecke?

Vielen Dank.

 

[Stoiko Ivanov]

poste bitte deine '/etc/pve/storage.cfg'
und den output von `systemctl status -l zfs*`
sieh auch im journal nach ob es potentiell probleme beim pool-import gab

danke

 

[JohnD]

Hi,

danke für deine Antwort.
Ich hab jetzt die Ordner /nvme1/subvol*/dev manuell gelöscht, danach zfs unmount /nvme1/subvol* (also für jedes subvolume) und danach wieder mit zfs mount eingebunden.
Nun geht alles wieder.

Ich nehme an, dass Proxmox 6 wieso auch immer dev einbindet bevor die volumes gemountet wurden.

 

[Stoiko Ivanov]

Das könnte bei jedem boot passieren ( wir kennen den fall, wenn ein directory storage auf einem ZFS-pool angelegt wird ohne die passenden Optionen zu setzen) - deswegen die Frage nach der storage.cfg und dem journal output.

 

[JohnD]

Das wäre natürlich doof.

Journal:

systemctl status -l zfs*
● zfs-import.target - ZFS pool import target
   Loaded: loaded (/lib/systemd/system/zfs-import.target; enabled; vendor preset: enabled)
   Active: active since Fri 2019-08-09 12:42:50 CEST; 1h 47min ago

Aug 09 12:42:50 prox15 systemd[1]: Reached target ZFS pool import target.

● zfs-mount.service - Mount ZFS filesystems
   Loaded: loaded (/lib/systemd/system/zfs-mount.service; enabled; vendor preset: enabled)
   Active: failed (Result: exit-code) since Fri 2019-08-09 12:42:50 CEST; 1h 47min ago
     Docs: man:zfs(8)
  Process: 8649 ExecStart=/sbin/zfs mount -a (code=exited, status=1/FAILURE)
 Main PID: 8649 (code=exited, status=1/FAILURE)

Aug 09 12:42:50 prox15 systemd[1]: Starting Mount ZFS filesystems...
Aug 09 12:42:50 prox15 zfs[8649]: cannot mount '/nvme1': directory is not empty
Aug 09 12:42:50 prox15 systemd[1]: zfs-mount.service: Main process exited, code=exited, status=1/FAILURE
Aug 09 12:42:50 prox15 systemd[1]: zfs-mount.service: Failed with result 'exit-code'.
Aug 09 12:42:50 prox15 systemd[1]: Failed to start Mount ZFS filesystems.

● zfs-zed.service - ZFS Event Daemon (zed)
   Loaded: loaded (/lib/systemd/system/zfs-zed.service; enabled; vendor preset: enabled)
   Active: active (running) since Fri 2019-08-09 12:42:50 CEST; 1h 47min ago
     Docs: man:zed(8)
 Main PID: 8918 (zed)
    Tasks: 3 (limit: 4915)
   Memory: 3.5M
   CGroup: /system.slice/zfs-zed.service
           └─8918 /usr/sbin/zed -F

Aug 09 12:42:50 prox15 systemd[1]: Started ZFS Event Daemon (zed).
Aug 09 12:42:51 prox15 zed[8918]: ZFS Event Daemon 0.8.1-pve1 (PID 8918)
Aug 09 12:42:51 prox15 zed[8918]: Processing events since eid=0

● zfs-share.service - ZFS file system shares
   Loaded: loaded (/lib/systemd/system/zfs-share.service; enabled; vendor preset: enabled)
   Active: active (exited) since Fri 2019-08-09 12:42:50 CEST; 1h 47min ago
     Docs: man:zfs(8)
  Process: 8916 ExecStartPre=/bin/rm -f /etc/dfs/sharetab (code=exited, status=0/SUCCESS)
  Process: 8923 ExecStart=/sbin/zfs share -a (code=exited, status=0/SUCCESS)
 Main PID: 8923 (code=exited, status=0/SUCCESS)

Aug 09 12:42:50 prox15 systemd[1]: Starting ZFS file system shares...
Aug 09 12:42:50 prox15 systemd[1]: Started ZFS file system shares.

● zfs-import-cache.service - Import ZFS pools by cache file
   Loaded: loaded (/lib/systemd/system/zfs-import-cache.service; enabled; vendor preset: enabled)
   Active: active (exited) since Fri 2019-08-09 12:42:50 CEST; 1h 47min ago
     Docs: man:zpool(8)
  Process: 598 ExecStart=/sbin/zpool import -c /etc/zfs/zpool.cache -aN (code=exited, status=0/SUCCESS)
 Main PID: 598 (code=exited, status=0/SUCCESS)

Aug 09 12:42:49 prox15 systemd[1]: Starting Import ZFS pools by cache file...
Aug 09 12:42:50 prox15 systemd[1]: Started Import ZFS pools by cache file.

● zfs.target - ZFS startup target
   Loaded: loaded (/lib/systemd/system/zfs.target; enabled; vendor preset: enabled)
   Active: active since Fri 2019-08-09 12:42:50 CEST; 1h 47min ago

Aug 09 12:42:50 prox15 systemd[1]: Reached target ZFS startup target.

Storage:

dir: local
        path /var/lib/vz
        content images,snippets,iso,rootdir,vztmpl
        maxfiles 0

zfspool: zfs
        pool nvme1
        content images,rootdir
        sparse 1

zfspool: backup
        pool nvme1
        content images,rootdir
        sparse 1

 

[carsten2]

Das Problem ist, dass irgendein Hintergrundprozess bei in storage.cfg konfigurierten Verzeichnissen diese versucht anzulegen, selbst wenn sie eigentlich ein Mount-Point sind. Wenn das Mounten aus irgendwelchen Gründen nicht rechtzeitig stattfindet, wird das durch die automatische Erzeugung dauerhaft verhindert. Das Problem hatte ich früher schon mal und es schein einen Parameter is_mountpoint zu geben, der das automatische Anlegen verhindert. Dieser scheint in Proxmox 6 aber nicht mehr zu funktionieren.

Beispiel:
Inhalt: storage.cfg:

dir: vmdatadir
path /data1/vmdatadir
content iso,backup,images,vztmpl,rootdir
is_mountpoint 1
maxfiles 2
shared 0

Wenn vmdatadir nicht gemountet ist, wird nach ein paar Sekundne das Verzeichnis vmdatadir angelegt. Selbst wenn man es löscht, erscheint es nach ein paar Sekunden wieder. Die Lösung ist also "Löschen und sofort mounten" in einem Befehl:

rmdir vmdatadir && zfs mount a

Dieser Fehler in Proxmox sollte behoben werden und der Paramter is_mountpoint wieder berücksichtigt werden, bzw. das automatische ggf. Anlegen komplett abgeschaltet werden, denn man kann auch sagen, dass ein in storage.cfg konfiguriertVerzeichnis vorab manuell angelegt werden muss, also immer existieren muss.

 

[Stoiko Ivanov]

Hm - normalerweise muss bei einem directory-storage auf ZFS auch der 'mkdir 0' parameter gesetzt werden.

ausserdem sollten images und rootdir (vm und container disks) nicht auf dem directory, sondern direkt im ZFS angelegt werden (als eigenes dataset, bzw. zvol)

Hoffe das hilft!

 

[carsten2]

1) Welcher "mkdir 0"-Parameter? Der steht nicht in der Doku und kann über die Oberfläche auch nicht angegeben werden.
Muss man den in die storage.cfg manuell einfügen? Was ist der Unterschied zu is_mountpoint?

2) data1/vmdatadir ist ein ZFS-Filesystem. Das ist als Typ "dir" eingebunden. Evtl. wäre "zfspool" besser (wobei der Name falsch zu sein scheint, denn es ist ja kein Pool sondern ein Filesystem)? Verhindert der Typ zfspool evtl. das automatische Erzeugen des Verzeichnisses, welches durch dir stattfindet?

3) Die LXCs sind alles ZFS-Filesysteme unter dem Pool data1 (z.B. /data1/vmdata1/subvol-103-disk-1). Aber auch hier gab es das Problem, dass das Verzeichnis data1/vmdata1 nicht leer war, spondern von Proxmox mit etwas gefüllt wurde, so dass data/vmdata1 und folgend die subvols nicht gemounted werden konnten. Ein Löschen des Inhalts und dann "zfs mount -a" behob das Problem.

 

[Stoiko Ivanov]

1) Welcher "mkdir 0"-Parameter? Der steht nicht in der Doku und kann über die Oberfläche auch nicht angegeben werden.
Muss man den in die storage.cfg manuell einfügen? Was ist der Unterschied zu is_mountpoint?

ja muss in der storage.cfg manuell hinzugefügt werden - siehe `man pvesm`

2) data1/vmdatadir ist ein ZFS-Filesystem. Das ist als Typ "dir" eingebunden. Evtl. wäre "zfspool" besser (wobei der Name falsch zu sein scheint, denn es ist ja kein Pool sondern ein Filesystem)? Verhindert der Typ zfspool evtl. das automatische Erzeugen des Verzeichnisses, welches durch dir stattfindet?

Normalerweise wird für zfspool ein pool (data1) genommen, und dieser muss unter seinem standard-mountpoint '/data1' gemountet werden können, dann werden sämtliche container darunter als datasets angelegt (/data1/subvol-103-disk-1)

 

[carsten2]

Ich habe im Pool einen Proxmox-ZFS-Pool vmdata1,vmdata2 usw. angelegt, um verschiedene Gruppen von VMs trennen zu können und verschiedene ZFS-Einstellungen machen zu können. Diese sind alle als ZFSPOOL in Proxmox angelegt. Zusätzlich ein DIR vmdatadir, um ISO-Images und Backups zu speichern. Das Problem nun, dass diese Dateisysteme nicht immer gemounted werden können, da Proxmox dort Verzeichnisse anlegt. Das muss unterbunden werden können, bzw. sollte standardmäßig unterbunden sein.

Mir scheint der Parameter is_mountpoint der richtigere zu sein, aber er scheint nicht richtig zu funktionieren.

 

[Stoiko Ivanov]

funktioniert es mit dem `mkdir 0` parameter - zusätzlich zum 'is_mountpoint' ?