Proxmox 6.1 VE Crash beim kopieren

[spaxxilein]

Moin!

Sobald wir lokal ein Hyper-V Image nach qemu in Raw per DD in eine virtuelle DIsk auf einem ZFS Pool schreiben, stürzt der gesamte Host mit Kernel Panic ab. Ich dachte ich bin bescheuert und habe es 3x probiert, jedes mal wenn ich mit dd das Image in das ZFS Image schreibe stürzt der gesamte Host ab, also nicht nur eine VM, sondern komplett Proxmox. Ich kann die ganzen VMs auch nicht mehr herunterfahren, das Webinterface ist nicht mehr erreichbar. Per SSH komme ich noch auf die Node, kann aber die VMs nicht beenden, da bei "qm stop XXX" die shell abstützt und nicht mehr reagiert.

Es handelt sich um einen neuen EPYC Server 7828 mit 128GB ECC-Ram. Der ZFS Pool besteht auf 4x4TB + SSD-Cache.

Hat irgendjemand eine Idee woran das liegen könnte?

BG

spaxxilein

 

[t.lamprecht]

Per SSH komme ich noch auf die Node, kann aber die VMs nicht beenden, da bei "qm stop XXX" die shell abstützt und nicht mehr reagiert.

Steht zu dem Zeitpunkt irgendwas verdächtiges im Kernel log (dmesg)?

Funktioniert qm importdisk VMID ./path/to/source.vhdx STORAGE-ID?

 

[spaxxilein]

Steht zu dem Zeitpunkt irgendwas verdächtiges im Kernel log (dmesg)?

Funktioniert qm importdisk VMID ./path/to/source.vhdx STORAGE-ID?

Ich kriege immer das raus:

root@pve:/tmp# qm importdisk 109 MDB.vhdx VM-DATA
importing disk 'MDB.vhdx' to VM 109 ...
transferred: 0 bytes remaining: 53687091200 bytes total: 53687091200 bytes progression: 0.00 %
qemu-img: output file is smaller than input file
copy failed: command '/usr/bin/qemu-img convert -p -n -t none -f raw -O raw MDB.vhdx zeroinit:/dev/zvol/rpool/vmdata/vm-109-disk-1' failed: exit code 1
root@pve:/tmp#

EDIT: this fixed it, always supply the complete path to the imported file :

qm importdisk 109 /tmp/MDB.vhdx VM-DATA

EDIT2: does not work

root@pve:/tmp# qm importdisk 109 /tmp/MDB.vhdx VM-DATA
importing disk '/tmp/MDB.vhdx' to VM 109 ...
command 'zfs create -s -V 52428800k rpool/vmdata/vm-109-disk-1' failed: got timeout
root@pve:/tmp#

 

[t.lamprecht]

Hmm, komisch. Was passiert wenn du die zwei schritte manuell ausführst:

zfs create -s -V 52428800k rpool/vmdata/vm-109-disk-1
qemu-img convert -p -n -t none -f raw -O raw MDB.vhdx zeroinit:/dev/zvol/rpool/vmdata/vm-109-disk-1

Nicht dass nur das Timeout für ZFS zu klein ist..

 

[spaxxilein]

Ich habe jetzt weiter getestet, das konvertieren funktioniert, was nicht funktioniert ist dass kopieren per dd, das ganze System hängt inklusive aller VMs, Webinterface nicht erreichbar, lediglich SSH Zugriff möglich:

Jan 22 13:13:12 pve kernel: [84461.556184] INFO: task txg_sync:1057 blocked for more than 120 seconds.
Jan 22 13:13:12 pve kernel: [84461.556902]       Tainted: P           O      5.3.10-1-pve #1
Jan 22 13:13:12 pve kernel: [84461.557479] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
Jan 22 13:13:12 pve kernel: [84461.558043] txg_sync        D    0  1057      2 0x80004000
Jan 22 13:13:12 pve kernel: [84461.558615] Call Trace:
Jan 22 13:13:12 pve kernel: [84461.559199]  __schedule+0x2bb/0x660
Jan 22 13:13:12 pve kernel: [84461.559809]  ? zio_taskq_member.isra.12.constprop.17+0x70/0x70 [zfs]
Jan 22 13:13:12 pve kernel: [84461.560408]  schedule+0x33/0xa0
Jan 22 13:13:12 pve kernel: [84461.560985]  schedule_timeout+0x152/0x300
Jan 22 13:13:12 pve kernel: [84461.561551]  ? __next_timer_interrupt+0xd0/0xd0
Jan 22 13:13:12 pve kernel: [84461.562123]  io_schedule_timeout+0x1e/0x50
Jan 22 13:13:12 pve kernel: [84461.562695]  __cv_timedwait_common+0x12f/0x170 [spl]
Jan 22 13:13:12 pve kernel: [84461.563268]  ? wait_woken+0x80/0x80
Jan 22 13:13:12 pve kernel: [84461.563838]  __cv_timedwait_io+0x19/0x20 [spl]
Jan 22 13:13:12 pve kernel: [84461.564465]  zio_wait+0x13a/0x280 [zfs]
Jan 22 13:13:12 pve kernel: [84461.565039]  ? _cond_resched+0x19/0x30
Jan 22 13:13:12 pve kernel: [84461.565644]  dsl_pool_sync+0xdc/0x4f0 [zfs]
Jan 22 13:13:12 pve kernel: [84461.566253]  spa_sync+0x5b2/0xfc0 [zfs]
Jan 22 13:13:12 pve kernel: [84461.566863]  ? spa_txg_history_init_io+0x106/0x110 [zfs]
Jan 22 13:13:12 pve kernel: [84461.567477]  txg_sync_thread+0x2d9/0x4c0 [zfs]
Jan 22 13:13:12 pve kernel: [84461.568095]  ? txg_thread_exit.isra.12+0x60/0x60 [zfs]
Jan 22 13:13:12 pve kernel: [84461.568693]  thread_generic_wrapper+0x74/0x90 [spl]
Jan 22 13:13:12 pve kernel: [84461.569282]  kthread+0x120/0x140
Jan 22 13:13:12 pve kernel: [84461.569866]  ? __thread_exit+0x20/0x20 [spl]
Jan 22 13:13:12 pve kernel: [84461.570450]  ? __kthread_parkme+0x70/0x70
Jan 22 13:13:12 pve kernel: [84461.571027]  ret_from_fork+0x22/0x40
Jan 22 13:13:12 pve kernel: [84461.571621] INFO: task kvm:962 blocked for more than 241 seconds.
Jan 22 13:13:12 pve kernel: [84461.572206]       Tainted: P           O      5.3.10-1-pve #1
Jan 22 13:13:12 pve kernel: [84461.572804] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
Jan 22 13:13:12 pve kernel: [84461.573396] kvm             D    0   962      1 0x00004000
Jan 22 13:13:12 pve kernel: [84461.573994] Call Trace:
Jan 22 13:13:12 pve kernel: [84461.574572]  __schedule+0x2bb/0x660
Jan 22 13:13:12 pve kernel: [84461.575146]  ? mutex_lock+0x12/0x30
Jan 22 13:13:12 pve kernel: [84461.575710]  schedule+0x33/0xa0
Jan 22 13:13:12 pve kernel: [84461.576277]  cv_wait_common+0x104/0x130 [spl]
Jan 22 13:13:12 pve kernel: [84461.576840]  ? wait_woken+0x80/0x80
Jan 22 13:13:12 pve kernel: [84461.577399]  __cv_wait+0x15/0x20 [spl]
Jan 22 13:13:12 pve kernel: [84461.577999]  rangelock_enter+0x127/0x580 [zfs]
Jan 22 13:13:12 pve kernel: [84461.578570]  ? spl_kmem_zalloc+0xe9/0x140 [spl]
Jan 22 13:13:12 pve kernel: [84461.579164]  zvol_get_data+0x81/0x170 [zfs]
Jan 22 13:13:12 pve kernel: [84461.579755]  zil_commit_impl+0x992/0xdb0 [zfs]
Jan 22 13:13:12 pve kernel: [84461.580356]  zil_commit+0x3d/0x60 [zfs]
Jan 22 13:13:12 pve kernel: [84461.580946]  zvol_request+0x233/0x3c0 [zfs]
Jan 22 13:13:12 pve kernel: [84461.581519]  generic_make_request+0xcf/0x310
Jan 22 13:13:12 pve kernel: [84461.582078]  submit_bio+0x40/0x170
Jan 22 13:13:12 pve kernel: [84461.582637]  submit_bio_wait+0x59/0x90
Jan 22 13:13:12 pve kernel: [84461.583194]  blkdev_issue_flush+0x8e/0xc0
Jan 22 13:13:12 pve kernel: [84461.583752]  blkdev_fsync+0x35/0x50
Jan 22 13:13:12 pve kernel: [84461.584315]  vfs_fsync_range+0x48/0x80
Jan 22 13:13:12 pve kernel: [84461.584870]  ? __fget_light+0x59/0x70
Jan 22 13:13:12 pve kernel: [84461.585424]  do_fsync+0x3d/0x70
Jan 22 13:13:12 pve kernel: [84461.585976]  __x64_sys_fdatasync+0x17/0x20
Jan 22 13:13:12 pve kernel: [84461.586534]  do_syscall_64+0x5a/0x130
Jan 22 13:13:12 pve kernel: [84461.587090]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
Jan 22 13:13:12 pve kernel: [84461.587651] RIP: 0033:0x7fb4410572e7
Jan 22 13:13:12 pve kernel: [84461.588228] Code: Bad RIP value.
Jan 22 13:13:12 pve kernel: [84461.588788] RSP: 002b:00007fb3b0df9e00 EFLAGS: 00000293 ORIG_RAX: 000000000000004b
Jan 22 13:13:12 pve kernel: [84461.589363] RAX: ffffffffffffffda RBX: 000000000000001b RCX: 00007fb4410572e7
Jan 22 13:13:12 pve kernel: [84461.589956] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 000000000000001b
Jan 22 13:13:12 pve kernel: [84461.590534] RBP: 00007fb43606a110 R08: 0000000000000000 R09: 00007fb3b0df9db0
Jan 22 13:13:12 pve kernel: [84461.591112] R10: 000000005e283b49 R11: 0000000000000293 R12: 000056247b49e5f2
Jan 22 13:13:12 pve kernel: [84461.591685] R13: 00007fb43606a178 R14: 00007fb4361bdd20 R15: 00007fb3b3224510

Hat jemand eine Ahnung woran das liegen könnte?

EDIT: das ganze passiert reproduzierbar wenn ich das zuvor per QEMU umgewandelte RAW-Image in eine vorhandene ZFS-Disk schieben will. Es scheint von der Größe / Kopierzeit abhängig zu sein, denn ein Image mit 50GB gab keine Probleme wohingegen dass 250GB Image jetzt wieder den ganzen Host zerschossen hat.

EDIT2: kann es etwas hiermit zutun haben?: https://www.cmo.de/wissensdatenbank/linux-problem-task-blocked-for-more-than-120-seconds/

EDIT3: ich vermute es liegt am viel zu hohen IO Delay. Je länger das kopieren dauert, desto höher steigt der IO-Delay und irgendwann steigt das System aus. Gibt es Tipps wie man das IO-Delay runter bekommt?

 

[Helmut Gruber]

ZFS ist der helle Wahnsinn. Haben vor einer Woche einen Server mit 2x4TB NVME als ZFS-RAID1 ausgeliefert. Fängt bei 70% RAM-Auslastung plötzlich zu swappen an, und zerschiesst wahllos (reproduzierbar) bei Linux-Guests die Bootpartitionen. Herausgefunden, dass sich ZFS im Standard die Hälfte des RAMs reserviert, aber irgendwie am Proxmox-Kernel vorbei, und der swappt dann plötzlich, und wenn der auch voll ist, passieren die Unglücke.

Gleiches beim Rücksichern vom zerschossenen Gästen: Wenn man die IO beim Restore auf volle Geschwindigkeit stehen lässt, hängen sich andere VMs auf. Und/oder das Restore bricht mit Fehlern ab.

Für mich ist ZFS in der aktuellen PVE (6.1.3) höchst experimentell und keinesfalls produktiv zu verwenden. Linux Torvalds hat wohl den richtigen Riecher, dass er ZFS nicht in den Kernel aufnehmen will...

 

[vikozo]

mitlesen
mein neuer Server hat sich gestern auch verabschiedet und blieb mit einem

grub rescue >

(nach 2 Stunden unaktivität auf dem neuen Server) hängen

 

[spaxxilein]

Ich habe bei einem ITler angerufen der sich mit Proxmox seit langem beschäftigt. Er hat mir dazu geraten auf ZFS zu verzichten und das ganze über ein Hardware-Raid zu realisieren. Adaptec 6805 ist bestellt. Wirklich sehr schade, dass es nicht so geklappt hat wie ich mir das vorgestellt hatte.

Hatte extra noch eine Consumer SSD als Cache eingebunde (ja ich weiß Consumer NIX gut), aber leider bringt das keine Besserung bei den IO-Werten.