maddinx6

Wie vermutet ist für den Support das Problem mit dem Hyper-V Server 2019 mit der Installation vom PowerShell 2.0 gelöst… Ich hätte da noch mal eine Frage zu meiner „kurzen“ Fehlerbeschreibung. War das einigermaßen verständlich? Falls nicht hier ein Video des Fehlers.

Das System ist meine Spielwiese. Dafür hätte man sicherlich auch die Eval Versionen nehmen können. Mein eigentliches Problem ist die FLR restore Geschichte. Das mit dem Hyper-V Server hat sich durch die Spielwiese ergeben.

Da stimme ich dir zu. Ich warte gerade auf die Antwort zu meinen Erkenntnissen. Vermutlich kommt als Antwort, das ist ein MS Problem da es auf einer Core Installation ja ohne PowerShell 2.0 läuft… Wichtiger finde ich allerdings das Restore Problem, bei dem die Dateien auf einem anderen Host landen, wie im Job konfiguriert. Dieses Problem besteht bei allen Server Versionen. Mir ist das nur aufgefallen da ich sporadisch Restore Tests der gesamten Umgebung mache. Deswegen landen die VMs in einem privaten Netz.

Moin, Dukels Tipp war die Lösung des Problems. Vielen Dank nochmal dafür. Ich bin aufgrund des Logeintrags „PowerShell 2.0 or later is required“ davon ausgegangen das die installierte 5.1 ausreicht. Merkwürdig ist allerdings das Powershell 2.0 nur beim Hyper-V Server 2019 benötigt wird. Standard und Datacenter mit und ohne Desktopdarstellung benötigen das nicht.

Ist halt eine Testumgebung. Quick and dirty Dieser Meinung bin ich auch. Aber die wollen sich diesem Thema nicht so recht annehmen. Ich bin da schon seit über einer Woche dran mit denen… Mit dem geht nicht auf Hyper-V Server 2019 könnte ich leben. Aber das der Restore einfach in einer anderen VM auf einem anderen Host landet geht meiner Meinung nach gar nicht. Vielen Dank für dein Unterstützung. Das klingt fast zu einfach. Muss ich mir mal anschauen. Ich bin davon ausgegangen das 5.1 passt wegen des Log Eintrags „PowerShell 2.0 or later is required“

Ist etwas länger geworden. Aber hoffentlich verständlich 😉 Hmm, ich habe mich aber mit genau diesem Konto angemeldet via Enter-PSSession -VMName angemeldet?

Ich habe mir zusätzlich eine kleine Testumgebung aufgebaut. Die Domain dieser heißt demo 😉 Hintergrund des ganzen ist ein meines Erachtens gravierender Fehler im File Level Restore (FLR) von Veeam. Ich versuche das mal zu beschreiben. Gesichert wird VM1 auf Host1. Diese wird anschließend auf Host2 zurück gesichert. Das klappt so weit. Die VM1 hat keine verbundene LAN-Schnittstelle auf Host2 zugewiesen bekommen. Wenn ich jetzt ein FLR-Job einer Datei aus dem Backup von VM1 in die VM1 Kopie auf Host2 mache, beginnt der Spaß. In der Veeam Konsole wird der Job als erfolgreich abgeschlossen dargestellt. Datei xyz in VM1 auf Host2 wiederhergestellt. Die Datei wird aber in VM1 auf Host1 geschrieben! Das liegt daran das Veeam beim Restore grundsätzlich immer erst versucht die Datei über Lan direkt in die VM zu schreiben. Wenn jetzt, wie im meinem Fall VM1 auf Host1 antwortet wird in diese zurückgesichert, ohne zu beachten das mein FLR-Job auf Host2 verweist… Wenn VM1 auf Host1 ebenfalls nicht über LAN erreichbar ist, wird er Job wie angegeben abgearbeitet. Hierfür wird dann PowerShell Direct benutzt. Man kann mittels Reg-Key Veeam dazu nötigen PowerShell Direct bevorzugt zu nutzen, um das Fehlverhalten zu umgehen. Leider klappt der Restore via PowerShell Direct grundsätzlich nicht wenn das Host2 OS Hyper-V Server 2019 ist.

Gibt es jetzt doch einen Hyper-V Server 2022 in der kostenlosen Version? Bisher bin ich davon ausgegangen, dass der Nachfolger azure stack hci „Abo Version“ ist. Azure Stack HCI Im Veeam Log bekomme ich diese Fehlermeldung. Kann es evtl. auch etwas mit dem invoke zu tun haben? Cannot connect to VM over PSDirect. Guest Login: [demo\administrator].;Failed to invoke func [Connect]: Unknown error 0x80131500. Unknown error 0x80131500. PowerShell 2.0 or later is required

Moin, wenn ich dich richtig verstanden habe, kann ich alle drei Punkte mit ja beantworten. Mir ist vorhin der gedackte gekommen das es evtl. einfach an der core ähnlichen Installation liegen könnte. Ich Test jetzt mal ob es mit einem Server std als core installiert läuft.

Hallo, ich bin auf der Suche nach Informationen bezüglich PowerShell Direct auf dem „freien“ Hyper-V Server 2019. Scheinbar ist diese Funktion nur eingeschränkt verfügbar. Ideal wäre eine Quelle von MS. Hintergrund der Frage. Ich komme vom Veeam Backupserver mittels Enter-PSSession -ComputerName auf den Hyper-V Server und von da aus mit Enter-PSSession -VMName in die VM. Veeam kann aber nicht über PowerShell Direct in die VM „ohne LAN“ schreiben, wen der Hyper-V Host die freie 2019er Version ist. So weit bin ich mit dem Veeam Support gekommen. Mir stellt sich jetzt die Frage, ob das eine Beschränkung Seitens MS.

Danke für die Antworten! Es liegt wirklich am scheduler mode. Wenn ich das richtig verstehe wurde der eingeführt um Sicherheitslücken der CPUs zu umschiffen. Ich habe noch mal ein Paar Tests mit Cinebench R15 gemacht. Der Leistungsverlust durch den core mode ist je Anwendungsfall aber recht beachtlich. Zwei VMs mit 8 Threads und scheduler mode core „Default ab Server 2019“ Beide VMs haben abgerundete 740 Punkte erreicht. Zwei VMs mit 8 Threads und scheduler mode classic Beide VMs haben abgerundete 960 Punkte erreicht. Hat der Epyc eigentlich auch diese Sicherheitslücke bzw. verhält sich das genauso bei dem?

Hallo, ich habe ein merkwürdiges Verhalten mit Hyper-V unter Server 2019 festgestellt. So wie es scheint unterbindet Microsoft die Nutzung von HT Threads, wenn mehr als eine VM Betrieben wird. Unter Win 10 habe ich dieses Verhalten nicht feststellen können. Intel hat doch vor einiger Zeit mal empfohlen HT zu deaktivieren um eine Sicherheitslücke zu schließen. Ist dieses Verhalten also gewollt oder hat das evtl. mit einem fehlenden Microcode Update zu tun? Kann diese „Sicherheitsfunktion“ irgendwie deaktivieren? Ist ja nur ein LAB System. Test Aufbau: Server 2019 und Win 10 1809 aufm Blech. VMs von Server 2016-2019 und Win 10 von 1703-1809. Als CPU last wurde Prime benutzt. Workstation Mainboard mit C246 Chipsatz. CPU i9-9900k Tests: Wenn nur eine VM mit 16 Threads betrieben wird kann die CPU zu 100% auslastet werden. Wenn ich zwei VMs mit jeweils 8 Threads betreibe kann ich die CPU nur noch zu ~50% auslasten. Bei acht VMs mit jeweils 2 Threads kann die CPU ebenfalls nur noch zu ~50% ausgelastet werden. Richtig merkwürdig wird es, wenn eine VM mit 16 Threads voll auslaste und anschließen eine weiter VM mit 2 Threads gestartet wird. In dieser Konstellation ist die maximal mögliche CPU Auslastung 100%, wenn nur die 16 Thread VM belastet wird. Wenn jetzt zusätzlich die 2 Thread VM belastet wird sinkt die CPU Auslastung auf 90%. Sobald die Last der 2 Thread VM weg fällt wird die CPU wieder 100% ausgelastet. Aufgefallen ist mir dieses Verhalten beim gleichzeitigen updaten mehrerer VMs. Es hat also nichts mit dem zum test eingesetzten Programm zu tun. Selbst im Taskmanager auf dem Blech kann man sehen das nur jeder zweite Thread benutzt wird…

Hallo Matze-it, mir geht es hauptsächlich um die Machbarkeit. Ich möchte die Konfigurationsmöglichkeiten mal testen. Hallo Dunkelmann, vielen Dank für den Link. Das es so einfach ist hatte ich nicht erwartet. Bisher bin Ich davon ausgegangen das bei einer konfigurierten Replikation am Zielserver nichts mehr geändert werden darf.

Hallo, ich würde gerne mittels Hyper-v Replica eine VM replizieren die zwei VHDx Dateien hat die jeweils auf einer eigenen Disk liegen. Bisher habe ich leider noch keine Möglichkeit gefunden dies zu konfigurieren. Server-1 Replica Server-2 Disk-1 VM-System >>> Disk-1 VM-System Disk-2 VM-Data >>> Disk-2 VM-Data Wenn jemand einen Tipp hat, wäre ich euch dankbar. Gruß Maddin