VM mit PBS stopt sändig

[Haxley]

Hallo Allen,
ich habe auf einer Proxmox Maschine TruNAS und den PBS virtuell laufen.
PBS greift auf den Speicher des NAS via NFS zu. Funktioniert soweit auch alles. Da die Beiden VM auf einer Maschine liegen läuft das soweit.

Ich habe aber zwei Probleme.
1. Nach eine Stromausfall startet der PBS nicht da das einzubindende NFS vom gleichzeitig gestarteten TrueNAS noch nicht zur Verfügung steht. Ideal wäre hier das die VM mit dem PBS verzögert startet. Geht das?

2. PBS stopt fast einmal täglich aus unbekannten Grund. Im Journal finde ich nichts. Starte ich PBS manuell läuft alles wieder. Hat dieses Erleben noch jemand mit einer ähnlichen Konstellation?
- Strom fällt nicht täglich 1x aus ;-)
- NFS sollte auch nicht einfach so aufhören zu existieren
- einziges Anzeichen ist eine Update Info von Proxmox zum vermutlichen Stop des PBS aber kein Fehler.

Lieben Dank
Gruß Haxley

 

[Folke]

Hallo Haxley,

Ideal wäre hier das die VM mit dem PBS verzögert startet. Geht das?

Jupp, die Option gibt es in den Optionen der Node unter Start/Shutdown order. Da kann auch eine Verzögerung eingestellt werden.

PBS stopt fast einmal täglich aus unbekannten Grund.

Kannst du mal den Syslog der VM und des Hosts um den Zeitraum eines Stops posten? Der Fehler muss nicht unbedingt im Journal von Proxmox zu finden sein.

 

[Falk R.]

Ich frage mich, warum tust du so etwas?
Backups auf die gleiche Maschine wie Prouktivadaten zu machen, macht keinen Sinn. Wenn die Disks eh im gleichen System sind, warum dann der Umweg über NFS, was ja extrem bremst?

 

[Haxley]

Ich frage mich, warum tust du so etwas?
Backups auf die gleiche Maschine wie Prouktivadaten zu machen, macht keinen Sinn. Wenn die Disks eh im gleichen System sind, warum dann der Umweg über NFS, was ja extrem bremst?

Wer sagt das das so ist?
Ich habe mehrere Webserver auf anderen physischen Servern. Extra habe ich ein NAS was ich zum zwischenspeichern nutze, das wiederum wird dann gebackupt. Auf dem NAS Server läuft halt eine VM mit PBS die das NAS mit nutzt.

 

[Haxley]

Zum Log... im PBS selbst steht nichts drin. der letzte Eintrag ist Task OK und dann folgt der Neustart.
Der Host erzählt mir da schon mehr. 101 ist übrigens der PBS

ES scheint mit dem Speicher was nicht zu stimmen.
die Maschine hat 64GB RAM, zugewiesen sind davon:
VM100 NAS hat 40GB (verwaltet durchgereichte HDD mit ZFS)
VM101 PBS hat 32GB
Vermutlich geht bei beiden der RAM Verbrauch hoch wenn der PBS Backups erstellt und das NAS ins ZFS schreibt. Normalerweise sollte doch Ballooning sowas verhindern. Tut es aber irgendwie nicht.
Liege ich richtig? Jemand Ideen?

Mar 19 21:12:46 nas kernel: Tasks state (memory values in pages):
Mar 19 21:12:46 nas kernel: [  pid  ]   uid  tgid total_vm      rss pgtables_bytes swapents oom_score_adj name
Mar 19 21:12:46 nas kernel: [    673]     0   673    51292      224   425984        0          -250 systemd-journal
Mar 19 21:12:46 nas kernel: [    693]     0   693     6698      320    73728        0         -1000 systemd-udevd
Mar 19 21:12:46 nas kernel: [   1081]   103  1081     1969      160    53248        0             0 rpcbind
Mar 19 21:12:46 nas kernel: [   1084]   101  1084     2314      128    53248        0          -900 dbus-daemon
Mar 19 21:12:46 nas kernel: [   1087]     0  1087    38187       64    57344        0         -1000 lxcfs
Mar 19 21:12:46 nas kernel: [   1089]     0  1089    69539      128    90112        0             0 pve-lxc-syscall
Mar 19 21:12:46 nas kernel: [   1091]     0  1091     1766      147    49152        0             0 ksmtuned
Mar 19 21:12:46 nas kernel: [   1094]     0  1094     3002      576    65536        0             0 smartd
Mar 19 21:12:46 nas kernel: [   1095]     0  1095     1327      160    49152        0             0 qmeventd
Mar 19 21:12:46 nas kernel: [   1100]     0  1100     4293      288    73728        0             0 systemd-logind
Mar 19 21:12:46 nas kernel: [   1104]     0  1104      583       64    40960        0         -1000 watchdog-mux
Mar 19 21:12:46 nas kernel: [   1241]     0  1241     1256       64    49152        0             0 lxc-monitord
Mar 19 21:12:46 nas kernel: [   1255]     0  1255     1468       96    45056        0             0 agetty
Mar 19 21:12:46 nas kernel: [   1261]     0  1261     3853      448    65536        0         -1000 sshd
Mar 19 21:12:46 nas kernel: [   1280]   100  1280     4715      170    61440        0             0 chronyd
Mar 19 21:12:46 nas kernel: [   1281]   100  1281     2633      178    61440        0             0 chronyd
Mar 19 21:12:46 nas kernel: [   1329]     0  1329   200274      307   180224        0             0 rrdcached
Mar 19 21:12:46 nas kernel: [   1345]     0  1345   143683    12509   348160        0             0 pmxcfs
Mar 19 21:12:46 nas kernel: [   1436]     0  1436    10664      198    69632        0             0 master
Mar 19 21:12:46 nas kernel: [   1438]   104  1438    10774      224    73728        0             0 qmgr
Mar 19 21:12:46 nas kernel: [   1443]     0  1443     1652      128    49152        0             0 cron
Mar 19 21:12:46 nas kernel: [   1450]     0  1450    39342    24081   286720        0             0 pve-firewall
Mar 19 21:12:46 nas kernel: [   1454]     0  1454      615       32    40960        0             0 bpfilter_umh
Mar 19 21:12:46 nas kernel: [   1460]     0  1460    37469    23850   344064        0             0 pvestatd
Mar 19 21:12:46 nas kernel: [   1481]     0  1481    58287    33510   458752        0             0 pvedaemon
Mar 19 21:12:46 nas kernel: [   1490]    33  1490    58671    33868   454656        0             0 pveproxy
Mar 19 21:12:46 nas kernel: [   1497]    33  1497    20206    12608   204800        0             0 spiceproxy
Mar 19 21:12:46 nas kernel: [   1534]     0  1534 10559244  6211111 65187840        0             0 kvm
Mar 19 21:12:46 nas kernel: [   1753]     0  1753    53627    27639   413696        0             0 pvescheduler
Mar 19 21:12:46 nas kernel: [1920725]     0 1920725    60164      320    86016        0             0 zed
Mar 19 21:12:46 nas kernel: [1275449]     0 1275449 14928717  9755461 80814080        0             0 kvm
Mar 19 21:12:46 nas kernel: [1456067]     0 1456067    60904    34310   450560        0             0 pvedaemon worke
Mar 19 21:12:46 nas kernel: [1456068]     0 1456068    60528    33835   466944        0             0 pvedaemon worke
Mar 19 21:12:46 nas kernel: [1456069]     0 1456069    60995    34342   442368        0             0 pvedaemon worke
Mar 19 21:12:46 nas kernel: [1456109]     0 1456109    54685    27202   356352        0             0 pve-ha-lrm
Mar 19 21:12:46 nas kernel: [1456171]     0 1456171    54834    27370   385024        0             0 pve-ha-crm
Mar 19 21:12:46 nas kernel: [1663695]     0 1663695    19796       64    53248        0             0 pvefw-logger
Mar 19 21:12:46 nas kernel: [1663702]    33 1663702    20272    12632   188416        0             0 spiceproxy work
Mar 19 21:12:46 nas kernel: [1663707]    33 1663707    58704    33911   421888        0             0 pveproxy worker
Mar 19 21:12:46 nas kernel: [1663708]    33 1663708    58704    33911   421888        0             0 pveproxy worker
Mar 19 21:12:46 nas kernel: [1663709]    33 1663709    58704    33879   421888        0             0 pveproxy worker
Mar 19 21:12:46 nas kernel: [2094532]   104 2094532    10764      160    77824        0             0 pickup
Mar 19 21:12:46 nas kernel: [2119046]     0 2119046     1366        0    53248        0             0 sleep
Mar 19 21:12:46 nas kernel: oom-kill:constraint=CONSTRAINT_NONE,nodemask=(null),cpuset=pve-cluster.service,mems_allowed=0,global_oom,task_memcg=/qemu.slice/101.scope,task=kvm,pid=1275449,uid=0
Mar 19 21:12:46 nas kernel: Out of memory: Killed process 1275449 (kvm) total-vm:59714868kB, anon-rss:39021844kB, file-rss:0kB, shmem-rss:0kB, UID:0 pgtables:78920kB oom_score_adj:0
Mar 19 21:12:46 nas kernel:  zd16: p1 p2 p3
Mar 19 21:12:46 nas kernel: fwbr101i0: port 2(tap101i0) entered disabled state
Mar 19 21:12:46 nas kernel: tap101i0 (unregistering): left allmulticast mode
Mar 19 21:12:46 nas kernel: fwbr101i0: port 2(tap101i0) entered disabled state
Mar 19 21:12:46 nas systemd[1]: 101.scope: A process of this unit has been killed by the OOM killer.
Mar 19 21:12:46 nas systemd[1]: 101.scope: Failed with result 'oom-kill'.
Mar 19 21:12:46 nas systemd[1]: 101.scope: Consumed 4h 13min 18.554s CPU time.
Mar 19 21:12:46 nas lvm[2119290]: /dev/zd16p3 excluded: device is rejected by filter config.
Mar 19 21:12:47 nas qmeventd[2119273]: Starting cleanup for 101
Mar 19 21:12:47 nas kernel: fwbr101i0: port 1(fwln101i0) entered disabled state
Mar 19 21:12:47 nas kernel: vmbr0: port 3(fwpr101p0) entered disabled state
Mar 19 21:12:47 nas kernel: fwln101i0 (unregistering): left allmulticast mode
Mar 19 21:12:47 nas kernel: fwln101i0 (unregistering): left promiscuous mode
Mar 19 21:12:47 nas kernel: fwbr101i0: port 1(fwln101i0) entered disabled state
Mar 19 21:12:47 nas kernel: fwpr101p0 (unregistering): left allmulticast mode
Mar 19 21:12:47 nas kernel: fwpr101p0 (unregistering): left promiscuous mode
Mar 19 21:12:47 nas kernel: vmbr0: port 3(fwpr101p0) entered disabled state
Mar 19 21:12:48 nas kernel: oom_reaper: reaped process 1275449 (kvm), now anon-rss:0kB, file-rss:0kB, shmem-rss:0kB
Mar 19 21:12:48 nas qmeventd[2119273]: Finished cleanup for 101
Mar 19 21:12:56 nas pvestatd[1460]: backup: error fetching datastores - 500 Can't connect to 192.168.0.63:8007 (Connection timed out)
Mar 19 21:12:56 nas pvestatd[1460]: status update time (7.222 seconds)
Mar 19 21:13:06 nas pvestatd[1460]: backup: error fetching datastores - 500 Can't connect to 192.168.0.63:8007 (Connection timed out)

 

[fabian]

deinem node geht der RAM aus, daher wird die VM vom OOM-killer abgeschossen..

 

[Falk R.]

Wer sagt das das so ist?
Ich habe mehrere Webserver auf anderen physischen Servern. Extra habe ich ein NAS was ich zum zwischenspeichern nutze, das wiederum wird dann gebackupt. Auf dem NAS Server läuft halt eine VM mit PBS die das NAS mit nutzt.

Das liest sich halt so und wenn man keine weiteren Informationen hat, muss man sich das aus dem geschriebenen zusammendenken. Ich verstehe immer noch nicht warum du das NFS nutzt.
Mit ZFS immer den ARC begrenzen und nie mehr RAM als vorhanden verplanen. CPU kann man überprovisionieren, RAM ist aber endlich.