14
Veeam 11 und vSphere 7.0.2
Moin,
ich habe seit dem Upgrade auf vSphere 7.0.2 (ESXi 7.0.2 und vCenter Appliance 7.0.2) ein Phänomen, für das ich noch keine Erklärung gefunden habe.
Wir sichern unsere Umgebung mit Veeam 11 (aktueller Patch-Level).
Jetzt kommt es gelegentlich vor (bei unterschiedlichen VMs), dass ich die Meldung erhalte, im ersten Versuch war das Erstellen oder Sichern des Snapshots nicht möglich.
Zum Einsatz kommen bei uns 3(!) Backup-Proxies für 17 produktive Maschinen. Ich weiß, dass ist overpowered, aber weniger kann ich immer noch bauen.
Die Proxies sind 2x Ubuntu 20.04. LTS VMs und 1x Windows VM (unser WSUS).
Die VMs, die Probleme machen bei der Sicherung, sind sowohl Hardware-Level 6.7U2, als auch 7.0.2.
Seltsamerweise gibt es Tage, da läuft es ohne Fehlermeldung durch, dann wieder tagelang mit min. 1 VM erst im 2. Versuch.
Die Sicherung an sich funktioniert und das Recovery auch (musste ich leider schon mal testen.....).
Die Fehlermeldung im Detail:
Der vCenterServer läuft bei mir schon mit 2 Cores und 16GB RAM (was über der Empfehlung für unsere Umgebung liegt).
Die Proxies sind auf 2 parallele Tasks / Proxy limitiert.
Hat das noch jemand beobachten können in dieser Konfiguration? Vergleiche zu 6.7U2-Umgebungen bringen nichts, denn dort funktionierten 10 parallele Tasks über 1 (!) Proxy reibungslos, weswegen ich auf das vCenter tippe.
Gruß
Looser
ich habe seit dem Upgrade auf vSphere 7.0.2 (ESXi 7.0.2 und vCenter Appliance 7.0.2) ein Phänomen, für das ich noch keine Erklärung gefunden habe.
Wir sichern unsere Umgebung mit Veeam 11 (aktueller Patch-Level).
Jetzt kommt es gelegentlich vor (bei unterschiedlichen VMs), dass ich die Meldung erhalte, im ersten Versuch war das Erstellen oder Sichern des Snapshots nicht möglich.
Zum Einsatz kommen bei uns 3(!) Backup-Proxies für 17 produktive Maschinen. Ich weiß, dass ist overpowered, aber weniger kann ich immer noch bauen.
Die Proxies sind 2x Ubuntu 20.04. LTS VMs und 1x Windows VM (unser WSUS).
Die VMs, die Probleme machen bei der Sicherung, sind sowohl Hardware-Level 6.7U2, als auch 7.0.2.
Seltsamerweise gibt es Tage, da läuft es ohne Fehlermeldung durch, dann wieder tagelang mit min. 1 VM erst im 2. Versuch.
Die Sicherung an sich funktioniert und das Recovery auch (musste ich leider schon mal testen.....).
Die Fehlermeldung im Detail:
Failed to create VM snapshot. Error: CreateSnapshot failed, vmRef vm-5031, timeout 1800000, snName VEEAM BACKUP TEMPORARY SNAPSHOT, snDescription Please do not delete this snapshot. It is being used by Veeam Backup., memory False, quiesce False
Error: An error occurred while saving the snapshot: Could not open or create change tracking file. (An error occurred while saving the snapshot: Could not open or create change tracking file., An error occurred while taking a snapshot: Could not open or create change tracking file.)Der vCenterServer läuft bei mir schon mit 2 Cores und 16GB RAM (was über der Empfehlung für unsere Umgebung liegt).
Die Proxies sind auf 2 parallele Tasks / Proxy limitiert.
Hat das noch jemand beobachten können in dieser Konfiguration? Vergleiche zu 6.7U2-Umgebungen bringen nichts, denn dort funktionierten 10 parallele Tasks über 1 (!) Proxy reibungslos, weswegen ich auf das vCenter tippe.
Gruß
Looser
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 666033
Url: https://administrator.de/contentid/666033
Printed on: April 19, 2024 at 22:04 o'clock
14 Comments
Latest comment
Hi,
zu dem Fehler weiß ich leider nichts, aber ich rate dir dich einfach bei dem Veeam Support zu melden.
Die waren bisher bei mir immer sehr kompetent und die Fehler konnten gelöst werden
VG
Deepsys
zu dem Fehler weiß ich leider nichts, aber ich rate dir dich einfach bei dem Veeam Support zu melden.
Die waren bisher bei mir immer sehr kompetent und die Fehler konnten gelöst werden
VG
Deepsys
Moin,
ich habe mal ein Ticket aufgemacht. Mal sehen, mit welchen Vorschlägen die um die Ecke kommen....
Gruß
Looser
ich habe mal ein Ticket aufgemacht. Mal sehen, mit welchen Vorschlägen die um die Ecke kommen....
Gruß
Looser
Hallo,
m.W wird ESXi 7 Update 2 noch nicht mit Veeam V11 supported.
Zudem hatte VMWare doch das ESXi Update 2 zurückgezogen, oder?
Gruß
m.W wird ESXi 7 Update 2 noch nicht mit Veeam V11 supported.
Zudem hatte VMWare doch das ESXi Update 2 zurückgezogen, oder?
Gruß
Moin,
exakt diese Meldung hatten wir auch schon einmal - mit VEEAM 10 und ESXi 7.0.x (hab vergessen, ob es schon due U2 war oder nicht).
Ich meine mich erinnern zu können, dass ich die VM nicht mehr via VSS (also stillegen der VM) sichere, sondern "normal".
Oder es war umgekehrt.
Prüfe mal, ob die VMware-Tools in der VM auf aktuellem Stand sind.
Gruß
em-pie
exakt diese Meldung hatten wir auch schon einmal - mit VEEAM 10 und ESXi 7.0.x (hab vergessen, ob es schon due U2 war oder nicht).
Ich meine mich erinnern zu können, dass ich die VM nicht mehr via VSS (also stillegen der VM) sichere, sondern "normal".
Oder es war umgekehrt.
Prüfe mal, ob die VMware-Tools in der VM auf aktuellem Stand sind.
Gruß
em-pie
Moin,
@em-pie: Meinst Du die Funktion VMWare Tools quiescence? Das ist bislang deaktiviert.
VM-Ware-Tools werden allesamt vom OS verwaltet (Linux-Maschinen mit Cent-OS und Ubuntu).
Scheinen aber aktuell zu sein, denn nach einer Aktualisierung und anschließendem Neustart ergibt sich keine Änderung der Versionsnummer.
Gruß
Looser
@em-pie: Meinst Du die Funktion VMWare Tools quiescence? Das ist bislang deaktiviert.
VM-Ware-Tools werden allesamt vom OS verwaltet (Linux-Maschinen mit Cent-OS und Ubuntu).
Scheinen aber aktuell zu sein, denn nach einer Aktualisierung und anschließendem Neustart ergibt sich keine Änderung der Versionsnummer.
Gruß
Looser
Je länger ich darüber nachdenke, umso mehr tippe ich auf den vCenterServer als Fehlerquelle.
Aus dem Bauch heraus würde ich mal behaupten, dass der mit der CPU/RAM-Ausstattung das gleichzeitige Verarbeiten von 4 SnapShots manchmal nicht hinbekommt (bei evtl. "doofer Kombi").
Ich habe der VM mal CPU&RAM verdoppelt und nur noch einen Task/Proxy eingestellt. Mal sehen ob das damit besser läuft.
Da der Fehler aber nicht permanent auftritt, muss man halt immer ein paar Datensicherungen abwarten.
Aus dem Bauch heraus würde ich mal behaupten, dass der mit der CPU/RAM-Ausstattung das gleichzeitige Verarbeiten von 4 SnapShots manchmal nicht hinbekommt (bei evtl. "doofer Kombi").
Ich habe der VM mal CPU&RAM verdoppelt und nur noch einen Task/Proxy eingestellt. Mal sehen ob das damit besser läuft.
Da der Fehler aber nicht permanent auftritt, muss man halt immer ein paar Datensicherungen abwarten.
Zitat von @Looser27:
@em-pie: Meinst Du die Funktion VMWare Tools quiescence? Das ist bislang deaktiviert.
Ja, genau.@em-pie: Meinst Du die Funktion VMWare Tools quiescence? Das ist bislang deaktiviert.
Wir nutzen die für manche VMs. Bin ir wie gesagt gerade nur nicht sicher, ob die Lösungg war, die betroffenen VMs damit zu sichern oder damit nicht mehr zu sichern...
VM-Ware-Tools werden allesamt vom OS verwaltet (Linux-Maschinen mit Cent-OS und Ubuntu).
Scheinen aber aktuell zu sein, denn nach einer Aktualisierung und anschließendem Neustart ergibt sich keine Änderung der Versionsnummer.
OK. dann sollte es ja passen. Wir machen es genauso: hier setzen wir die Open-VM-Tools ein (geht via apt-get installl...)Scheinen aber aktuell zu sein, denn nach einer Aktualisierung und anschließendem Neustart ergibt sich keine Änderung der Versionsnummer.
Das vCenter würde in der WebGUI auch "meckern" wenn eine aktuellere Version verfügbar wäre - fällt mir gerade ein.
Ich schaue mal, ob ich noch herausfinde, was bei uns die Lösung war. genau das habe ich mir damals nicht notiert *grml*
Kurzer Zwischenstand....mal läuft es fehlerfrei durch....mal nicht. Betroffen sind unterschiedliche Linux-Maschinen. Ich habe jetzt mal die Funktion VMWare Tools quiescence aktiviert und teste mal, ob das Backup damit besser läuft.
Aktuell nach wie vor 3 Proxies mit je 2 Tasks maximal (das das Backup-Ziel aber nur 4 parallele Tasks zuläßt, ist das vernachlässigbar.
Gruß
Looser
P.S.: Im Retry 1 des Backup-Jobs werden die im ersten Versuch fehlgeschlagenen Backups aber problemlos gesichert. Ich habe nur das Nadelöhr noch nicht gefunden, was den Fehler verursacht.
Aktuell nach wie vor 3 Proxies mit je 2 Tasks maximal (das das Backup-Ziel aber nur 4 parallele Tasks zuläßt, ist das vernachlässigbar.
Gruß
Looser
P.S.: Im Retry 1 des Backup-Jobs werden die im ersten Versuch fehlgeschlagenen Backups aber problemlos gesichert. Ich habe nur das Nadelöhr noch nicht gefunden, was den Fehler verursacht.
Gestern habe ich Antwort vom Veeam-Support erhalten, die mich leider NULL weiter gebracht hat. Deren Meinung ist: Es liegt am VCenter.
Heute gab es das erste Patch für das VCenter (7.0U2a). Das spiele ich gerade ein.
Das Backup lief gestern mit der zuletzt gemachten Änderung ( VMWare Tools quiescence aktiviert) fehlerfrei durch.
An dieser Stelle Danke an alle, die geholfen haben. Ich werde die Infos hier ergänzen, sowie ich neue Erkenntnisse gewonnen habe.
Gruß
Looser
Heute gab es das erste Patch für das VCenter (7.0U2a). Das spiele ich gerade ein.
Das Backup lief gestern mit der zuletzt gemachten Änderung ( VMWare Tools quiescence aktiviert) fehlerfrei durch.
An dieser Stelle Danke an alle, die geholfen haben. Ich werde die Infos hier ergänzen, sowie ich neue Erkenntnisse gewonnen habe.
Gruß
Looser
Moin Looser27
Danke dir der Rückmeldung.
Ernüchternde Antwort seitens VEEAM - bin mal gespannt, ob das Problem dann nu wech ist.
Wobei dann die Frage ist: lag es am 7.0U2a oder am aktivierten quiescence !?
Gruß
em-pie
Danke dir der Rückmeldung.
Ernüchternde Antwort seitens VEEAM - bin mal gespannt, ob das Problem dann nu wech ist.
Wobei dann die Frage ist: lag es am 7.0U2a oder am aktivierten quiescence !?
Gruß
em-pie
Wobei dann die Frage ist: lag es am 7.0U2a oder am aktivierten quiescence !?
Das werde ich dann noch herausfinden.
Nachdem mir das Update-Patch meine vCenter Installation zerballert hat, habe ich eben zurückgesichert und belasse es jetzt bei der Version 7.0U2 mit aktiviertem quiescence.
Weitere Tests erst mit der nächsten Version
Weitere Tests erst mit der nächsten Version
Letztes Update:
Nachdem ich letzte Woche die aktuellen Patches auf die ESXi-Hosts aufgespielt hatte, wollte sich ein Host nicht herunterfahren lassen.
Ursache waren hier diverse VM, die vom vCenter zwar heruntergefahren wurden, jedoch nicht in den Status Offline gesetzt wurden.
Nach einem erzwungenen Reboot des Hosts lief aber alles wieder wie gewohnt. Warum ich das schreibe? Seit diesem letzten Einspielen der Patches funktioniert das Veeam B&R 11 mit dem vSphere 7.0.2 wie es sein sollte. Alle VMs werden ohne Fehlermeldung im ersten Versuch gesichert (ohne aktiviertes quiescence).
Von daher gehe ich von einem Bug in der Software des Hosts aus (auf diesem lief die ganze Zeit das vCenter), der o.g. Fehler produziert hat.
Gruß
Looser
Nachdem ich letzte Woche die aktuellen Patches auf die ESXi-Hosts aufgespielt hatte, wollte sich ein Host nicht herunterfahren lassen.
Ursache waren hier diverse VM, die vom vCenter zwar heruntergefahren wurden, jedoch nicht in den Status Offline gesetzt wurden.
Nach einem erzwungenen Reboot des Hosts lief aber alles wieder wie gewohnt. Warum ich das schreibe? Seit diesem letzten Einspielen der Patches funktioniert das Veeam B&R 11 mit dem vSphere 7.0.2 wie es sein sollte. Alle VMs werden ohne Fehlermeldung im ersten Versuch gesichert (ohne aktiviertes quiescence).
Von daher gehe ich von einem Bug in der Software des Hosts aus (auf diesem lief die ganze Zeit das vCenter), der o.g. Fehler produziert hat.
Gruß
Looser
Moin,
danke dir der Rückmeldung.
Dann kann ich ein VEEAM Upgrade ja auch mal einplanen.
Derzeit rennt unser vCenter auch auf der 7.0.2, VEEAM jedoch auf 10.irgendwas...
danke dir der Rückmeldung.
Dann kann ich ein VEEAM Upgrade ja auch mal einplanen.
Derzeit rennt unser vCenter auch auf der 7.0.2, VEEAM jedoch auf 10.irgendwas...
