Hyper-V-Server kann andere im Cluster nicht anzeigen

[Preleaze 0]

Hallo zusammen,

 

ich habe folgendes Szenario:
HV1, HV2 und HV3 befinden sich in einem Cluster
HV4 läuft parallel dazu.

Alle 4 befinden sich in der selben Domäne

HV1, HV2 und HV4 laufen mit dem Windows Server 2012 R2 Datacenter

HV3 läuft mit dem Windows Server 2016 Datacenter Evaluation

 

Die HV's zeigen sich alle gegenseitig an und lassen sich auch entsprechend verwalten, beim HV3 ist das jedoch nicht der Fall.

Den HV 4 (der sich nicht im Cluster befindet) kann ganz normal hinzugefügt werden und wird angezeigt.

Beim hinzufügen von HV1 und HV2 bekomme ich jedoch folgende Meldung:

"Sie besitzen nicht die erforderliche Berechtigung für diese Aufgabe. Wenden Sie sich an den Administrator der Autorisierungsrichtlinie für Computer "HV1/HV2"."

Andersherum funktioniert es aber.

 

Ebenfalls kann ich die Virtuellen Maschinen zwischen den HVs hin und her schieben, auch vom HV3 aus auf die anderen beiden, ich sehe eben nur nicht, ob sie drauf sind.

Ich habe sämtliche Lösungsansätze aus jeglichen Foren probiert...

Rechte zuweisen, Neueinbinden ins Cluster, Neustarten der Dienste, und und und...

 

Ich hoffe Ihr könnt mir in dieser Angelegenheit helfen.

Grüße

 

 

 

 

 

bearbeitet 18. Oktober 2023 von Preleaze

[NorbertFe 1.805]

vor 51 Minuten schrieb Preleaze:

ich sehe eben nur nicht, ob sie drauf sind.

Einfach im Failover Clustermanager nachschauen reicht nicht?

[NilsK 2.785]

Moin,

 

zunächst mal ist völlig unklar, an welcher Stelle du überhaupt nachsiehst - im Server-Manager, im Failover-Cluster-Manager oder wo?

Dann verstehe ich das Konstrukt nicht. Warum baut man einen Cluster, in dem ein Node mit einer Eval-Lizenz läuft? Davon abgesehen, dass das ziemlich sicher ein Lizenzverstoß ist, ist es auch technisch nicht sinnvoll.

 

Und was heißt

Zitat

Den HV 4 (der sich nicht im Cluster befindet) kann ganz normal hinzugefügt werden und wird angezeigt

 ? Wenn er nicht im Cluster ist, wo fügst du ihn hinzu?

 

Und schließlich: Warum betreibt man heute noch einen Cluster mit Windows Server 2012? Ein Node ohne Support widerspricht irgendwie dem Konzept eines Clusters.

 

Gruß, Nils

 

[Preleaze 0]

Guten Morgen,

 

die Beschreibung oben bezieht sich auf den Hyper-V-Manager, da lassen sich die anderen HV's nicht einbinden.

 

@NorbertFe

Leider bekomme ich das Cluster im Failovercluster-Manager nicht angezeigt und verbinden lässt es sich auch nicht:
"Fehler beim Herstellen der Verbindung mit dem Cluster "Cluster1"."

"Zugriff verweigert (Ausnahme von HRESULT: 0x80070005 (E_ACCESSDENIED)

#Auf den anderen Maschinen sehe ich jedoch, dass sich der HV3 im Cluster befinden und ich kann auch auf den ClusterStorage zugreifen.

 

@NilsK

Das Ziel ist es die 2012 auf 2022 upzugraden, hierzu nutze ich den 2016 als Zwischenschritt, um die Maschinen dort zwischenzulagern.

Den HV4 habe ich ebenfalls im Hyper-V-Manager hinzugefügt. Die Interaktion mit diesem läuft problemlos.

bearbeitet 19. Oktober 2023 von Preleaze

[testperson 1.534]

vor 14 Minuten schrieb Preleaze:

"Zugriff verweigert (Ausnahme von HRESULT: 0x80070005 (E_ACCESSDENIED)

Der User ist auch Mitglied der lokalen Administratoren auf den Cluster Nodes / Hyper-V Hosts?

 

vor 14 Minuten schrieb Preleaze:

Das Ziel ist es die 2012 auf 2022 upzugraden, hierzu nutze ich den 2016 als Zwischenschritt, um die Maschinen dort zwischenzulagern.

Bleibt die alte(?) Hardware bestehen oder kommt auch neue Hardware? Dann wäre es vermutlich schneller und einfacher, einen neuen Cluster aufzusetzen und die VMs zu migrieren. (Wobei das vermutlich auch ohne neue Hardware mit dem Neubau des Cluster funktionieren könnte.)

 

Generell klingt das so, als solltet ihr hier evtl. einen externen Dienstleister hinzuziehen, der Erfahrung in diesen Bereichen hat. Den Cluster betreibt ihr ja vermutlich nicht aus Spaß.

bearbeitet 19. Oktober 2023 von testperson

[NorbertFe 1.805]

vor 20 Minuten schrieb Preleaze:

Leider bekomme ich das Cluster im Failovercluster-Manager nicht angezeigt und verbinden lässt es sich auch nicht:

Wär ja evtl. sinnvoll, sowas im Eröffnungspost zu schreiben. Ich bin da bei der @testperson Klingt irgendwie sehr merkwürdig das ganze Konstrukt.

[Preleaze 0]

vor 23 Minuten schrieb testperson:

Der User ist auch Mitglied der lokalen Administratoren auf den Cluster Nodes / Hyper-V Hosts?

Der User hat vollumfängliche Adminrechte ja.

 

vor 24 Minuten schrieb testperson:

Bleibt die alte(?) Hardware bestehen oder kommt auch neue Hardware? Dann wäre es vermutlich schneller und einfacher, einen neuen Cluster aufzusetzen und die VMs zu migrieren. (Wobei das vermutlich auch ohne neue Hardware mit dem Neubau des Cluster funktionieren könnte.)

 

Generell klingt das so, als solltet ihr hier evtl. einen externen Dienstleister hinzuziehen, der Erfahrung in diesen Bereichen hat. Den Cluster betreibt ihr ja vermutlich nicht aus Spaß.

Die alte Hardware wird weiter genutzt.

HV1 und HV2 sollen in der Zukunft als 2022er laufen, der 2016er fliegt nach der Migration wieder raus, diesen benötigen wir nur,

weil wir geschuldet der Unterstützten VM-Konfigurationsversionen die Hosts auf 2016 schieben, bevor wir sie auf die 2022 bringen.

 

Das Cluster komplett neu zu bauen ist mir persönlich zu riskant, da ja alles andere im Moment funktioniert.

 

vor 25 Minuten schrieb NorbertFe:

Wär ja evtl. sinnvoll, sowas im Eröffnungspost zu schreiben.

Hatte ich leider nicht dran gedacht. Tut mir Leid.

[NorbertFe 1.805]

Du bekommt also auf keinem der drei Clusterknoten den Failover Clustermanager aufgerufen? War das schon immer so? Falls ja, würd ich da mal ansetzen

[NilsK 2.785]

Moin,

 

... zumal es die Faustregel gibt, dass man in einer Hyper-V-Clusterumgebung immer das "höchste" Tool nutzen sollte, also für Aktionen, die über den FC-Manager oder über den HV-Manager durchführbar sind, immer den FC-Manager. In dem Fall kann es nämlich sein, dass der HV-Manager die Cluster-Besonderheiten nicht berücksichtigt. Ist die Umgebung per VMM verwaltet, dann gilt es entsprechend, in dem Fall ist der VMM das "höchste" Tool.

 

Für mich klingt es auch so, als sei mitnichten alles in Ordnung. Da man einen Cluster hat, um sich auf ihn verlassen zu können, rate ich auch dazu, externen Sachverstand dazu zu holen und das Cluster-Upgrade nicht irgendwie zu basteln, sondern ordentlich zu machen. Hochverfügbarkeit und Sparsamkeit gingen noch nie zusammen.

 

Gruß, Nils

 

[Preleaze 0]

vor 18 Minuten schrieb NorbertFe:

Du bekommt also auf keinem der drei Clusterknoten den Failover Clustermanager aufgerufen? War das schon immer so?

 

vor einer Stunde schrieb Preleaze:

#Auf den anderen Maschinen sehe ich jedoch, dass sich der HV3 im Cluster befinden und ich kann auch auf den ClusterStorage zugreifen.

Wie beschrieben funktioniert auf den beiden anderen Maschinen alles Einwandfrei.

 

 

vor 13 Minuten schrieb NilsK:

... zumal es die Faustregel gibt, dass man in einer Hyper-V-Clusterumgebung immer das "höchste" Tool nutzen sollte, also für Aktionen, die über den FC-Manager oder über den HV-Manager durchführbar sind, immer den FC-Manager. In dem Fall kann es nämlich sein, dass der HV-Manager die Cluster-Besonderheiten nicht berücksichtigt. Ist die Umgebung per VMM verwaltet, dann gilt es entsprechend, in dem Fall ist der VMM das "höchste" Tool.

Leider funktioniert aber weder das eine, noch das andere Tool auf dem HV3

 

vor 14 Minuten schrieb NilsK:

Für mich klingt es auch so, als sei mitnichten alles in Ordnung.

Das Cluster läuft stabil, sämtliche Funktionen und Anzeigen können über den HV1 und HV2 gesteuert werden, wie es auch sein soll.

Lediglich die Anzeige auf dem HV3 geht nicht, was uns nur dahingehend einschränkt, dass wir nicht umstellen können.

Die Verfügbarkeit und Ausfallsicherheit sind auch ohne den HV3 gewährleistet.
 

 

vor 19 Stunden schrieb Preleaze:

Ebenfalls kann ich die Virtuellen Maschinen zwischen den HVs hin und her schieben, auch vom HV3 aus auf die anderen beiden, ich sehe eben nur nicht, ob sie drauf sind.

Die Funktionen an sich sind auch auf dem HV3 verfügbar, lediglich die Anzeige funktioniert nicht.

 

 

[Weingeist 157]

Am 19.10.2023 um 10:29 schrieb Preleaze:

Das Cluster läuft stabil, sämtliche Funktionen und Anzeigen können über den HV1 und HV2 gesteuert werden, wie es auch sein soll.

Lediglich die Anzeige auf dem HV3 geht nicht, was uns nur dahingehend einschränkt, dass wir nicht umstellen können.

Die Verfügbarkeit und Ausfallsicherheit sind auch ohne den HV3 gewährleistet.

Ob ein Cluster wirklicht läuft / funktioniert siehst Du erst, wenn man einen Failover oder geregelten Umzug macht/machen musst. Vorher geht man davon aus, das es so ist. Auf welcher Grundlage auch immer man das entscheidet.

 

Um wie viele VM's gehts den überhaupt? Der VM ist der Unterbau ja grundsätzlich egal solange sie wieder die Ressourcen bekommt die sie benötigt. Warum nicht zwei Maschinen in das neue Cluster und alle VM's migrieren? Allenfalls kalt statt warm? Mit einem Cluster-Spezi?

 

 

Kleiner Anhaltspunkt: Viele Tools die Maschinenübergreifend agieren funktionieren nicht richtig wenn man Remote-Registrierung oder Remote-Verwaltungsdienste nicht laufen oder entsprechende Firewall-Freigaben fehlen. Natürlich kann man auch pedantisch die Firewall-Regeln/laufende Dienste zwischen den Servern abgleichen. Auch DNS ist immer wieder ein Klassiker für sehr vieles das nicht richtig tut.

 

 

Ansonsten: Aktiviere mal das Firewall-Auditing und erstelle eine  gefilterten Ausgabe für Packet-Block im EventViewer.

--> Wird in Security geloggt, dann siehst was nicht ankommt/rausgeht. Relevante Nummern: 5152, 5157

 

 

Englisches OS: auditpol.exe /set /category:"Object Access" /subcategory:"Filtering Platform packet drop" /success:enable /failure:enable
Deutsches OS: auditpol.exe /set /category:"Objektzugriff" /subcategory:"Filterplattform: verworfene Pakete" /success:enable /failure:enable
Sprachübergreifend: auditpol.exe /set /category:"{6997984A-797A-11D9-BED3-505054503030}" /subcategory:"{0CCE9225-69AE-11D9-BED3-505054503030}" /success:enable /failure:enable

 

Die Protokollgrösse würde ich auf mindestens 64MB (65536) hoschrauben eher das Vierfache.

 

Mit
- tasklist /svc
- netstat -a -b

 

Kann herausgefunden werden welcher Prozess es betrifft der allenfalls Freigaben braucht.