PVE verliert(?) Verbindung zum NFS

AST · Oct 8, 2020

Moin,

mir ist folgendes Problem bereits zum zweiten Male untergekommen:

Ohne weiteres Zutun stellen gewisse VMs, deren Platten auf einer NAS liegen, teilweise oder ganz ihre Arbeit ein.
Über die Console /mnt/pve/nas7/ sind die Pfade erreichbar.
pvesm status ergibt auch die aktuellen Werte und spricht vom aktivem Status.
Andere Hosts im Cluster können über die WEB-Gui auch auf die Inhalte zugreifen - nur "der eine" Hosts nicht, in dem die VM mit den NAS-Laufwerken sitzt.

Dabei wurden zwei verschiedene NAS ausprobiert: eine mit 4 HDDs und 1gbit/s (~125MB/s) und eine mit 12HDDs und 2x 10gbit (~300MB/s).

Wenn dieser Zustand eintritt, sind keine Migrationen oder sonstige PVE-Befehle mehr auf diesem Host möglich. Geholfen hatte bisher nur ein Reboot, bei dem man noch einen Hardwarereset hinterherschicken muss, damit der endlich neustartet. Um den Host auszuschließen wurden die VMs mal migriert - selber Fehler nur dann eben auf dem entsprechendem Host.

Aktuell habe ich diesen Status und müsste dann heute Abend den Reset durchführen. Da das z.B. redundante VMs sind, ist das nicht ganz so übel.

Hat jemand diese Art von Problemen schonmal erlebt und wenn ja, wie gefixt?

Aktueller Versionsstand: 6.2-11 mit Standardlizenz.

Gruß, Patrick

oguz · Oct 8, 2020

hi,

LachCraft said:
Um den Host auszuschließen wurden die VMs mal migriert - selber Fehler nur dann eben auf dem entsprechendem Host.

kann dieser host die NAS normal erreichen?

kannst du bitte posten:

Code:

pveversion -v
cat /etc/pve/storage.cfg

siehst du in journalctl or /var/log/syslog etwas?

AST · Oct 8, 2020

> kann dieser host die NAS normal erreichen?
Das schrieb ich bereits, per Konsole ist alles erreichbar bis hin zu den Laufwerkimages

In den Logs ist mir nichts in den letzten 24h aufgefallen, da gestern noch alles in Ordnung war.

AST · Oct 8, 2020

PS: Offenbar ist das ganze Panel am sterben, denn auch die Statuseinheit unten sowie gewisse Funktionen laufen nicht mehr.
Aber nur beim betroffenem Host, bei den anderen verhält es sich normal.

AST · Oct 8, 2020

Damit man sich das besser vorstellen kann:

VS

oguz · Oct 8, 2020

LachCraft said:
PS: Offenbar ist das ganze Panel am sterben, denn auch die Statuseinheit unten sowie gewisse Funktionen laufen nicht mehr.
Aber nur beim betroffenem Host, bei den anderen verhält es sich normal.

was steht in /etc/hosts bei diesem host?

kannst du z.b. von pve3 nach pve2 eine ssh verbindung machen? das sollte normalerweise ohne interaktion funktionieren

AST · Oct 8, 2020

Das versuchte ich eigentlich darzustellen: PVE1 darf/kann nicht mehr zu anderen hosts, inzwischen kommt:

Die anderen Hosts (PVE2-4) funktionieren und können auch den Problemserver PVE1 erreichen.

Gesamtübersicht von PVE2 aus:

oguz · Oct 8, 2020

ok. was steht in /etc/hosts ?

LachCraft said:
Die anderen Hosts (PVE2-4) funktionieren und können auch den Problemserver PVE1 erreichen.

ueber ssh? z.b. von pve4 nach pve1: ssh root@10.16.0.101 geht ?

die VMs mit NAS disk, sind die momentan online? kannst du schauen ob es funktioniert wenn die VMs abgeschaltet sind?

LachCraft said:
Das versuchte ich eigentlich darzustellen: PVE1 darf/kann nicht mehr zu anderen hosts, inzwischen kommt:

diese fehlermeldung heisst meistens dass der pveproxy service nicht am laufen ist. kannst du in systemctl schauen?

AST · Oct 8, 2020

> ueber ssh? z.b. von pve4 nach pve1: ssh root@10.16.0.101 geht ?

> die VMs mit NAS disk, sind die momentan online? kannst du schauen ob es funktioniert wenn die VMs abgeschaltet sind?
Die sind quasi als Task noch am laufen, lassen sich aber im PVE nicht steuern und die Maschinen selbst sind auch unbenutzbar (als ob die Platte geklaut worden ist). Die Maschine reagiert soviel wie noch im RAM steckt, Zugriffe auf die Disk sind aber nicht gegeben.

> diese fehlermeldung heisst meistens dass der pveproxy service nicht am laufen ist. kannst du in systemctl schauen?

oguz · Oct 8, 2020

hmm...

LachCraft said:
Die sind quasi als Task noch am laufen, lassen sich aber im PVE nicht steuern und die Maschinen selbst sind auch unbenutzbar (als ob die Platte geklaut worden ist). Die Maschine reagiert soviel wie noch im RAM steckt, Zugriffe auf die Disk sind aber nicht gegeben.

kannst du qm stop VMID probieren? und schauen ob das verhalten sich veraendert.

AST · Oct 8, 2020

Bereits versucht, kommt jeweils jenes:

oguz · Oct 8, 2020

versuch mal:

Code:

ps -ef | grep kvm # schau die PID fuer den prozess
kill -9 PID # kill

AST · Oct 8, 2020

Nun ist die VM zwar aus, aber starten lässt sie sich auch nicht.

oguz · Oct 8, 2020

was sagt systemctl status pve-cluster und pvecm status ?

und koenntest du die VM config auch schicken: qm config VMID

(alles bei pve1 ausfuehren)

AST · Oct 8, 2020

Ich habe eben versucht den pvedeamon neuzustarten. Da kommt gar keine Reaktion bei herum.
Meines Wissens ist der deamon die Schnittstelle Interfaces<-->Rootrechte. Das würde zumindest das Unvermögen bei den lockdateien erklären.

AST · Oct 8, 2020

So nebenbei: Das Webpanel vom ersten Host ist noch unbenutzbar.

oguz · Oct 8, 2020

bitte syslog von pve1 posten, vielleicht hast du was uebersehen

AST · Oct 8, 2020

Die syslogs von gestern und heute.

oguz · Oct 8, 2020

in deinen logs sehe ich (heute):

Code:

Oct  8 14:45:52 pve1 systemd[1]: pvedaemon.service: State 'stop-sigterm' timed out. Killing.
Oct  8 14:45:52 pve1 systemd[1]: pvedaemon.service: Killing process 1668722 (pvedaemon worke) with signal SIGKILL.
Oct  8 14:45:52 pve1 systemd[1]: pvedaemon.service: Killing process 1858428 (pvedaemon worke) with signal SIGKILL.
Oct  8 14:45:52 pve1 systemd[1]: pvedaemon.service: Killing process 1897927 (task UPID:pve1:) with signal SIGKILL.
Oct  8 14:45:52 pve1 systemd[1]: pvedaemon.service: Killing process 1903446 (task UPID:pve1:) with signal SIGKILL.
Oct  8 14:45:52 pve1 systemd[1]: pvedaemon.service: Killing process 1924385 (pvedaemon worke) with signal SIGKILL.
Oct  8 14:46:00 pve1 systemd[1]: Starting Proxmox VE replication runner...
Oct  8 14:46:00 pve1 systemd[1]: pvesr.service: Succeeded.
Oct  8 14:46:00 pve1 systemd[1]: Started Proxmox VE replication runner.
Oct  8 14:46:56 pve1 systemd[1]: Started Session 445 of user root.
Oct  8 14:47:00 pve1 systemd[1]: Starting Proxmox VE replication runner...
Oct  8 14:47:00 pve1 systemd[1]: pvesr.service: Succeeded.
Oct  8 14:47:00 pve1 systemd[1]: Started Proxmox VE replication runner.
Oct  8 14:47:23 pve1 systemd[1]: pvedaemon.service: Processes still around after SIGKILL. Ignoring.
Oct  8 14:48:00 pve1 systemd[1]: Starting Proxmox VE replication runner...
Oct  8 14:48:00 pve1 systemd[1]: pvesr.service: Succeeded.
Oct  8 14:48:00 pve1 systemd[1]: Started Proxmox VE replication runner.
Oct  8 14:48:53 pve1 systemd[1]: pvedaemon.service: State 'stop-final-sigterm' timed out. Killing.
Oct  8 14:48:53 pve1 systemd[1]: pvedaemon.service: Killing process 1668722 (pvedaemon worke) with signal SIGKILL.
Oct  8 14:48:53 pve1 systemd[1]: pvedaemon.service: Killing process 1858428 (pvedaemon worke) with signal SIGKILL.
Oct  8 14:48:53 pve1 systemd[1]: pvedaemon.service: Killing process 1897927 (task UPID:pve1:) with signal SIGKILL.
Oct  8 14:48:53 pve1 systemd[1]: pvedaemon.service: Killing process 1903446 (task UPID:pve1:) with signal SIGKILL.
Oct  8 14:48:53 pve1 systemd[1]: pvedaemon.service: Killing process 1924385 (pvedaemon worke) with signal SIGKILL.
Oct  8 14:49:00 pve1 systemd[1]: Starting Proxmox VE replication runner...
Oct  8 14:49:00 pve1 systemd[1]: pvesr.service: Succeeded.
Oct  8 14:49:00 pve1 systemd[1]: Started Proxmox VE replication runner.
Oct  8 14:50:00 pve1 systemd[1]: Starting Proxmox VE replication runner...
Oct  8 14:50:00 pve1 systemd[1]: pvesr.service: Succeeded.
Oct  8 14:50:00 pve1 systemd[1]: Started Proxmox VE replication runner.
Oct  8 14:50:23 pve1 systemd[1]: pvedaemon.service: Processes still around after final SIGKILL. Entering failed mode.
Oct  8 14:50:23 pve1 systemd[1]: pvedaemon.service: Failed with result 'exit-code'.
Oct  8 14:50:23 pve1 systemd[1]: Failed to start PVE API Daemon.
Oct  8 14:50:23 pve1 systemd[1]: pvedaemon.service: Service RestartSec=100ms expired, scheduling restart.
Oct  8 14:50:23 pve1 systemd[1]: pvedaemon.service: Scheduled restart job, restart counter is at 3.
Oct  8 14:50:23 pve1 systemd[1]: Stopped PVE API Daemon.
Oct  8 14:50:23 pve1 systemd[1]: pvedaemon.service: Found left-over process 1668722 (pvedaemon worke) in control group while starting unit. Ignoring.
Oct  8 14:50:23 pve1 systemd[1]: This usually indicates unclean termination of a previous run, or service implementation deficiencies.
Oct  8 14:50:23 pve1 systemd[1]: pvedaemon.service: Found left-over process 1858428 (pvedaemon worke) in control group while starting unit. Ignoring.
Oct  8 14:50:23 pve1 systemd[1]: This usually indicates unclean termination of a previous run, or service implementation deficiencies.
Oct  8 14:50:23 pve1 systemd[1]: pvedaemon.service: Found left-over process 1897927 (task UPID:pve1:) in control group while starting unit. Ignoring.
Oct  8 14:50:23 pve1 systemd[1]: This usually indicates unclean termination of a previous run, or service implementation deficiencies.
Oct  8 14:50:23 pve1 systemd[1]: pvedaemon.service: Found left-over process 1903446 (task UPID:pve1:) in control group while starting unit. Ignoring.
Oct  8 14:50:23 pve1 systemd[1]: This usually indicates unclean termination of a previous run, or service implementation deficiencies.
Oct  8 14:50:23 pve1 systemd[1]: pvedaemon.service: Found left-over process 1924385 (pvedaemon worke) in control group while starting unit. Ignoring.
Oct  8 14:50:23 pve1 systemd[1]: This usually indicates unclean termination of a previous run, or service implementation deficiencies.

von gestern sieht dieser teil nicht gut aus:

Code:

Oct  7 11:43:32 pve1 kernel: [1206901.259669] INFO: task kvm:3609474 blocked for more than 120 seconds.
Oct  7 11:43:32 pve1 kernel: [1206901.259695]       Tainted: P           O      5.4.60-1-pve #1
Oct  7 11:43:32 pve1 kernel: [1206901.259708] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
Oct  7 11:43:32 pve1 kernel: [1206901.259725] kvm             D    0 3609474      1 0x00004002
Oct  7 11:43:32 pve1 kernel: [1206901.259727] Call Trace:
Oct  7 11:43:32 pve1 kernel: [1206901.259738]  __schedule+0x2e6/0x6f0
Oct  7 11:43:32 pve1 kernel: [1206901.259739]  schedule+0x33/0xa0
Oct  7 11:43:32 pve1 kernel: [1206901.259741]  io_schedule+0x16/0x40
Oct  7 11:43:32 pve1 kernel: [1206901.259746]  wait_on_page_bit+0x141/0x210
Oct  7 11:43:32 pve1 kernel: [1206901.259748]  ? file_fdatawait_range+0x30/0x30
Oct  7 11:43:32 pve1 kernel: [1206901.259751]  wait_on_page_writeback+0x43/0x90
Oct  7 11:43:32 pve1 kernel: [1206901.259752]  __filemap_fdatawait_range+0xae/0x120
Oct  7 11:43:32 pve1 kernel: [1206901.259754]  file_write_and_wait_range+0xa0/0xc0
Oct  7 11:43:32 pve1 kernel: [1206901.259772]  nfs_file_fsync+0x33/0x1a0 [nfs]
Oct  7 11:43:32 pve1 kernel: [1206901.259776]  vfs_fsync_range+0x48/0x80
Oct  7 11:43:32 pve1 kernel: [1206901.259778]  ? __fget_light+0x59/0x70
Oct  7 11:43:32 pve1 kernel: [1206901.259779]  do_fsync+0x3d/0x70
Oct  7 11:43:32 pve1 kernel: [1206901.259780]  __x64_sys_fdatasync+0x17/0x20
Oct  7 11:43:32 pve1 kernel: [1206901.259785]  do_syscall_64+0x57/0x190
Oct  7 11:43:32 pve1 kernel: [1206901.259786]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
Oct  7 11:43:32 pve1 kernel: [1206901.259787] RIP: 0033:0x7fc0764dc2e7
Oct  7 11:43:32 pve1 kernel: [1206901.259789] Code: b8 4b 00 00 00 0f 05 48 3d 00 f0 ff ff 77 3c c3 0f 1f 00 53 89 fb 48 83 ec 10 e8 74 54 01 00 89 df 89 c2 b8 4b 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 2b 89 d7 89 44 24 0c e8 b6 54 01 00 8b 44 24
Oct  7 11:43:32 pve1 kernel: [1206901.259790] RSP: 002b:00007fbc271f59c0 EFLAGS: 00000293 ORIG_RAX: 000000000000004b
Oct  7 11:43:32 pve1 kernel: [1206901.259791] RAX: ffffffffffffffda RBX: 000000000000006e RCX: 00007fc0764dc2e7
Oct  7 11:43:32 pve1 kernel: [1206901.259792] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 000000000000006e
Oct  7 11:43:32 pve1 kernel: [1206901.259793] RBP: 00007fbc52b27d30 R08: 0000000000000000 R09: 00000000ffffffff
Oct  7 11:43:32 pve1 kernel: [1206901.259793] R10: 00007fbc271f59b0 R11: 0000000000000293 R12: 0000560757aed272
Oct  7 11:43:32 pve1 kernel: [1206901.259794] R13: 00007fbc52b27d98 R14: 00007fc06acd6ae0 R15: 0000560757ae9762

probier mal:

Code:

systemctl restart pve-cluster
systemctl restart pvedaemon
systemctl restart pveproxy
systemctl restart pvestatd

(reihe ist wichtig)

AST · Oct 8, 2020

Dein snipped von heute: Um 14:xx (ich sollte Buch führen...) hatte ich erfolglos versucht den Deamon neuzustarten.

and here we go again:

PVE verliert(?) Verbindung zum NFS

Well-Known Member

Proxmox Retired Staff

Well-Known Member

Well-Known Member

Well-Known Member

Proxmox Retired Staff

Well-Known Member

Proxmox Retired Staff

Well-Known Member

Proxmox Retired Staff

Well-Known Member

Proxmox Retired Staff

Well-Known Member

Proxmox Retired Staff

Well-Known Member

Well-Known Member

Proxmox Retired Staff

Well-Known Member

Attachments

Proxmox Retired Staff

Well-Known Member