Aktionen

Proxmox Veeam - Failed to prepare the worker - Failed to synchronize configuration settings of the worker - can't lock file - got timeout

Aus znilwiki

Version vom 2. Mai 2025, 11:09 Uhr von BLinz (Diskussion | Beiträge) (Die Seite wurde neu angelegt: „<u>'''Changelog:'''</u><br> * 02.05.2025 erste Version ---- ==Problem== Veeam Backup & Replication sichert Proxmox in dem auf jedem PVE eine sogenannter "Proxmox VE Worker" deployed wird:<br> :Datei:ClipCapIt-250502-105130.PNG<br> Diese VMs sind im Normalfall ausgeschaltet und werden nur für die Backups gestartet und nach der Sicherung wieder beendet.<br> Nun habe ich schon seit Anfang an das Problem, das nach ein paar Tagen und vorzugsweise auf dem…“)
(Unterschied) ← Nächstältere Version | Aktuelle Version (Unterschied) | Nächstjüngere Version → (Unterschied)

Changelog:

  • 02.05.2025 erste Version

Problem

Veeam Backup & Replication sichert Proxmox in dem auf jedem PVE eine sogenannter "Proxmox VE Worker" deployed wird:


Diese VMs sind im Normalfall ausgeschaltet und werden nur für die Backups gestartet und nach der Sicherung wieder beendet.
Nun habe ich schon seit Anfang an das Problem, das nach ein paar Tagen und vorzugsweise auf dem ersten System folgender Fehler auftrat:

01.05.2025 12:00:34 :: PiHolePM : An unknown Proxmox VE error has occurred  
01.05.2025 12:00:35 :: Failed to prepare the worker PVEWorker229: Failed to synchronize configuration settings of the worker PVEWorker229 can't lock file '/var/lock/qemu-server/lock-101.conf' - got timeout
01.05.2025 12:04:06 :: There are no available workers in the cluster proxmox01. Performance may be affected  

In der Proxmox VE / PVE Konsole iseht man wie er versucht die PVE-Worker VM zu starten, schafft es aber nicht.
Die einzige Abhilfe bei mir war es, den PVE Host einmal nur zu starten (wohl dem der die VMs vorher verschieben kann).
In den Foren fand ich keine Lösung gegen die Ursache. Die ist wohl das Veeam die PVEWorker auch während des Jobs mehrmals startet, stoppt und wieder startet. Irgendwann ist das Timing unglücklich so das es hängt.


Pflaster drauf - ein Workaround

Die Lösung aus den Foren die wohl am besten funktioniert, ist die PVEWorker nicht beenden zu lassen, sondern die VMs durchlaufen zu lassen.
Das erreichen wir indem wir unter Veeam die folgende Datei bearbeiten (also auf der Windows Maschine auf der Veeam Backup & Replication installiert ist):

C:\Program Files\Veeam\Plugins\PVE\Service\appsettings.json

Dort suchen wir den Abschnitt

  "Workers": {
   "IpDiscoveryTimeout": "10 min",
   "CheckIpDiscoveredInterval": "5 sec",
   "RollbackOnUpgradeFailed": true,
   "RemoveVmOnFailedDeploy": true,
   "StartedOnAnotherHostSeverity": "Error",
   "DownloadFullLogsOnTest": false,
   "Vm": {
     "DefaultMaxConcurrentTasks": 4,
     "MemoryMbPerTask": 1024,
     "CpuPerTask": 1,
     "BaseCpu": 2,
     "BaseMemoryGb": 2,
     "KeepTurnedOn": false,
     "CustomValues": {},
     "HotPlugPortsCount": 140,
     "FirstAvailablePcieAddress": 6,
     "PcieAddressesInUse": "0x8,0xa,0x12",
     "AllowAnyStorage": false,
     "CloudinitDriveBus": "ide",
     "CloudinitDriveIndex": 2,
     "VcpuSocketsOverrideToCores": false
   }

bei mir ab Zeile 139 und ändern den folgenden Eintrag

"KeepTurnedOn": true,

Danach den Server neu starten, alternativ zumindest den Dienst

Veeam PVE Service

Bei der nächsten Ausführung sollte er die PVEWorker starten und danach eingeschaltet lassen.
Die Worker werden in Veeam nun auch mit einen grünen Kreis dargestellt und können nicht mehr bearbeitet werden:



Neue Probleme durch die Lösung

Ab nun seit Ihr dafür verantwortlich das die Worker laufen!
Ich hatte heute Nacht den Fehler

01.05.2025 19:00:16 :: homeassistent : Ein Verbindungsversuch ist fehlgeschlagen, da die Gegenstelle nach einer bestimmten Zeitspanne nicht richtig reagiert hat, oder die hergestellte Verbindung war fehlerhaft, da der verbundene Host nicht reagiert hat. [::ffff:192.168.0.215]:19000

Was daran lag das der PVEWorker mit der IP 192.168.0.215 ausgeschaltet war.
Also nach Updates des PVE Host müsst Ihr die VMs auch wieder anstarten.


Quellen


Kommentare

Loading comments...