disc full obwohl noch Platz ist!?!

O

oberfragger

Member
Nov 22, 2022
15
2
8
Moin,

leider muss ich mich hier mal melden. Ich kann plötzlich einen Container nicht mehr starten. Er meldet: Not enough space. Das verstehe ich nicht. Das Backup hat entpackt keine 2GB. Ich bekomme auch ein Warning dass die LVM-Thin Size überschritten ist.

In meinem NUC steckt eine 120GB M.1 SSD. Zusätzlich einen 1TB SSD angeschlossen.

Irgendwas muss ich bei der Erstellung bzw. Zuweisung im LVM falsch gemacht haben. Wie kann ich das "Geradebiegen". Da ist doch eigenlich genug Platz!

Laut LVM:
1669151725574.png
IM LVM-Thin steht das drin:
1669151758527.png

Ich habe jetzt mal ein restore auf der 1TB SSD probiert. Auch da heisst es:
Code: 
recovering backed-up configuration from 'Qnap:backup/vzdump-lxc-104-2022_11_21-00_26_24.tar.gz'
  Logical volume "vm-104-disk-0" created.
Creating filesystem with 786432 4k blocks and 196608 inodes
Filesystem UUID: c07a6d43-452e-47f7-a464-dfe1c2769302
Superblock backups stored on blocks:
    32768, 98304, 163840, 229376, 294912
  Logical volume "vm-104-disk-1" created.
Creating filesystem with 26214400 4k blocks and 6553600 inodes
Filesystem UUID: 6d8f98f1-24b7-46f4-ae5f-e1842f414bd7
Superblock backups stored on blocks:
    32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
    4096000, 7962624, 11239424, 20480000, 23887872
restoring 'Qnap:backup/vzdump-lxc-104-2022_11_21-00_26_24.tar.gz' now..
extracting archive '/mnt/pve/Qnap/dump/vzdump-lxc-104-2022_11_21-00_26_24.tar.gz'
tar: ./etc/ImageMagick-6/mime.xml: Cannot write: No space left on device
tar: ./etc/ImageMagick-6/type-apple.xml: Cannot write: No space left on device
tar: ./etc/ImageMagick-6/type-urw-base35.xml: Cannot write: No space left on device
tar: ./etc/timezone: Cannot write: No space left on device
...

Code: 
root@pve:~# df -h
Filesystem                         Size  Used Avail Use% Mounted on
udev                               3.9G     0  3.9G   0% /dev
tmpfs                              788M  1.2M  787M   1% /run
/dev/mapper/pve-root                28G   14G   13G  53% /
tmpfs                              3.9G   46M  3.9G   2% /dev/shm
tmpfs                              5.0M     0  5.0M   0% /run/lock
/dev/fuse                          128M   20K  128M   1% /etc/pve
192.168.178.11:/Sicherung/Proxmox  2.7T  2.3T  478G  83% /mnt/pve/Qnap
tmpfs                              788M  4.0K  788M   1% /run/user/0
root@pve:~# qm list
      VMID NAME                 STATUS     MEM(MB)    BOOTDISK(GB) PID
       202 ioBroker             running    5120              15.00 2577
root@pve:~# vm list
-bash: vm: command not found
root@pve:~# pct list
VMID       Status     Lock         Name
100        running                 pihole
101        running                 fileshare
103        running                 MariaDB
105        running                 homebridge
root@pve:~# lvm
lvm> vgs
  VG     #PV #LV #SN Attr   VSize    VFree
  pve      1   8   0 wz--n- <111.29g  13.87g
  vmdata   1   3   0 wz--n-  931.51g 120.00m
lvm>

Code: 
root@pve:~# cat /etc/fstab
# <file system> <mount point> <type> <options> <dump> <pass>
/dev/pve/root / ext4 errors=remount-ro 0 1
/dev/pve/swap none swap sw 0 0
proc /proc proc defaults 0 0

Ideen was ich machen kann?
 
Hi,
Du könntest versuchen, die Größe der Root-Disk vom Container während dem Restore zu vergrößern, siehe hier. Wenn das nicht hilft, bitte die Konfiguration des Containers aus dem Backup und die Ausgabe von pveversion -v posten.
 
  • Like
Reactions: oberfragger
fiona said:
Hi,
Du könntest versuchen, die Größe der Root-Disk vom Container während dem Restore zu vergrößern, siehe hier. Wenn das nicht hilft, bitte die Konfiguration des Containers aus dem Backup und die Ausgabe von pveversion -v posten.
Click to expand...
Daanke. Fast geschafft. Ich hatte 100G Speicher der weiteren internen Festplatte allokiert. Sind die Daten da nun weg oder gibt da nen Trick/ Ergänzung des Parameters? Oder kann ich das bestehende Script irgenwie anpassen?

Ich hab echt keine Ahnung was den Speicher in Proxmox angeht.
Habe jetzt folgendes ausgeführt:
Code: 
pct restore 104  '/mnt/pve/Qnap/dump/vzdump-lxc-104-2022_11_21-00_26_24.tar.gz' --storage local-lvm --rootfs local-lvm:5
und der Container läuft wieder.

Ich habe KEINE Ahnung wo er nun den weiteren, notwenidgen Speicher hergezaubert hat. Mit 3GB war ein entpacken nicht möglich, 5 hat dann aber geklappt.

Anscheinend liegt ja der notwendige Speicher IM LVM-Thin-Pool.
Code: 
  --- Logical volume ---
  LV Name                data
  VG Name                pve
  LV UUID                TWDYz9-3Bae-txyh-SE43-JDMn-ZWYn-uba5kU
  LV Write Access        read/write (activated read only)
  LV Creation host, time proxmox, 2020-10-03 22:06:21 +0200
  LV Pool metadata       data_tmeta
  LV Pool data           data_tdata
  LV Status              available
  # open                 0
  LV Size                63.66 GiB
  Allocated pool data    37.99%
  Allocated metadata     2.76%
  Current LE             16298
  Segments               1
  Allocation             inherit
  Read ahead sectors     auto
  - currently set to     256
  Block device           253:7

Vorher lag der allokierte Speicher bei ~35%. Ist das richtig- alle LXC liegen im ThinPool, werden aber mit LVS einzeln angegeben?

Code: 
root@pve:~# lvs
  LV            VG     Attr       LSize   Pool   Origin Data%  Meta%  Move Log Cpy%Sync Convert
  data          pve    twi-aotz--  63.66g               38.00  2.76
  root          pve    -wi-ao----  27.75g
  swap          pve    -wi-ao----   4.00g
  vm-100-disk-0 pve    Vwi-aotz--   3.00g data          99.66
  vm-101-disk-0 pve    Vwi-aotz--   4.00g data          31.62
  vm-103-disk-0 pve    Vwi-aotz--   2.00g data          90.82
  vm-104-disk-0 pve    Vwi-aotz--   5.00g data          60.47
  vm-105-disk-0 pve    Vwi-aotz--   2.00g data          90.72
  vm-202-disk-0 pve    Vwi-aotz--  15.00g data          88.56
  vm-101-disk-0 vmdata Vwi-aotz-- 500.00g vmdata        64.49
  vm-103-disk-0 vmdata Vwi-aotz--   4.00g vmdata        61.42
  vmdata        vmdata twi-aotz-- 912.76g               35.59  1.80

Naja, jetzt habe ich auch gelernt, wie man den zugewiesenen Storage von Container verkleinern kann.
Backup erstellen, stoppen und mit dem Befehl und angepasster Storagegröße wiederherstellen.

Also, wie gesagt Danke. Und hast du noch eine Idee bzgl. des "externen" Speichers?
 
Last edited:
fiona said:
Hi,
Du könntest versuchen, die Größe der Root-Disk vom Container während dem Restore zu vergrößern, siehe hier. Wenn das nicht hilft, bitte die Konfiguration des Containers aus dem Backup und die Ausgabe von pveversion -v posten.
Click to expand...
Leider noch nicht ganz fertig.

Abgesehen vom gemounteten Storage....hast du noch eine Idee wie ich den Container unpriviligiert starten kann?
Code: 
pct restore 104  '/mnt/pve/Qnap/dump/vzdump-lxc-104-2022_11_21-00_26_24.tar.gz' --storage local-lvm --rootfs local-lvm:5 --unprivileged
klappt leider nicht.

Code: 
root@pve:~# pct restore 104  '/mnt/pve/Qnap/dump/vzdump-lxc-104-2022_11_21-00_26_24.tar.gz' --storage local-lvm --rootfs local-lvm:4 --unprivileged
Use of uninitialized value $PVE::JSONSchema::PVE_TAG_RE in concatenation (.) or string at /usr/share/perl5/PVE/DataCenterConfig.pm line 147.
Use of uninitialized value $PVE::JSONSchema::PVE_TAG_RE in concatenation (.) or string at /usr/share/perl5/PVE/DataCenterConfig.pm line 182.
Use of uninitialized value $PVE::JSONSchema::PVE_TAG_RE in concatenation (.) or string at /usr/share/perl5/PVE/DataCenterConfig.pm line 182.
Use of uninitialized value $PVE::JSONSchema::PVE_TAG_RE in concatenation (.) or string at /usr/share/perl5/PVE/DataCenterConfig.pm line 208.
Use of uninitialized value $PVE::JSONSchema::PVE_TAG_RE in concatenation (.) or string at /usr/share/perl5/PVE/DataCenterConfig.pm line 208.
recovering backed-up configuration from '/mnt/pve/Qnap/dump/vzdump-lxc-104-2022_11_21-00_26_24.tar.gz'
  Logical volume "vm-104-disk-0" created.
Creating filesystem with 1048576 4k blocks and 262144 inodes
Filesystem UUID: d37a2041-1f28-4d2e-8e04-f528a0814fd6
Superblock backups stored on blocks: 
        32768, 98304, 163840, 229376, 294912, 819200, 884736
restoring '/mnt/pve/Qnap/dump/vzdump-lxc-104-2022_11_21-00_26_24.tar.gz' now..
extracting archive '/mnt/pve/Qnap/dump/vzdump-lxc-104-2022_11_21-00_26_24.tar.gz'
tar: ./var/spool/postfix/dev/urandom: Cannot mknod: Operation not permitted
tar: ./var/spool/postfix/dev/random: Cannot mknod: Operation not permitted
Total bytes read: 3056711680 (2.9GiB, 68MiB/s)
tar: Exiting with failure status due to previous errors
  Logical volume "vm-104-disk-0" successfully removed
unable to restore CT 104 - command 'lxc-usernsexec -m u:0:100000:65536 -m g:0:100000:65536 -- tar xpf - -z --totals --one-file-system -p --sparse --numeric-owner --acls --xattrs '--xattrs-include=user.*' '--xattrs-include=security.capability' '--warning=no-file-ignored' '--warning=no-xattr-write' -C /var/lib/lxc/104/rootfs --skip-old-files --anchored --exclude './dev/*'' failed: exit code 2
 
ITT said:
Machst du auch regelmäßig TRIM (im PVE)?
Click to expand...
Nein. Daran kann ich mich nicht erinnern.

Wie mache ich das? EInfach folgendes in die Console?

Code: 
cp /usr/share/doc/util-linux/examples/fstrim.{service,timer} /etc/systemd/system
systemctl enable fstrim.timer
systemctl start fstrim.timer
Oder muss ich da noch was anpassen?
Ich denke mal ich muss irgendwas in die geschweifte Klammer eintragen...!?!
 
ITT said:
Machst du auch regelmäßig TRIM (im PVE)?
Click to expand...
...ich hatte je die Hoffnung dass nach dem aufräumen das Backup doch vielleicht wieder funktioniert. Naja. Leider nicht.
Gut. Ich setze wohl neu auf. EInstellungen sind überschaubar.
 
oberfragger said:
Nein. Daran kann ich mich nicht erinnern.

Wie mache ich das? EInfach folgendes in die Console?
Click to expand...
In der PVE Konsole
pct list | awk '/^[0-9]/ {print $1}' | while read ct; do pct fstrim ${ct}; done
Das muss man übrigens regelmässig machen, ich machs 1* die Woche.
 
Last edited:
oberfragger said:
Daanke. Fast geschafft. Ich hatte 100G Speicher der weiteren internen Festplatte allokiert. Sind die Daten da nun weg oder gibt da nen Trick/ Ergänzung des Parameters? Oder kann ich das bestehende Script irgenwie anpassen?
Click to expand...
Wenn das ein Volume des Containers war (also kein Bind-Mount) und wenn die Daten nicht im Backup sind, fürchte ich, sind sie weg. Wenn Du über einen bestehenden Container drüber-wiederherstellst, dann werden die Daten vom aktuellen gelöscht. Dazu gibt es auch eine Warnung in der UI, die man bestätigen muss. Und auf der Kommandozeile, muss man explizit die --force Option benutzen, um einen bestehenden Container zu überschreiben.

oberfragger said:
Ich hab echt keine Ahnung was den Speicher in Proxmox angeht.
Habe jetzt folgendes ausgeführt:
Code: 
pct restore 104  '/mnt/pve/Qnap/dump/vzdump-lxc-104-2022_11_21-00_26_24.tar.gz' --storage local-lvm --rootfs local-lvm:5
und der Container läuft wieder.

Ich habe KEINE Ahnung wo er nun den weiteren, notwenidgen Speicher hergezaubert hat. Mit 3GB war ein entpacken nicht möglich, 5 hat dann aber geklappt.
Click to expand...
Wenn Du Lust hast, könntest Du im Container nachschauen, welche Dateien den Speicher brauchen. Handelt es sich möglicherweise um sparse files oder ähnliches?

oberfragger said:
Vorher lag der allokierte Speicher bei ~35%. Ist das richtig- alle LXC liegen im ThinPool, werden aber mit LVS einzeln angegeben?
Click to expand...
Ja, die Pool-Spalte zeigt an, in welchem Pool ein Volume ist.

oberfragger said:
Abgesehen vom gemounteten Storage....hast du noch eine Idee wie ich den Container unpriviligiert starten kann?
Code: 
pct restore 104  '/mnt/pve/Qnap/dump/vzdump-lxc-104-2022_11_21-00_26_24.tar.gz' --storage local-lvm --rootfs local-lvm:5 --unprivileged
klappt leider nicht.
Click to expand...
War der Container vorher privilegiert? Bin mir grad nicht sicher, ob man da in allen Fällen als unprivilegiert wiederherstellen kann.

oberfragger said:
Code: 
root@pve:~# pct restore 104  '/mnt/pve/Qnap/dump/vzdump-lxc-104-2022_11_21-00_26_24.tar.gz' --storage local-lvm --rootfs local-lvm:4 --unprivileged
Use of uninitialized value $PVE::JSONSchema::PVE_TAG_RE in concatenation (.) or string at /usr/share/perl5/PVE/DataCenterConfig.pm line 147.
Use of uninitialized value $PVE::JSONSchema::PVE_TAG_RE in concatenation (.) or string at /usr/share/perl5/PVE/DataCenterConfig.pm line 182.
Use of uninitialized value $PVE::JSONSchema::PVE_TAG_RE in concatenation (.) or string at /usr/share/perl5/PVE/DataCenterConfig.pm line 182.
Use of uninitialized value $PVE::JSONSchema::PVE_TAG_RE in concatenation (.) or string at /usr/share/perl5/PVE/DataCenterConfig.pm line 208.
Use of uninitialized value $PVE::JSONSchema::PVE_TAG_RE in concatenation (.) or string at /usr/share/perl5/PVE/DataCenterConfig.pm line 208.
Click to expand...
Die Fehler sollten harmlos sein, aber bitte alle Nodes im Cluster updaten ;)

oberfragger said:
Code: 
tar: ./var/spool/postfix/dev/urandom: Cannot mknod: Operation not permitted
tar: ./var/spool/postfix/dev/random: Cannot mknod: Operation not permitted
Click to expand...
mknod geht eben leider nur für privilegierte Container soweit ich weiß.
 
You must log in or register to reply here.

About

The Proxmox community has been around for many years and offers help and support for Proxmox VE, Proxmox Backup Server, and Proxmox Mail Gateway.
We think our community is one of the best thanks to people like you!

Quick Navigation

Home Get Subscription Wiki Downloads Proxmox Customer Portal About

Get your subscription!

The Proxmox team works very hard to make sure you are running the best software and getting stable updates and security enhancements, as well as quick enterprise support. Tens of thousands of happy customers have a Proxmox subscription. Get yours easily in our online shop.

Buy now!
Community platform by XenForo® © 2010-2024 XenForo Ltd.
Top Bottom