20
VM-Export (HV 2019) Fehler bei Prüfpunkt Initiierung
Hallo Administratoren,
ich wende mich mal wieder an euch weil ich einem Rätsel auf der Spur bin auf welches ich keine Antwort mehr finde ;)
kurze Vorgeschichte, wir haben letztes Jahr einen neuen Server angeschafft und alle anderen auch von HyperV-2012 auf HyperV-2019 umgestellt. Bis dato auch keine gravierenden Probleme, es funktioniert alles einwandfrei.
Jetzt haben wir eine neue VM erstellt (die erste die unter 2019 erstellt wurde, alle anderen wurden noch "übernommen") und wollen diese nun wie alle anderen Maschinen die darauf laufen über ein Powershell Script auf ein NAS sichern. Das Script ist bei allen VM´s das gleiche, nur das bei der neu erstellten VM die Sicherung nicht durchgeführt wird. Es liegt auch nicht am PS-Script, da ich einen einfachen Export-VM Befehl gemacht habe mit dem Netzwerkpfad. siehe Fehlermeldung:
Ein Lokaler Export der VM funktioniert einwandfrei, wird sofort gestartet, daher kommt mir die Fehlermeldung mit "Prüfpunktvorgang" sehr komisch vor.
Rechte am NAS sind vorhanden, die anderen Maschinen werden auch exportiert.
Hat jemand das gleiche Problem schon mal gehabt?
Ich danke euch vorab für eure Unterstützung,
LG aus WIen
Greg
ich wende mich mal wieder an euch weil ich einem Rätsel auf der Spur bin auf welches ich keine Antwort mehr finde ;)
kurze Vorgeschichte, wir haben letztes Jahr einen neuen Server angeschafft und alle anderen auch von HyperV-2012 auf HyperV-2019 umgestellt. Bis dato auch keine gravierenden Probleme, es funktioniert alles einwandfrei.
Jetzt haben wir eine neue VM erstellt (die erste die unter 2019 erstellt wurde, alle anderen wurden noch "übernommen") und wollen diese nun wie alle anderen Maschinen die darauf laufen über ein Powershell Script auf ein NAS sichern. Das Script ist bei allen VM´s das gleiche, nur das bei der neu erstellten VM die Sicherung nicht durchgeführt wird. Es liegt auch nicht am PS-Script, da ich einen einfachen Export-VM Befehl gemacht habe mit dem Netzwerkpfad. siehe Fehlermeldung:
PS C:\Users\srvadmin> Get-VM -Name vServer130 | Export-VM -Path "\\Nas01.meinefirma.com\B4ckup\Server\vServer130\Do\vServer130"
Export-VM : Der virtuelle Computer "vServer130" wurde nicht exportiert.
"vServer130": Fehler beim Initiieren eines Prüfpunktvorgangs.
Der virtuelle Computer "vServer130" wurde nicht exportiert, da der Vorgang abgebrochen wurde (ID des virtuellen Computers: 859A39CC-A627-47B6-807D-88F419AC945C).
Von "vServer130" konnte ein Prüfpunktvorgang nicht initiiert werden: Die Anforderung wird nicht unterstützt. (0x80070032). (ID des virtuellen Computers:
859A39CC-A627-47B6-807D-88F419AC945C)
In Zeile:1 Zeichen:27
+ ... Server130 | Export-VM -Path "\\Nas01.meinefirma.com\B4ckup\Server\ ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : InvalidOperation: (:) [Export-VM], VirtualizationException
+ FullyQualifiedErrorId : NotSupported,Microsoft.HyperV.PowerShell.Commands.ExportVMEin Lokaler Export der VM funktioniert einwandfrei, wird sofort gestartet, daher kommt mir die Fehlermeldung mit "Prüfpunktvorgang" sehr komisch vor.
Rechte am NAS sind vorhanden, die anderen Maschinen werden auch exportiert.
Hat jemand das gleiche Problem schon mal gehabt?
Ich danke euch vorab für eure Unterstützung,
LG aus WIen
Greg
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 1020215265
Url: https://administrator.de/forum/vm-export-hv-2019-fehler-bei-pruefpunkt-initiierung-1020215265.html
Ausgedruckt am: 26.12.2024 um 17:12 Uhr
20 Kommentare
Neuester Kommentar
Moin,
ich würde, wenn schon auf diesem Weg, auf jeden Fall auf Nummer sicher gehen und zu erst lokal exportieren und dann verschieben.
Die erstellte VHDX beim Export ist sowieso empfindlich. Aus diesem Grund gesichert herstellen und sicher verschieben mit Robocopy oder ähnlichem.
Gruß
bdmvg
ich würde, wenn schon auf diesem Weg, auf jeden Fall auf Nummer sicher gehen und zu erst lokal exportieren und dann verschieben.
Die erstellte VHDX beim Export ist sowieso empfindlich. Aus diesem Grund gesichert herstellen und sicher verschieben mit Robocopy oder ähnlichem.
Gruß
bdmvg
Moin,
Sehr spärliche Informationen, welche du hier niederschreibst.
Dein Skript bricht ab, bevor es die Daten zur NAS schickt. Also kann der Fehler nicht dort zu finden sein.
Hast du schon herausgefunden, weshalb kein Prüfpunkt (Snapshot) erstellt werden kann?
Gruß
C.C.
Sehr spärliche Informationen, welche du hier niederschreibst.
Dein Skript bricht ab, bevor es die Daten zur NAS schickt. Also kann der Fehler nicht dort zu finden sein.
Hast du schon herausgefunden, weshalb kein Prüfpunkt (Snapshot) erstellt werden kann?
Gruß
C.C.
Starte mal die PowerShell als Administrator und lasse den gleichen Befehl nochmals laufen.
Zitat von @beidermachtvongreyscull:
Moin,
ich würde, wenn schon auf diesem Weg, auf jeden Fall auf Nummer sicher gehen und zu erst lokal exportieren und dann verschieben.
Die erstellte VHDX beim Export ist sowieso empfindlich. Aus diesem Grund gesichert herstellen und sicher verschieben mit Robocopy oder ähnlichem.
Gruß
bdmvg
Moin,
ich würde, wenn schon auf diesem Weg, auf jeden Fall auf Nummer sicher gehen und zu erst lokal exportieren und dann verschieben.
Die erstellte VHDX beim Export ist sowieso empfindlich. Aus diesem Grund gesichert herstellen und sicher verschieben mit Robocopy oder ähnlichem.
Gruß
bdmvg
Moin,
das machen wir bis zur Lösung des Problems sowieso vorübergehend Lokal und verschieben es dann ;)
LG
Zitat von @148656:
Moin,
Sehr spärliche Informationen, welche du hier niederschreibst.
Dein Skript bricht ab, bevor es die Daten zur NAS schickt. Also kann der Fehler nicht dort zu finden sein.
Hast du schon herausgefunden, weshalb kein Prüfpunkt (Snapshot) erstellt werden kann?
Gruß
C.C.
Moin,
Sehr spärliche Informationen, welche du hier niederschreibst.
Dein Skript bricht ab, bevor es die Daten zur NAS schickt. Also kann der Fehler nicht dort zu finden sein.
Hast du schon herausgefunden, weshalb kein Prüfpunkt (Snapshot) erstellt werden kann?
Gruß
C.C.
Moin Caveman,
Wenn du mir sagst welche Information dir noch fehlt versuche ich gerne dir diese zur Verfügung zu stellen ;)
Wie gesagt, das Skript kann es nicht sein, weil ohne Skript kommt der gleiche Fehler.
- Die VM Einstellungen sind auch ident mit den "funktionierenden" VM´s.
- Ich habe die Snapshot Funktion deaktiviert und wieder aktiviert.
- Ich habe die Maschine exportiert und mit einer neuen ID importiert.
- Ich habe die .vhdx. aus dem root in den Folder "Virtual Hard Disks" verschoben, habe gelesen, dass es manchmal Probleme macht, das war es leider auch nicht.
Aus der Ereignisanzeige kann ich noch folgendes bereitstellen :
Protokollname: Microsoft-Windows-Hyper-V-VMMS-Admin
Quelle: Microsoft-Windows-Hyper-V-VMMS
Datum: 17.07.2021 10:33:38
Ereignis-ID: 18280
Aufgabenkategorie:Keine
Ebene: Fehler
Schlüsselwörter:
Benutzer: SYSTEM
Computer: HYPERV01.meinefirma.COM
Beschreibung:
Der virtuelle Computer "vServer130" wurde nicht exportiert, da der Vorgang abgebrochen wurde (ID des virtuellen Computers: 859A39CC-A627-47B6-807D-88F419AC945C).
Ereignis-XML:
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
<System>
<Provider Name="Microsoft-Windows-Hyper-V-VMMS" Guid="{6066F867-7CA1-4418-85FD-36E3F9C0600C}" />
<EventID>18280</EventID>
<Version>0</Version>
<Level>2</Level>
<Task>0</Task>
<Opcode>0</Opcode>
<Keywords>0x8000000000000000</Keywords>
<TimeCreated SystemTime="2021-07-17T08:33:38.806131600Z" />
<EventRecordID>1948</EventRecordID>
<Correlation ActivityID="{91D49ACF-7505-0000-6AF0-D6910575D701}" />
<Execution ProcessID="2796" ThreadID="6368" />
<Channel>Microsoft-Windows-Hyper-V-VMMS-Admin</Channel>
<Computer>HYPERV01.meinefirma.COM</Computer>
<Security UserID="S-1-5-18" />
</System>
<UserData>
<VmlEventLog xmlns="http://www.microsoft.com/Windows/Virtualization/Events">
<VmName>vServer130</VmName>
<VmId>859A39CC-A627-47B6-807D-88F419AC945C</VmId>
</VmlEventLog>
</UserData>
</Event>Protokollname: Microsoft-Windows-Hyper-V-Worker-Admin
Quelle: Microsoft-Windows-Hyper-V-Worker
Datum: 17.07.2021 10:33:38
Ereignis-ID: 3280
Aufgabenkategorie:Keine
Ebene: Fehler
Schlüsselwörter:
Benutzer: S-1-5-83-1-2241477068-1203152423-4102585728-1553247257
Computer: HYPERV01.meinefirma.COM
Beschreibung:
Von "vServer130" konnte ein Prüfpunktvorgang nicht initiiert werden: Die Anforderung wird nicht unterstützt. (0x80070032). (ID des virtuellen Computers: 859A39CC-A627-47B6-807D-88F419AC945C)
Ereignis-XML:
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
<System>
<Provider Name="Microsoft-Windows-Hyper-V-Worker" Guid="{51DDFA29-D5C8-4803-BE4B-2ECB715570FE}" />
<EventID>3280</EventID>
<Version>0</Version>
<Level>2</Level>
<Task>0</Task>
<Opcode>0</Opcode>
<Keywords>0x8000000000000000</Keywords>
<TimeCreated SystemTime="2021-07-17T08:33:38.799885000Z" />
<EventRecordID>514</EventRecordID>
<Correlation />
<Execution ProcessID="4040" ThreadID="408" />
<Channel>Microsoft-Windows-Hyper-V-Worker-Admin</Channel>
<Computer>HYPERV01.meinefirma.COM</Computer>
<Security UserID="S-1-5-83-1-2241477068-1203152423-4102585728-1553247257" />
</System>
<UserData>
<VmlEventLog xmlns="http://www.microsoft.com/Windows/Virtualization/Events">
<VmName>vServer130</VmName>
<VmId>859A39CC-A627-47B6-807D-88F419AC945C</VmId>
<ErrorCode>%%2147942450</ErrorCode>
<HResult>0x80070032</HResult>
</VmlEventLog>
</UserData>
</Event>Werde mal weiter auf spurensuche gehen
LG Greg
Zitat von @DeViL5:
...
Moin Caveman,
Wenn du mir sagst welche Information dir noch fehlt versuche ich gerne dir diese zur Verfügung zu stellen ;)
Eine kleine Auswahl der benötigten Informationen werden Hier genannt....
Moin Caveman,
Wenn du mir sagst welche Information dir noch fehlt versuche ich gerne dir diese zur Verfügung zu stellen ;)
Wie gesagt, das Skript kann es nicht sein, weil ohne Skript kommt der gleiche Fehler.
Mag sein, dass die Einstellungen der VM ident sind. Aber sind es die VMs auch? Hier zählen, wie in der Liebe auch, die inneren Werte. - Die VM Einstellungen sind auch ident mit den "funktionierenden" VM´s.
* Ich habe die Snapshot Funktion deaktiviert und wieder aktiviert.
Aus der Ereignisanzeige kann ich noch folgendes bereitstellen :
...
Werde mal weiter auf spurensuche gehen
Schau doch mal in die VM.- Ich habe die Maschine exportiert und mit einer neuen ID importiert.
- Ich habe die .vhdx. aus dem root in den Folder "Virtual Hard Disks" verschoben, habe gelesen, dass es manchmal Probleme macht, das war es leider auch nicht.
Aus der Ereignisanzeige kann ich noch folgendes bereitstellen :
...
Werde mal weiter auf spurensuche gehen
Laufen die Integrationskomponenten?
Wenn der VM ein Windows-OS zugrunde liegt, was spuckt der "Volume Shadow Copy Service" für Meldungen?
https://www.windowspro.de/marcel-kueppers/produktionspruefpunkte-hyper-v ...
LG Greg
GrußC.C.
Moin Greg,
diese Zeile sagt mir, dass du das Skript nicht als Administrator sondern mit einem anderen, zusätzlich angelegtem Benutzer startest.
Ich vermute hier aus Erfahrung eher ein Berechtigungsproblem.
Versuche doch einmal bitte wie oben schon gebeten, das Script mal als Administrator laufen zu lassen.
Es wird wahrscheinlich nicht durchlaufen, weil der lokale Administrator keine Schreibrechte auf die NAS hat, aber dann müsste die Fehlermeldung auch anders aussehen.
Beste Grüsse aus BaWü
Alex
Benutzer: S-1-5-83-1-2241477068-1203152423-4102585728-1553247257 diese Zeile sagt mir, dass du das Skript nicht als Administrator sondern mit einem anderen, zusätzlich angelegtem Benutzer startest.
Ich vermute hier aus Erfahrung eher ein Berechtigungsproblem.
Versuche doch einmal bitte wie oben schon gebeten, das Script mal als Administrator laufen zu lassen.
Es wird wahrscheinlich nicht durchlaufen, weil der lokale Administrator keine Schreibrechte auf die NAS hat, aber dann müsste die Fehlermeldung auch anders aussehen.
Beste Grüsse aus BaWü
Alex
Hallo Alex,
in diesem Fall habe ich es sogar mit dem "SYSTEM" Benutzer gemacht gehabt, auch dieser hat auf den Backup Ordner Zugriff, aber auch unser srvadmin Account und die Einstellung mit "höchsten" Privilegien klappt leider nicht.
Wenn die VM Heruntergefahren ist, "klappt" auch der Export (logisch hier wird kein Prüfpunkt erstellt), aber nach dem Export werden die Daten gleich wieder vom NAS entfernt...
Die virtuelle Maschine läuft als einziges auf der Version 9.0 während alle "alten" V-Maschinen noch auf 5.0 sind.
in diesem Fall habe ich es sogar mit dem "SYSTEM" Benutzer gemacht gehabt, auch dieser hat auf den Backup Ordner Zugriff, aber auch unser srvadmin Account und die Einstellung mit "höchsten" Privilegien klappt leider nicht.
Wenn die VM Heruntergefahren ist, "klappt" auch der Export (logisch hier wird kein Prüfpunkt erstellt), aber nach dem Export werden die Daten gleich wieder vom NAS entfernt...
Die virtuelle Maschine läuft als einziges auf der Version 9.0 während alle "alten" V-Maschinen noch auf 5.0 sind.
Moin Greg,
OK, vor allem das mit dem Herunterfahren ist sehr interessant. 🤔
Das verstehe ich wiederum nicht so ganz.
Der Export läuft sauber durch und dennoch wird das Backup auf dem NAS im Anschluss gelöscht?
😲 da hätte ich eher vermutet, dass sich die 5.0 nicht sichern lassen als die 9.0, so kann man sich auch täuschen. 🙃
Jetzt aber zu dem Wesentlichen, dass sich die VM im heruntergefahrenen Zustand sichern lässt und hochgefahren nicht
bedeutet eigentlich nur eins, die VM kann "intern" keinen VSS Snapshot erstellen. Ob das so ist, lässt sich jedoch recht einfach herausfinden. 😀
Führe mal bitte dein Skript mit der folgenden Erweiterung aus.
Mit diesem Parameter müsste, wenn ich die Doku von Microsoft auf nur halbwegs richtig verstanden habe, der Export der VM ohne die Zuhilfenahme von VSS erfolgen.
https://docs.microsoft.com/en-us/powershell/module/hyper-v/export-vm?vie ...
Warum VSS in der VM nicht läuft kann mehrere Gründe haben, hier solltest du am besten mal die Ereignislogs der VM selbst prüfen.
Ist es eigentlich ein Hyper-V Failover Cluster oder ein einzelner Hyper-V Node?
Wenn Cluster, hast du es eventuell von 2012R2 auf 2019 upgegradet?
Hat der Benutzer mit dem der Job gestartet wird, auf der zu sichernden VM Admin Rechte?
Beste Grüsse aus BaWü
Alex
in diesem Fall habe ich es sogar mit dem "SYSTEM" Benutzer gemacht gehabt, auch dieser hat auf den Backup Ordner Zugriff, aber auch unser srvadmin Account und die Einstellung mit "höchsten" Privilegien klappt leider nicht.
Wenn die VM Heruntergefahren ist, "klappt" auch der Export (logisch hier wird kein Prüfpunkt erstellt),
Wenn die VM Heruntergefahren ist, "klappt" auch der Export (logisch hier wird kein Prüfpunkt erstellt),
OK, vor allem das mit dem Herunterfahren ist sehr interessant. 🤔
aber nach dem Export werden die Daten gleich wieder vom NAS entfernt...
Das verstehe ich wiederum nicht so ganz.
Der Export läuft sauber durch und dennoch wird das Backup auf dem NAS im Anschluss gelöscht?
Die virtuelle Maschine läuft als einziges auf der Version 9.0 während alle "alten" V-Maschinen noch auf 5.0 sind.
😲 da hätte ich eher vermutet, dass sich die 5.0 nicht sichern lassen als die 9.0, so kann man sich auch täuschen. 🙃
Jetzt aber zu dem Wesentlichen, dass sich die VM im heruntergefahrenen Zustand sichern lässt und hochgefahren nicht
bedeutet eigentlich nur eins, die VM kann "intern" keinen VSS Snapshot erstellen. Ob das so ist, lässt sich jedoch recht einfach herausfinden. 😀
Führe mal bitte dein Skript mit der folgenden Erweiterung aus.
Get-VM -Name vServer130 | Export-VM -CaptureLiveState CaptureCrashConsistentState -Path "\\Nas01.meinefirma.com\B4ckup\Server\vServer130\Do\vServer130" Mit diesem Parameter müsste, wenn ich die Doku von Microsoft auf nur halbwegs richtig verstanden habe, der Export der VM ohne die Zuhilfenahme von VSS erfolgen.
https://docs.microsoft.com/en-us/powershell/module/hyper-v/export-vm?vie ...
Warum VSS in der VM nicht läuft kann mehrere Gründe haben, hier solltest du am besten mal die Ereignislogs der VM selbst prüfen.
Ist es eigentlich ein Hyper-V Failover Cluster oder ein einzelner Hyper-V Node?
Wenn Cluster, hast du es eventuell von 2012R2 auf 2019 upgegradet?
Hat der Benutzer mit dem der Job gestartet wird, auf der zu sichernden VM Admin Rechte?
Beste Grüsse aus BaWü
Alex
Das verstehe ich wiederum nicht so ganz.
Der Export läuft sauber durch und dennoch wird das Backup auf dem NAS im Anschluss gelöscht?
Der Export läuft sauber durch und dennoch wird das Backup auf dem NAS im Anschluss gelöscht?
ja, ich verstehe es auch nicht, habe sogar auf einen Extra Ordner mit Rechte für alle vorhin probiert, da macht er genau das gleiche...
Führe mal bitte dein Skript mit der folgenden Erweiterung aus.
Get-VM -Name vServer130 | Export-VM -CaptureLiveState CaptureCrashConsistentState -Path "\\Nas01.meinefirma.com\B4ckup\Server\vServer130\Do\vServer130" habe ich gemacht, jetzt macht er den Export mit eingeschaltener Maschine, der Export wird wieder gelöscht.
PS C:\Users\srvadmin> Get-VM -Name vServer130 | Export-VM -CaptureLiveState CaptureCrashConsistentState -Path "\\Nas01\Spielwiese$\Test\"
Export-VM : Fehler beim Exportieren des virtuellen Computers "vServer130".
Fehler beim Exportieren des virtuellen Computers "vServer130" (859A39CC-A627-47B6-807D-88F419AC945C). Fehler: "Die
Anforderung wird nicht unterstützt." (0x80070032).
In Zeile:1 Zeichen:27
+ ... Server130 | Export-VM -CaptureLiveState CaptureCrashConsistentState - ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : InvalidOperation: (:) [Export-VM], VirtualizationException
+ FullyQualifiedErrorId : NotSupported,Microsoft.HyperV.PowerShell.Commands.ExportVMIst es eigentlich ein Hyper-V Failover Cluster oder ein einzelner Hyper-V Node?
Wenn Cluster, hast du es eventuell von 2012R2 auf 2019 upgegradet?
Wenn Cluster, hast du es eventuell von 2012R2 auf 2019 upgegradet?
Nein, ist kein Cluster, wir haben einen neuen Server gekauft und frisch mit HyperV2019 installiert, die alten 2012R2 Hyper-V´s haben wir (nachdem wir die VM´s umgezogen haben) neu aufgesetzt. also kein Upgrade. Cluster verwenden wir auch keinen, sind alle einzelne Nodes.
Hat der Benutzer mit dem der Job gestartet wird, auf der zu sichernden VM Admin Rechte?
Der Benutzer ist auf dem Hyper V Admin, in der VM ist er "nichts",, ist aber auch eine Linux Maschine und auf den anderen Linux Geräten haben wir auch keine "VM" User.
Ich werde morgen mal eine neue Maschine erstellen mit Linux und diese versuchen zu sichern, vlt. ist einfach bei der Erstellung was extrem schief gelaufen...
Weiters habe ich gestern Nacht noch mit Veeam Backup and Replication Community Edition ein Backup durchführen können. Er hat auch einen Snapshot erstellt, die Sicherung gemacht und danach den Snapshot wieder gelöscht. Der User ist dabei genau der gleiche wie bei allen Scripts und mit dem ich auch lokal den VM Export durchführe...
langsam bin ich mit meinem Latein Echt am Ende ;)
LG Greg
Moin Greg,
ja, ich verstehe es auch nicht, habe sogar auf einen Extra Ordner mit Rechte für alle vorhin probiert, da macht er genau das gleiche...
das ist echt schräg, da läuft irgendwo noch etwas kräftig schief. 🤔
wie schon oben gesagt, echt schräg, muss etwas Nachhirnen. 🤪
OK, das erklärt auch warum der Backupjob nicht mit VSS durchgelaufen ist, VSS ist nur bei Windows verfügbar. 🙃
Wir sichern bei unseren Kunden nur mit Veeam.
Ja, kostet Geld, dafür hast du aber auch so gut wie keinen Rumfummelstress. 😜
Beste Grüsse aus BaWü
Alex
Der Export läuft sauber durch und dennoch wird das Backup auf dem NAS im Anschluss gelöscht?
ja, ich verstehe es auch nicht, habe sogar auf einen Extra Ordner mit Rechte für alle vorhin probiert, da macht er genau das gleiche...
das ist echt schräg, da läuft irgendwo noch etwas kräftig schief. 🤔
habe ich gemacht, jetzt macht er den Export mit eingeschaltener Maschine, der Export wird wieder gelöscht.
wie schon oben gesagt, echt schräg, muss etwas Nachhirnen. 🤪
Ich werde morgen mal eine neue Maschine erstellen mit Linux und diese versuchen zu sichern, vlt. ist einfach bei der Erstellung was extrem schief gelaufen...
OK, das erklärt auch warum der Backupjob nicht mit VSS durchgelaufen ist, VSS ist nur bei Windows verfügbar. 🙃
Weiters habe ich gestern Nacht noch mit Veeam Backup and Replication Community Edition ein Backup durchführen können. Er hat auch einen Snapshot erstellt, die Sicherung gemacht und danach den Snapshot wieder gelöscht. Der User ist dabei genau der gleiche wie bei allen Scripts und mit dem ich auch lokal den VM Export durchführe...
Wir sichern bei unseren Kunden nur mit Veeam.
Ja, kostet Geld, dafür hast du aber auch so gut wie keinen Rumfummelstress. 😜
Beste Grüsse aus BaWü
Alex
Kannst du noch ein paar Infos über die Linux-VM rüberwachsen lassen?
Zum Beispiel, welches OS und sind die Integrationsdienste installiert?
Zum Beispiel, welches OS und sind die Integrationsdienste installiert?
Hi Alex,
entschuldige, stressige Woche mit anderen Dingen ;)
Ja wir haben auch Veeam schon länger im Einsatz, verwenden die Community Edition für ein paar Windows VM´s, bei den Linux Maschinen hat der VM Export immer gut geklappt. Dadurch sind wir nicht "umgestiegen". Aber aktuell wird die Maschine so gesichert.
Das Geld wäre kein Problem für die Software, bis dato war einfach der Bedarf nicht gegeben ;)
Problem ist nur, dass mich persönlich solche Dinge "fertig" machen wenn ich das Problem nicht finde ;).
Liebe Grüße aus Wien
Greg
entschuldige, stressige Woche mit anderen Dingen ;)
Ja wir haben auch Veeam schon länger im Einsatz, verwenden die Community Edition für ein paar Windows VM´s, bei den Linux Maschinen hat der VM Export immer gut geklappt. Dadurch sind wir nicht "umgestiegen". Aber aktuell wird die Maschine so gesichert.
Das Geld wäre kein Problem für die Software, bis dato war einfach der Bedarf nicht gegeben ;)
Problem ist nur, dass mich persönlich solche Dinge "fertig" machen wenn ich das Problem nicht finde ;).
Liebe Grüße aus Wien
Greg
Hallo Caveman,
ja gerne.
Aktuell läuft Debian 10.10 darauf. Alle Integrationsdienste sind angehackt/aktiviert.
Die Linux Maschine besitzt aktuell nur einen NGINX und eine CouchDB für eine interne Webapplikation.
Die Integrationsdienste sind nicht installiert (zumindest nicht von mir) habe es letzten mal kurz auf der MS Homepage wo gelesen, müsste mir aber noch die Packages laden und installieren, werde es am Wochenende probieren und gebe wieder bescheid.
Eine Google Suche hat mir aber ausgespuckt, dass ich nicht der einzige mit diesem Problem sein dürfte. Aber DIE LÖSUNG habe ich noch nicht gefunden ;)
Liebe Grüße
Greg
ja gerne.
Aktuell läuft Debian 10.10 darauf. Alle Integrationsdienste sind angehackt/aktiviert.
Die Linux Maschine besitzt aktuell nur einen NGINX und eine CouchDB für eine interne Webapplikation.
Die Integrationsdienste sind nicht installiert (zumindest nicht von mir) habe es letzten mal kurz auf der MS Homepage wo gelesen, müsste mir aber noch die Packages laden und installieren, werde es am Wochenende probieren und gebe wieder bescheid.
Eine Google Suche hat mir aber ausgespuckt, dass ich nicht der einzige mit diesem Problem sein dürfte. Aber DIE LÖSUNG habe ich noch nicht gefunden ;)
Liebe Grüße
Greg
Moin Greg,
laufen auf den anderen Linux-VMs auch Datenbanken?
Gruß
C.C.
laufen auf den anderen Linux-VMs auch Datenbanken?
Gruß
C.C.
Abend Caveman,
ja auf den meisten, egal ob am Gogs (GIT), Redmine oder auch am ProjectSend Server, überall sind DB´s mit dabei soweit ich es weiß ;)
Liebe Grüße
Greg
ja auf den meisten, egal ob am Gogs (GIT), Redmine oder auch am ProjectSend Server, überall sind DB´s mit dabei soweit ich es weiß ;)
Liebe Grüße
Greg
Moin Greg,
So, ich Klinke mich an dieser Stelle aus.
Mach dich mit der Funktions- und Arbeitsweise deines Handwerkszeugs vertraut.
Ich habe dich nach den Integrationsdiensten gefragt und erhalte diese Antwort.
Ein Prüfpunkt erstellt ein Abbild des Arbeitsspeichers. Wenn deine Datenbank dies nicht unterstützt oder aufgrund der Arbeitsweise nicht möglich ist, Joar, da kannst du auch noch sooft deine Berechtigungen auf der NAS anpassen.
Das gleiche gilt auch für die Integrationsdienste. Sind diese nicht vorhanden, geht’s einfach nicht. Schau in das LOG deiner VM und halte dich an die bewährten Methoden zum Aufbau der Infrastruktur.
https://docs.microsoft.com/de-de/virtualization/hyper-v-on-windows/about ...
https://docs.microsoft.com/de-de/windows-server/virtualization/hyper-v/s ...
https://www.rheinwerk-verlag.de/microsoft-hyper-v-das-handbuch-fuer-admi ...
https://www.andysblog.de/hyper-v-debian-10-buster-installieren-minimal-a ...
Schönes Wochenende.
CaseClosed
So, ich Klinke mich an dieser Stelle aus.
Mach dich mit der Funktions- und Arbeitsweise deines Handwerkszeugs vertraut.
Ich habe dich nach den Integrationsdiensten gefragt und erhalte diese Antwort.
Die Integrationsdienste sind nicht installiert (zumindest nicht von mir) habe es letzten mal kurz auf der MS Homepage wo gelesen, müsste mir aber noch die Packages laden und installieren, werde es am Wochenende probieren und gebe wieder bescheid.
Ein Prüfpunkt erstellt ein Abbild des Arbeitsspeichers. Wenn deine Datenbank dies nicht unterstützt oder aufgrund der Arbeitsweise nicht möglich ist, Joar, da kannst du auch noch sooft deine Berechtigungen auf der NAS anpassen.
Das gleiche gilt auch für die Integrationsdienste. Sind diese nicht vorhanden, geht’s einfach nicht. Schau in das LOG deiner VM und halte dich an die bewährten Methoden zum Aufbau der Infrastruktur.
https://docs.microsoft.com/de-de/virtualization/hyper-v-on-windows/about ...
https://docs.microsoft.com/de-de/windows-server/virtualization/hyper-v/s ...
https://www.rheinwerk-verlag.de/microsoft-hyper-v-das-handbuch-fuer-admi ...
https://www.andysblog.de/hyper-v-debian-10-buster-installieren-minimal-a ...
Schönes Wochenende.
CaseClosed
Moin C.C.,
ist ein freies Land. 😉
Du aber auch.
Greg hat schon den folgenden Befehl ausprobiert.
Dabei wird eine Sicherung ohne das Einbeziehen der Integrationsdienste gefahren und diese Sicherung ist auch nicht durchgelaufen. 😉
Warum versteifst du dich daher auf die unschuldigen Integrationsdienste? 🤔
Dir auch
Und Übrigens.
Du bist hier weder der TO noch einer der Forenadmins, also las bitte auch den Mist mit.
danke.
So, ich Klinke mich an dieser Stelle aus.
ist ein freies Land. 😉
Mach dich mit der Funktions- und Arbeitsweise deines Handwerkszeugs vertraut.
Du aber auch.
Ich habe dich nach den Integrationsdiensten gefragt und erhalte diese Antwort.
Ein Prüfpunkt erstellt ein Abbild des Arbeitsspeichers. Wenn deine Datenbank dies nicht unterstützt oder aufgrund der Arbeitsweise nicht möglich ist, Joar, da kannst du auch noch sooft deine Berechtigungen auf der NAS anpassen.
Das gleiche gilt auch für die Integrationsdienste. Sind diese nicht vorhanden, geht’s einfach nicht. Schau in das LOG deiner VM und halte dich an die bewährten Methoden zum Aufbau der Infrastruktur.
https://docs.microsoft.com/de-de/virtualization/hyper-v-on-windows/about ...
https://docs.microsoft.com/de-de/windows-server/virtualization/hyper-v/s ...
https://www.rheinwerk-verlag.de/microsoft-hyper-v-das-handbuch-fuer-admi ...
https://www.andysblog.de/hyper-v-debian-10-buster-installieren-minimal-a ...
Die Integrationsdienste sind nicht installiert (zumindest nicht von mir) habe es letzten mal kurz auf der MS Homepage wo gelesen, müsste mir aber noch die Packages laden und installieren, werde es am Wochenende probieren und gebe wieder bescheid.
Ein Prüfpunkt erstellt ein Abbild des Arbeitsspeichers. Wenn deine Datenbank dies nicht unterstützt oder aufgrund der Arbeitsweise nicht möglich ist, Joar, da kannst du auch noch sooft deine Berechtigungen auf der NAS anpassen.
Das gleiche gilt auch für die Integrationsdienste. Sind diese nicht vorhanden, geht’s einfach nicht. Schau in das LOG deiner VM und halte dich an die bewährten Methoden zum Aufbau der Infrastruktur.
https://docs.microsoft.com/de-de/virtualization/hyper-v-on-windows/about ...
https://docs.microsoft.com/de-de/windows-server/virtualization/hyper-v/s ...
https://www.rheinwerk-verlag.de/microsoft-hyper-v-das-handbuch-fuer-admi ...
https://www.andysblog.de/hyper-v-debian-10-buster-installieren-minimal-a ...
Greg hat schon den folgenden Befehl ausprobiert.
Get-VM -Name vServer130 | Export-VM -CaptureLiveState CaptureCrashConsistentState -Path "\\Nas01.meinefirma.com\B4ckup\Server\vServer130\Do\vServer130" Dabei wird eine Sicherung ohne das Einbeziehen der Integrationsdienste gefahren und diese Sicherung ist auch nicht durchgelaufen. 😉
Warum versteifst du dich daher auf die unschuldigen Integrationsdienste? 🤔
Schönes Wochenende.
Dir auch
Und Übrigens.
Du bist hier weder der TO noch einer der Forenadmins, also las bitte auch den Mist mit.
CaseClosed
danke.
Die Fehlermeldung 0x80070032 hat mich nun selbst ca. 3 Tage beschäftigt. Da dieser Thread bei Google zu diesem Thema recht weit oben steht, poste ich hier meine Erkenntnisse und Lösung.
In meiner Umgebung sollen Windows Server der Versionen 2012 R2 bis 2022 Sicherungen auf einen UNC Pfad per Export-VM durchführen. Die Freigabe wird dabei von einem Debian (9.13) mit Samba (4.5.16) bereitgestellt.
Die Freigabe ist für jeden beschreibbar und Gastzugriffe sind erlaubt.
Mit Win 2012R2 funktioniert das exportieren out of the box tadellos unter Angabe des UNC Pfades auf das Share des Debian Servers.
Ab Windows 2016 bricht der Export zu Beginn mit der Fehlermeldung 0x8007003A ab. Hier habe ich zwar keine Ursache für gefunden, jedoch festgestellt, dass der Fehler nicht auftritt, wenn der HyperV, der den Export durchführen soll Mitglied einer Domäne ist und der exportierende User der Domänen Administrator ist. Die Domäne selbst kann dabei von einem Windows Server, aber auch von einem Samba Server bereitgestellt sein. Letzteres habe ich erfolgreich mit Samba 4.13.13 (DC) und Windows 2012 R2 bis 2022 (Member Server) getestet. Sowohl das von mir getestete Windows AD, als auch das Samba AD liefen hierbei "wie installiert". Also keinerlei Einstellungen an irgendwelchen GPOs oder Rechten.
Der Server, der den UNC Pfad zur Sicherung bereitstellt, muss interessanter Weise dabei kein Mitglied der Domäne sein. Das Problem, dass hier ein Computer Account Rechte auf dem UNC Pfad braucht, würde ich daher eher ausschließen.
Mit Windows 2019 baut Microsoft nun neue Hürde ein, welcher zum Fehler 0x80070032 führt. Hier ist das verwendete Samba Protokoll während der Übertragung des Exportes das Hinderniss.
Standardmäßig handeln beide beteiligten Server das aktuellste Protokoll aus, das von beiden unterstützt wird. Derzeit ist das die Version 3.11 (Quelle: https://unix.stackexchange.com/questions/458203/smb-protocol-min-max-val ..).
Welche Protokollversion mit welchem Share verwendet wird, kann man unter Windows mit dem PowerShell Befehl 'Get-SmbConnection' testen. Unter Linux nimmt man hierfür den Befehl 'smbstatus'.
Überredet man den Linux Server, der das Share bereitstellt, nicht mehr das Protokoll 3.11, sondern 2.02 zu verwenden, so funktioniert Export-VM wieder.
Hierzu muss auf dem Linux Server der Bereich '[global]' der Date /etc/samba/smb.conf ergänzt werden:
Danach benötigt der Samba Daemon einen Neustart. Das Maximale Sambaprotokoll kann man wohl auch per Registry Key in Windows einstellen. Die Keys dazu habe ich aber leider nicht mehr gefunden. In meinem Fall macht es auch auf dem Linux Server mehr Sinn.
Bei mir hatte der Windows Server 2022 dann auch noch vorab eine Überraschung parat. Wie erwähnt sind auf dem von mir verwendeten Share Gastzugriffe erlaubt. Diese mag Win2022 aber nicht mehr und sind daher deaktiviert. So kam ich mit Win 2022 von vornherein überhaupt nicht auf mein Share.
Reaktivieren kann man den Gastzugriff unter Win 2022 per Registry Key:
(Dword, Value: 1)
Der Key muss ggf. angelegt werden.
In meiner Umgebung sollen Windows Server der Versionen 2012 R2 bis 2022 Sicherungen auf einen UNC Pfad per Export-VM durchführen. Die Freigabe wird dabei von einem Debian (9.13) mit Samba (4.5.16) bereitgestellt.
Die Freigabe ist für jeden beschreibbar und Gastzugriffe sind erlaubt.
Mit Win 2012R2 funktioniert das exportieren out of the box tadellos unter Angabe des UNC Pfades auf das Share des Debian Servers.
Ab Windows 2016 bricht der Export zu Beginn mit der Fehlermeldung 0x8007003A ab. Hier habe ich zwar keine Ursache für gefunden, jedoch festgestellt, dass der Fehler nicht auftritt, wenn der HyperV, der den Export durchführen soll Mitglied einer Domäne ist und der exportierende User der Domänen Administrator ist. Die Domäne selbst kann dabei von einem Windows Server, aber auch von einem Samba Server bereitgestellt sein. Letzteres habe ich erfolgreich mit Samba 4.13.13 (DC) und Windows 2012 R2 bis 2022 (Member Server) getestet. Sowohl das von mir getestete Windows AD, als auch das Samba AD liefen hierbei "wie installiert". Also keinerlei Einstellungen an irgendwelchen GPOs oder Rechten.
Der Server, der den UNC Pfad zur Sicherung bereitstellt, muss interessanter Weise dabei kein Mitglied der Domäne sein. Das Problem, dass hier ein Computer Account Rechte auf dem UNC Pfad braucht, würde ich daher eher ausschließen.
Mit Windows 2019 baut Microsoft nun neue Hürde ein, welcher zum Fehler 0x80070032 führt. Hier ist das verwendete Samba Protokoll während der Übertragung des Exportes das Hinderniss.
Standardmäßig handeln beide beteiligten Server das aktuellste Protokoll aus, das von beiden unterstützt wird. Derzeit ist das die Version 3.11 (Quelle: https://unix.stackexchange.com/questions/458203/smb-protocol-min-max-val ..).
Welche Protokollversion mit welchem Share verwendet wird, kann man unter Windows mit dem PowerShell Befehl 'Get-SmbConnection' testen. Unter Linux nimmt man hierfür den Befehl 'smbstatus'.
Überredet man den Linux Server, der das Share bereitstellt, nicht mehr das Protokoll 3.11, sondern 2.02 zu verwenden, so funktioniert Export-VM wieder.
Hierzu muss auf dem Linux Server der Bereich '[global]' der Date /etc/samba/smb.conf ergänzt werden:
min protocol = SMB2_02
max protocol = SMB2_02Bei mir hatte der Windows Server 2022 dann auch noch vorab eine Überraschung parat. Wie erwähnt sind auf dem von mir verwendeten Share Gastzugriffe erlaubt. Diese mag Win2022 aber nicht mehr und sind daher deaktiviert. So kam ich mit Win 2022 von vornherein überhaupt nicht auf mein Share.
Reaktivieren kann man den Gastzugriff unter Win 2022 per Registry Key:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters\AllowInsecureGuestAuthDer Key muss ggf. angelegt werden.
1
Moin S-Oehl,
an dieser Stelle schon Mal besten Dank für deinen ausführlichen Erfahrungsbericht.
🤔, sehr interessant, ich hatte dem Letzt ein ähnliche Phänomen mit einem 2016er und einem NAS.
Das mit dem AD ist interessant, da muss ich nochmals genauer drüberhirnen.
Ich habe es dann irgendwann mal geschafft, aber ich habe einiges am SMB-Client umgebogen und kann dir
jetzt (noch) nicht sagen, was am Ende geholfen hat. Dein Hinweis auf das AD ist auf jeden Fall für mich ein fehlendes Puzzelstück zum Lösungspuzzl gewesen. 😀
Das bedeutet für mich, dass irgend eines der im Windows implementierten SMB3 Features, nicht so ganz rund läuft
oder zum Linux in bestimmten Situationen inkompatibel ist. 🤔
Diese Konfigurationsoption des SMB-Clients gibt es schon seit Server 2016, dort ist diese aber auf Enabled, repektive True gesetzt. Ab Server 2019, ist diese Option auf Disabled, respektive False gesetzt.
Mann kann diese Option übrigens auch ganz entspannt über Powershell konfigurieren.
Beste Grüsse aus BaWü
Alex
an dieser Stelle schon Mal besten Dank für deinen ausführlichen Erfahrungsbericht.
Mit Win 2012R2 funktioniert das exportieren out of the box tadellos unter Angabe des UNC Pfades auf das Share des Debian Servers.
Ab Windows 2016 bricht der Export zu Beginn mit der Fehlermeldung 0x8007003A ab. Hier habe ich zwar keine Ursache für gefunden, jedoch festgestellt, dass der Fehler nicht auftritt, wenn der HyperV, der den Export durchführen soll Mitglied einer Domäne ist und der exportierende User der Domänen Administrator ist.
Ab Windows 2016 bricht der Export zu Beginn mit der Fehlermeldung 0x8007003A ab. Hier habe ich zwar keine Ursache für gefunden, jedoch festgestellt, dass der Fehler nicht auftritt, wenn der HyperV, der den Export durchführen soll Mitglied einer Domäne ist und der exportierende User der Domänen Administrator ist.
Die Domäne selbst kann dabei von einem Windows Server, aber auch von einem Samba Server bereitgestellt sein. Letzteres habe ich erfolgreich mit Samba 4.13.13 (DC) und Windows 2012 R2 bis 2022 (Member Server) getestet. Sowohl das von mir getestete Windows AD, als auch das Samba AD liefen hierbei "wie installiert". Also keinerlei Einstellungen an irgendwelchen GPOs oder Rechten.
🤔, sehr interessant, ich hatte dem Letzt ein ähnliche Phänomen mit einem 2016er und einem NAS.
Das mit dem AD ist interessant, da muss ich nochmals genauer drüberhirnen.
Ich habe es dann irgendwann mal geschafft, aber ich habe einiges am SMB-Client umgebogen und kann dir
jetzt (noch) nicht sagen, was am Ende geholfen hat. Dein Hinweis auf das AD ist auf jeden Fall für mich ein fehlendes Puzzelstück zum Lösungspuzzl gewesen. 😀
Überredet man den Linux Server, der das Share bereitstellt, nicht mehr das Protokoll 3.11, sondern 2.02 zu verwenden, so funktioniert Export-VM wieder.
Das bedeutet für mich, dass irgend eines der im Windows implementierten SMB3 Features, nicht so ganz rund läuft
oder zum Linux in bestimmten Situationen inkompatibel ist. 🤔
Bei mir hatte der Windows Server 2022 dann auch noch vorab eine Überraschung parat. Wie erwähnt sind auf dem von mir verwendeten Share Gastzugriffe erlaubt. Diese mag Win2022 aber nicht mehr und sind daher deaktiviert. So kam ich mit Win 2022 von vornherein überhaupt nicht auf mein Share.
Reaktivieren kann man den Gastzugriff unter Win 2022 per Registry Key:
(Dword, Value: 1)
Der Key muss ggf. angelegt werden.
Reaktivieren kann man den Gastzugriff unter Win 2022 per Registry Key:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters\AllowInsecureGuestAuthDer Key muss ggf. angelegt werden.
Diese Konfigurationsoption des SMB-Clients gibt es schon seit Server 2016, dort ist diese aber auf Enabled, repektive True gesetzt. Ab Server 2019, ist diese Option auf Disabled, respektive False gesetzt.
Mann kann diese Option übrigens auch ganz entspannt über Powershell konfigurieren.
Set-SmbClientConfiguration -EnableInsecureGuestLogons $trueBeste Grüsse aus BaWü
Alex
