Backups restoren lässt andere VMs abstürtzen, Ursache lvm-thin?

[ARPA_net_agent]

Hallo,
wir sind auf eine neue Version von Proxmox umgestiegen. Seit dem ist es so, dass wenn wir ein Backup von unserm externen Backup-Server wiederherstellen, die anderen VMs nicht mehr reagieren oder abschmieren. Da ist ein ziemliches Problem weil darunter auch ein DHCP und Mail-Server sind. Vorher lagen unsere ganzen VMs in der local Storage vom Typ directory. In der neuen Version liegen sie in einem lvmthin names data. Wir vermuten das es ein bottleneck gibt, da die write Operation des restore in das lvmthin alles andere ausbremst. Aber warum war das dann vorher nicht der Fall? Und gibt es eine Möglichkeit das zu reparieren, ohne alle VMs wieder auf local zu spielen (wobei wir erstmal die Partition ändern müssten)? Wir haben schon versucht ein restore bandwidth Limit zu setzen, das scheint aber nicht geholfen zu haben. Im Anhang lsblk auf dem alten Proxmox, und jeweils die Storage GUI auf dem alten und neuen.
Hier noch ein paar Resultate auf dem neuen:

root@Superserver:~# pvesm lvmscan
pve
root@Superserver:~# pvesm lvmthinscan pve
data
root@Superserver:~# pvesm lvmscan
pve
root@Superserver:~# pvs
  PV         VG  Fmt  Attr PSize PFree
  /dev/sda3  pve lvm2 a--  7.27t <16.38g
root@Superserver:~# lvs
  LV            VG  Attr       LSize   Pool Origin Data%  Meta%  Move Log Cpy%Sync Convert
  data          pve twi-aotz--  <7.13t             40.69  9.66
  root          pve -wi-ao----  96.00g
  swap          pve -wi-ao----   8.00g
  vm-102-disk-0 pve Vwi-a-tz-- 500.00g data        5.98
  vm-104-disk-0 pve Vwi-a-tz--  50.00g data        66.69
  vm-105-disk-0 pve Vwi-a-tz--  90.00g data        61.99
  vm-107-disk-0 pve Vwi-aotz-- 512.00g data        9.91
  vm-108-disk-0 pve Vwi-a-tz-- 512.00g data        8.51
  vm-109-disk-0 pve Vwi-a-tz-- 500.00g data        20.36
  vm-112-disk-0 pve Vwi-aotz--   1.46t data        83.85
  vm-113-disk-0 pve Vwi-a-tz--   1.00t data        9.17
  vm-114-disk-0 pve Vwi-a-tz--  50.00g data        94.78
  vm-115-disk-0 pve Vwi-a-tz--  50.00g data        92.69
  vm-116-disk-0 pve Vwi-aotz-- 530.00g data        84.45
  vm-116-disk-1 pve Vwi-aotz-- 512.00g data        94.60
  vm-118-disk-0 pve Vwi-a-tz--   1.00t data        20.73
  vm-121-disk-0 pve Vwi-a-tz--  50.00g data        95.62
  vm-122-disk-0 pve Vwi-a-tz--  <7.82g data        87.96
  vm-122-disk-1 pve Vwi-a-tz--  <7.82g data        90.27
  vm-122-disk-2 pve Vwi-a-tz--   5.00g data        59.26
root@Superserver:~# lsblk
NAME                         MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
sda                            8:0    1  7.3T  0 disk
├─sda1                         8:1    1 1007K  0 part
├─sda2                         8:2    1  512M  0 part
└─sda3                         8:3    1  7.3T  0 part
  ├─pve-swap                 253:0    0    8G  0 lvm  [SWAP]
  ├─pve-root                 253:1    0   96G  0 lvm  /
  ├─pve-data_tmeta           253:2    0 15.8G  0 lvm
  │ └─pve-data-tpool         253:4    0  7.1T  0 lvm
  │   ├─pve-data             253:5    0  7.1T  1 lvm
  │   ├─pve-vm--105--disk--0 253:6    0   90G  0 lvm
  │   ├─pve-vm--122--disk--0 253:7    0  7.8G  0 lvm
  │   ├─pve-vm--122--disk--1 253:8    0  7.8G  0 lvm
  │   ├─pve-vm--122--disk--2 253:9    0    5G  0 lvm
  │   ├─pve-vm--102--disk--0 253:10   0  500G  0 lvm
  │   ├─pve-vm--104--disk--0 253:11   0   50G  0 lvm
  │   ├─pve-vm--107--disk--0 253:12   0  512G  0 lvm
  │   ├─pve-vm--108--disk--0 253:13   0  512G  0 lvm
  │   ├─pve-vm--109--disk--0 253:14   0  500G  0 lvm
  │   ├─pve-vm--118--disk--0 253:15   0    1T  0 lvm
  │   ├─pve-vm--115--disk--0 253:16   0   50G  0 lvm
  │   ├─pve-vm--113--disk--0 253:17   0    1T  0 lvm
  │   ├─pve-vm--114--disk--0 253:18   0   50G  0 lvm
  │   ├─pve-vm--116--disk--0 253:19   0  530G  0 lvm
  │   ├─pve-vm--116--disk--1 253:20   0  512G  0 lvm
  │   ├─pve-vm--112--disk--0 253:21   0  1.5T  0 lvm
  │   └─pve-vm--121--disk--0 253:22   0   50G  0 lvm
  └─pve-data_tdata           253:3    0  7.1T  0 lvm
    └─pve-data-tpool         253:4    0  7.1T  0 lvm
      ├─pve-data             253:5    0  7.1T  1 lvm
      ├─pve-vm--105--disk--0 253:6    0   90G  0 lvm
      ├─pve-vm--122--disk--0 253:7    0  7.8G  0 lvm
      ├─pve-vm--122--disk--1 253:8    0  7.8G  0 lvm
      ├─pve-vm--122--disk--2 253:9    0    5G  0 lvm
      ├─pve-vm--102--disk--0 253:10   0  500G  0 lvm
      ├─pve-vm--104--disk--0 253:11   0   50G  0 lvm
      ├─pve-vm--107--disk--0 253:12   0  512G  0 lvm
      ├─pve-vm--108--disk--0 253:13   0  512G  0 lvm
      ├─pve-vm--109--disk--0 253:14   0  500G  0 lvm
      ├─pve-vm--118--disk--0 253:15   0    1T  0 lvm
      ├─pve-vm--115--disk--0 253:16   0   50G  0 lvm
      ├─pve-vm--113--disk--0 253:17   0    1T  0 lvm
      ├─pve-vm--114--disk--0 253:18   0   50G  0 lvm
      ├─pve-vm--116--disk--0 253:19   0  530G  0 lvm
      ├─pve-vm--116--disk--1 253:20   0  512G  0 lvm
      ├─pve-vm--112--disk--0 253:21   0  1.5T  0 lvm
      └─pve-vm--121--disk--0 253:22   0   50G  0 lvm

 

[mira]

Vermutlich liegt es am Anlegen der Disk. Dabei wird, wenn es ein thin-provisioned LV ist, dieses mit Nullen initialisiert.
Das passiert in QEMU/qemu-img und PVE hat da keine Kontrolle darüber.
Es gibt bereits einige Berichte von ähnlichem Verhalten bei der Live Migration und LVM thin.

Handelt es sich um HDD(s) oder SSD(s) beim `local-lvm` Storage?

 

[ARPA_net_agent]

es handelt sich um eine HDD.

EDIT: Dies sind eigentlich mehrere Platten mit einem hardware RAID controller, der sie nach außen wie eine Platte erscheinen lässt

 

[itNGO]

es handelt sich um eine HDD.

EDIT: Dies sind eigentlich mehrere Platten mit einem hardware RAID controller.

Hi,
wenn der Restore beginnt wird zunächst ein LVM-Thin initialisiert, wenn das Volume im Backup 100GB groß ist, werden 100GB "00" auf den LVM-Thin "initialisiert". Das in Kombination mit einer HDD und das System ist für Zeit X einfach ausgelastet.

Da kann Proxmox nix zu, das QEMU unterliegend gibt an der Stelle einfach "Vollgas" beim Anlegen.
Anderen Volume-Typ benutzen, auf SSD wechseln oder die Restores zu Zeiten machen wo es keinen stört....

 

[Falk R.]

Wenn das ein Hardware Raid Controller ist, hilft da ein Batteriecache. Damit werden genau solche Operationen deutlich besser verarbeitet.