Hartnäckiges HyperV Prüfpunktproblem

Michi777

Commander
Registriert
Apr. 2009
Beiträge
2.147
Liebe Community!

Die zweite VEEAM Fernwartung konnte das Problem „nach einem Backup nach Neustart des physischen Servers, können keine Prüfpunkte mehr erstellt werden“ leider trotz Ausarbeitung der Logs und Rücksprache nicht lösen und verwies darauf, dass es ein „Microsoft HyperV Problem“ ist weil dort auch keine Prüfpunkte intern erstellt werden können, jedoch VEEAM als Drittsoftware darauf zugreift.

Bereits versucht/Erkenntnisse:
  • Virtuelle Maschine neu angelegt
  • Vssadmin list writers befehl auf host und virtuellem server (alles stabil und ohne Fehler)
  • Problem tritt auf allen virtuellen Servern auf (3x Server 2019 und 1x Server 2012R2)
  • Problem tritt unabhängig von Produktionsprüfpunkten\ApplicationAwareeinstellung\Standardprüfüunkten auf
  • Nur nach einem Neustart des physischen Hostservers kann ich einmalig erfolgreich ein VEEAM Backup\Prüfpunkt machen, danach kommt immer Fehler
  • Es wirkt als würde es ein HyperV Problem im Bezug auf Freigabe\Zusammenführen von Prüfpunkt (.avhdx) und virtuellem Server (.vhdx) haben
  • Die VEEAM Technikerin investierte bereits 4h in das Problem und konnte es nicht lösen, da es bei HyperV (Microsoft) hakt (im Anhang ihre Zusammenfassung).
  • Es bleibt auch die .avhdx Datei in HyperV geladen (weiß nicht ob\wann Diese auf .vhdx sich abändern sollte)
  • Neueste Windows – und VEEAM B&R 9.5 Updates eingespielt
  • Es ist ein HP DL380G10 mit Windows Server 2019 Standard als physisches Hostsystem

    Relevante Screenshots dazu hier:
    https://1drv.ms/u/s!Arpdbk5slCaIgZs_YQ1qaaBW6N5AZw?e=FZ87Cx
Vielleicht seht ihr ja anhand der möglichst gut dargelegten Problemlage, was ich zur Lösung beitragen könnte.

Vielen Dank im Voraus!
 

Anhänge

  • Fehler Prüfpunkt erstellen.JPG
    Fehler Prüfpunkt erstellen.JPG
    27,3 KB · Aufrufe: 4.606
  • HH-DC01 HyperV Details.JPG
    HH-DC01 HyperV Details.JPG
    108,7 KB · Aufrufe: 4.566
  • HH-DC01 Verzeichnis.JPG
    HH-DC01 Verzeichnis.JPG
    27,4 KB · Aufrufe: 4.381
  • list writer auf host.JPG
    list writer auf host.JPG
    161 KB · Aufrufe: 4.329
  • list writer auf virtuellemserver.JPG
    list writer auf virtuellemserver.JPG
    146,9 KB · Aufrufe: 4.293
  • VEEAM Fehlermeldung.JPG
    VEEAM Fehlermeldung.JPG
    168,6 KB · Aufrufe: 4.324
  • statement veeam.JPG
    statement veeam.JPG
    109,5 KB · Aufrufe: 4.481
Zuletzt bearbeitet:
Michi777 schrieb:
Vielleicht seht ihr ja anhand der möglichst gut dargelegten Problemlage, was ich zur Lösung beitragen könnte.
Ja, das machen, was im vorletzten Satz des Veeam Statements steht. Du hast kein Problem mit Veeam. Dein Problem ist, dass sich überhaupt keine Snapshots mit Hyper-V erstellen lassen. Der Fehler ist also dort zu suchen.

Warum du dafür jetzt einen neuen Thread aufmachen musstest, anstatt den anderen weiter zu nutzen, ist mir nicht ganz klar.

Edit: Und du könntest mal die AVHDX-Datei mit der Ursprungs-VHDX zusammenführen. Auf die Idee hätte der Veeam-Support aber auch kommen müssen.

Nebenbei: In mindestens einem der Screenshots ist der Firmenname deines Arbeitgebers sichtbar...
 
Zuletzt bearbeitet:
@Evil E-Lex:
Ja das weiß ich dass es nicht mehr bei VEEAM liegt und um eine Lösung für das Prüfpunktproblem zu finden habe ich mich zusätzlich an das Forum gewendet, weil ich bereits die weniger Schritte die man bzgl. machen kann gemacht habe (vsswriters, updates, prüfpunktarten etc.), ich weiß gerade nicht mehr was noch zu machen wäre.
 
Und? Hast du dir den verlinkten Artikel vom Veeam Support angesehen? Trifft das Problem auf dich zu? Konntest du es mit der im Artikel genannten Lösung beheben?

Hast du die Probleme der letzten 2-3 Hyper-V Threads hier behoben?
 
@snaxilian:
Berechtigungen passen und werden anders als im Thread ja in keiner Fehlermeldung bei mir angemerkt.
Habe von der .vhdx, avhdx und dem VZ einen Screenshot hier angehängt.

Das VM Verzeichnis ist auch im Standardpfad vom Aufsetzen und der Domänenadministrator der eingeloggte Nutzer.
 

Anhänge

  • Berechtigungen.JPG
    Berechtigungen.JPG
    134,6 KB · Aufrufe: 4.206
Nach zwei Minuten Google-Suche bin ich mir sicher, dass du dieses Problem hier hast:
THE CASE OF: WINDOWS SERVER 2019 HYPER-V CHECKPOINT STUCK AT 9% AFTER VEEAM 9.5 UR 4 UPGRADE

Dort werden in den Kommentaren zwei Lösungsmöglichkeiten genannt:
  • Disable VMQ on Host, VMs one by one, then restart your VMs and your host. This will resolve the issue.
  • It was bloody damn Group Policy. We had 1 wrong GPO set which messed with log on as service.

Das würde ich beides prüfen. Zudem die in den Kommentaren verlinkten Threads im MS TechNet durcharbeiten.
 
@Evil E-Lex :
Danke für den Tipp, scheint ein Windows Server 2019 Bug zu sein und ehrlich zu sein schwer zu finden, wie auch die Kommentatoren geschrieben haben.
Jetzt konnte ich 3 VEEAM Backup nacheinander und 2 Prüfpunkte aus dem HyperV bereits erfolgreich erstellen, ich teste morgen nochmals.

Application Aware aus VEEAM (Zusatzfeature für Datenbankserver nützlich) funktioniert nur auf einem 2012 virtuellen Server, die Anderen brachten Fehler, habe dazu Logs an die VEEAM Dame geschickt und die checkt das morgen, scheint aber allgemein eine heikle fehleranfällige Option zu sein.
 
Check mal deine GPO bzgl. dem "Anmelden als Dienst-Recht" auf den Hyper-V-Hosts...

Computerkonfiguration
-> Richtlinien
-> Windows-Einstellungen
-> Sicherheitseinstellungen
-> Lokale Richtlinien/Zuweisen von Benutzerrechten
-> Anmelden als Dienst: Virtuelle Computer, Virtual Machines

Wir hatten genau das gleiche Problem. Produktionsprüfpunkte werden nicht richtig zurück migriert, Veeam macht dadurch lauter Fehler, die avhdx-Dateien bleiben als Datenträger stehen. Die Lösung war tatsächlich die deutsche Schreibweise für das Recht mit einzutragen... Seitdem läuft Veeam anstandsfrei, übrigens mit Application Aware für AD, Exchange und SQL-Server... Das ist jetzt seit einem Jahr solide bei uns. Auch nach dem Veeam-Update auf 9.5 UR4
 
Zuletzt bearbeitet:
@ayngush
Danke für deinen Tipp, nämlich funktioniert das Backup\Prüfpunkt erstellen heute nicht mehr, gestern versuchte ich zumindest zum Schluss Application Aware probiert, nur bei 1 von 3 erfolgreich.
Heute geht gar kein Prüfpunkt mehr, gestern habe ich VMQ deaktiviert und Host neugestartet.

Wsl. gehört auch noch das Anmelden als Dienst Recht angepasst und das versucht ich gerade, jedoch kann ich dort trotz lokaler Admin sowie Domänenadmin nicht ändern, da steht dass Betriebssystem höher als Windows 2000 sein muss (habe 2019) - siehe Anhang.
Dort ist übrigens domäne\dba eingetragen, welche in Gruppe Domänen Admins, Mitarbeiter etc. ist.

Was kann es damit auf sich haben und auf welchen Nutzer sollte man es abändern?
 

Anhänge

  • gpo error.png
    gpo error.png
    73,1 KB · Aufrufe: 4.066
Zuletzt bearbeitet:
Das musst du schon in den Gruppenrichtlinien der Domäne ändern, das geht nicht in den lokalen Richtlinien.
Irgendwas von eurer Domäne schreibt da nen dba-User rein. Das ist üblicherweise eine Abkürzung für einen Datenbankadmin - braucht man für SQL Server und dessen Aufträge. Hat auf den Hyper-V Hosts aber nichts zu suchen.
Kannst ja mal mit gpresult nachschauen, was für Richtlinien und Einstellungen angewendet werden und/oder dich da mal mit euren Domänen-Admin unterhalten ;)

Jedenfalls muss das Dienstkonto "Virtuelle Computer" als Anmelden als Dienst für die HV-Hosts zugelassen werden, sonst kann das Handling mit den Datenträgern nicht richtig funktionieren.
Siehe auch: https://support.microsoft.com/en-us...g-hyper-v-virtual-machines-may-fail-with-erro
Vorsicht: Da stehen wieder nur die englischen Bezeichnungen ;)

Und lass dich nicht von "Live Migrating" täuschen - das funtioniert technisch sehr ähnlich wie ein Veeam-Backup über die Prüfpunkte. Deswegen: Wenn Das Hyper-V Live Migrating nicht funktioniert, funktioniert auch in der Regel Veeam nicht und umgekehrt.
 
Zuletzt bearbeitet:
ayngush schrieb:
Das musst du schon in den Gruppenrichtlinien der Domäne ändern, das geht nicht in den lokalen Richtlinien.
Doch, doch, das geht schon lokal. Das Problem hier ist, dass es eine Gruppenrichtline gibt, die die lokale Einstellung überschreibt (daher ist der Button zum Hinzugen auch ausgegraut). Ich würde die GPO entsprechend anpassen, damit diese nicht auf die Hyper-V-Hosts greift.
Mich wundert allerdings ernsthaft, warum der Veeam-Support das nicht geprüft hat.
 
Hab es nun gefunden (domänen nutzer am domänen server) konnte es öffnen:
Habe dort dann Virtuelle Computer und Virtual Machines hinzugefügt, jedoch finde er in der Domänen sowie Lokalen Ebene kein Nutzer\Gruppenobjekt was so heißt, so habe ich es einfach getippt und bestätigt, doch kann das funktionieren?
Prüfpunkt erstellen nach gpupdate /force (auf DC und Veeam Host Server) zumindest nicht erfolgirech
 

Anhänge

  • gpo error2.jpg
    gpo error2.jpg
    84,2 KB · Aufrufe: 4.002
Zuletzt bearbeitet:
Im AD kannst du diese Nutzerkonten nicht finden, der Suchpfad "Gesamtes Verzeichnis" ist daher nicht zielführend.

Ich möchte mich wiederholen: Definiere "Anmelden als Dienst" nicht domänenweit. Dort sind standardmäßig diverse Konten eingetragen, die nur lokal auf den jeweiligen Computern existieren.

So sieht das beispielsweise auf meiner Workstation aus:
mmc_2019-11-08_12-48-15.png


Ich bin mir fast sicher, dass auf Servern dort auch mehr als nur dein DBA-Nutzer eingetragen sein sollte.
 
Okay, wie es scheint muss ich die GPO abdrehen, welche verhindert dass man lokal was ändert unter "dienste anmelden", ich konnte jedoch trotz vielen Suchen keine Policy dazu finden.
Danach sobald lokal nicht ausgegraut würde er dann die scheinbar rein lokalen Einträge "Virtuelle Computer etc" finden, richtig?

Habt ihr eine Idee wo ich die Richtlinie finde um das freizuschalten auf lokaler Ebene?
...und was ist mit deutscher Schreibweise gemeint, ich denke er findet nur einen Eintrag und den muss man nehmen oder?
 
Michi777 schrieb:
Danach sobald lokal nicht ausgegraut würde er dann die scheinbar rein lokalen Einträge "Virtuelle Computer etc" finden, richtig?
So sollte es ein. Wenn ich @ayngush richtig verstehe, gibt es aber durchaus Fälle in denen diese Einträge fehlen. Die müsstest du dann händisch nachtragen.
Habt ihr eine Idee wo ich die Richtlinie finde um das freizuschalten auf lokaler Ebene?
Stichwort: gpresult
...und was ist mit deutscher Schreibweise gemeint, ich denke er findet nur einen Eintrag und den muss man nehmen oder?
Nicht zwingend. Es gibt Programme/Dienste, die erwarten den lokalisierten Namen der Dienstkonten, auch wenn dieser gar nicht vorhanden ist. Über die Suche wirst du den nicht finden, einfach per Hand in das Benutzerfeld eintragen sollte genügen.
 
Die fehlen immer genau dann, wenn man sich eine GPO für die Hyper-V-Server gebaut hat, damit man diese OracleException-Anmeldenummer und andere Berechtigungen nicht auf zig Hosts immer wieder neu, individuell und abweichend voneinander konfigurieren muss, sondern die HV-Hosts einfach in die passende Gruppe / OU in der Domäne verschiebt und die GPO dann die notwendigen Einstellungen für die (lokale / remote) Hyper-V-Administration vornimmt - inklusive dem Recht "Anmelden als Dienst" für die VM...
Es sind ja noch ein paar mehr Rechte und Vertrauensstellungen per GPO für einen erfolgreichen Hyper-V-Betrieb zu setzen als nur diese "Anmelden als Dienst" Nummer.

Wenn mann die GPO dann deutsch konfiguriert oder die Server deutsch konfigurioert sind (keine Ahnung, welche Spracheinstellung dafür hauptverantwortlich ist), muss man diesem Service-Benutzer "NT Virtual Machine\Virtual Machines" eben auch mit der deutschen Schreibweise in die GPO eintragen.

Ist halt Qualitätssoftware aus dem Hause Microsoft. Warum der Veeam Support das nicht weiß? Ist nicht deren Baustelle, wenn man sich mit Gruppenrichtlinien sein Netzwerk zerlegt...

Evil E-Lex schrieb:
Nicht zwingend. Es gibt Programme/Dienste, die erwarten den lokalisierten Namen der Dienstkonten, auch wenn dieser gar nicht vorhanden ist. Über die Suche wirst du den nicht finden, einfach per Hand in das Benutzerfeld eintragen sollte genügen.

Eben ganz genau das war auch >mein< Fehler damals, wodurch wir in der Firma Anfangs mit Veeam auf dem Prototypen genau die gleichen Probleme hatten. Nicht nach dem Benutzer suchen, einfach "Virtuelle Computer" reinschreiben und fertig ist die Laube.
 
Zuletzt bearbeitet:
Hatte eine lange Remotesession mit dem Microsoft Experten und auch wir haben mit verschiedenen Versuchen im GPO nicht geschafft dass man lokal unter Dienste anmelden als... selbst definieren kann.
Da es laut ihm ohnehin nicht sinnvoll ist einen Host in der Domäne zu haben, haben wir ihn aus der Domäne gehoben und die englische Schreibweise von NT Virtual Machine\Virtual Machines war drinnen, die deutsche jedoch nicht zu finden\einzubinden.

Danach neugestartet und mit Produktionsprüfpunkten ging nur der alte 2012er virtuelle Server, die 3 anderen mit 2019 schafften es nicht und brachten immer sofort die Meldung, mit Standardprüfpunkten funktionierne Diese.
Der Microsofttechniker hält noch Rücksprache am Montag mit technischem Leiter und weiß auch nicht mehr weiter (sehr HyperV bewandt war er aber nicht muss ich sagen).
...er ging schon so auf 2019er Bug und nach Möglichkeit mit 2016er Host versuchen (Hosten und Produktionssnapshots zu machen) oder HyperV neu installieren und die Server exportierten\importieren.

Wenn dauerhaft alle Backups\Snapshots ohne Produktionsprüfpunkten gehen ist schonmal der erste grobe Fortschritt getan...
Wie wichtig schätzt ihr die Produktionsprüfpunkte (Application Aware) ein bei Servern mit Datenbanken, nice2have oder essentiell?
 
Zuletzt bearbeitet:
Essentiell. Application aware von Veeam beendet den lokalen File Writer in der VM (sowohl Linux als auch Windows - weswegen man auch im Veeam die Anmeldedaten für administrative Benutzer für die VMs konfigurieren muss) und die Hyper-V Produktionsprüfpunkte sind die einzige Möglichkeit konsistent Prüfpunkte und damit überhaupt konsistente Backups herzustellen.

Das mit der deutschen Schreibweise kann auch daran liegen, dass mein Gruppenrichtlinieneditor auf deutsch steht. Keine Ahnung, wer da zu welchem Zeitpunkt welche Namen wie auflöst beim Microsoft Windows Domänen und dessen Einstellungen. In meinen Testlab zu hause, ohne Domäne, habe ich auch keine Benutzer in irgendwelchen Gruppenrichtlinieneditoren lokal auf dem Hyper-V Hosts konfigurieren müssen. Ich denke, dass "Virtual Machines" schon das absolut richtige Konto ist, zumal das ja auch Berechtigungen auf den Verzeichnissen besitzt.

Wenn man die Hyper-V Hosts nicht in der Domäne hat, kann man machen, ist das administrieren eben jener Hosts in einer Domäne halt absolut bescheiden, vor allem wenn das Headless Systeme mit dem Windows Hyper-V Server (Core) sind. Das scheint aber bei dir aber nicht der Fall zu sein, so viel GUI, wie du hier abbilden kannst ;) Live Migration kann man ohne Domäne aber wohl vergessen, wenn ich richtig informiert bin, da man dann die Vertrauensstellung nicht konfigurieren kann.

Wo wir aber schon bei best practises wären... auf laufwerk C: haben die VMs auch nichts zu suchen ;) mach da aber bloß nicht den Fehler zuerst auf D: oder sonstwo die Verzeichnisse zu erstellen und dann in der Hyper-V Server-Konfiguration via durchsuchen drauf zu zeigen. Das geht schief. Schreib den Pfad manuell hin und drück einfach "OK", dann werden die Verzeichnisse mit den richtigen ACL vom Server angelegt... (das war mein erster Fehler im Bezug auf Hyper-V, warum Veeam am Ende nicht richtig lief, weil die Checkpunkte nicht liefen...)
 
Zuletzt bearbeitet:
Hallo!
ich habe nun nach 2 Durchläufen und einer Nacht dazwischen nun nochmals VEEAM Backup & HyperV Prüfpunkte versucht und nach wie vor funktionieren Standardprüfpunkte auf den 3 2019 Servern und Produktionsprüfpunkte nur am 2012er Server, bei VEEAM sowie HyperV - somit ein Microsoft Problem und VEEAM außenvor und anhand des offenen Microsoft Tickets muss das dann von den "Experten" behoben werden können, hoffe ich.
Er fraget mich eben ob ich 2016er Host aufsetzen kann und dort Testen kann, weil er vermutet 2019er Hostsystem macht die Probleme, welche jedoch ein frisch aufgesetzter sauberer neuer Server ist d.h. zwecks Microsoft Bug auf andere Version gehen ist denke ich kein zufriedenstellender Vorschlag, ist doch ein seit 8 Monaten fertiges Windows Produkt und 2019 mit 2019 sollte sich doch besser verstehen als zu 2012...

Habt ihr Ansätze welche ich zur Lösung in dem Ticket anstoßen\beitragen kann, warum Produktionsprüfpunkte nicht funktionieren bei den 2019ern?
Fakt ist gleicher Pfad\Berechtigungen der virtuellen Server in diesem Fall (und 2012er schafft es) d.h. Basissetting passt und keine Rechteprobleme oder so.

Zumindest ist der aktuelle Stand so dass sie per VEEAM gesichert werden und zusätzlich Datenbanksicherungen auf Fileebene auf verschiedene Ziele gesichert werden, sollte eine Datenbank inkonsistent wiederhergestellt werden im Notfall (import von Sicherung).
Die .avhdx wird auch nicht mehr bleibend geladen, nach VEEAM Backup, das ist nun auch gut.

Im Anhang Bilder von Einstellung und Fehlermeldung aus HyperV\VEEAM, so konfiguriert dass Produktionsprüfpunkte am 2019er Server erstellt werden müssen.

Vielen Dank!
 

Anhänge

  • hyperv einstellung.JPG
    hyperv einstellung.JPG
    102,5 KB · Aufrufe: 3.900
  • hyperv meldung.JPG
    hyperv meldung.JPG
    39,6 KB · Aufrufe: 3.929
  • veeam einstellung.JPG
    veeam einstellung.JPG
    50,5 KB · Aufrufe: 3.861
  • veeam meldung.JPG
    veeam meldung.JPG
    53,5 KB · Aufrufe: 3.873
Zuletzt bearbeitet:
Die konfigurierten Anmeldedaten in Veeam für die Virtuellen Maschinen stimmen eventuell nicht. Du brauchst für das Application Processing (App Aware) Anmeldedaten auf der VM, die sich dort als Dienstkonto anmelden dürfen und die in der VM Administratorberechtigungen haben, damit der Befehl an den Filewriter in der VM, in dem Fall VSS, vom Backupserver aus über den Hyper-V Host als Proxy in die VM geschickten werden können.
 
Zurück
Oben