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 2.253]

  Am 18.10.2023 um 12:34 schrieb Preleaze:

ich sehe eben nur nicht, ob sie drauf sind.

Mehr  

Einfach im Failover Clustermanager nachschauen reicht nicht?

[NilsK 3.020]

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

Mehr  

 ? 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.816]

  Am 19.10.2023 um 07:13 schrieb Preleaze:

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

Mehr  

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

 

  Am 19.10.2023 um 07:13 schrieb Preleaze:

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

Mehr  

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 2.253]

  Am 19.10.2023 um 07:13 schrieb Preleaze:

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

Mehr  

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]

  Am 19.10.2023 um 07:27 schrieb testperson:

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

Mehr  

Der User hat vollumfängliche Adminrechte ja.

 

  Am 19.10.2023 um 07:27 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ß.

Mehr  

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.

 

  Am 19.10.2023 um 07:34 schrieb NorbertFe:

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

Mehr  

Hatte ich leider nicht dran gedacht. Tut mir Leid.

[NorbertFe 2.253]

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 3.020]

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]

  Am 19.10.2023 um 08:04 schrieb NorbertFe:

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

Mehr  

 

  Am 19.10.2023 um 07:13 schrieb Preleaze:

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

Mehr  

Wie beschrieben funktioniert auf den beiden anderen Maschinen alles Einwandfrei.

 

 

  Am 19.10.2023 um 08:10 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.

Mehr  

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

 

  Am 19.10.2023 um 08:10 schrieb NilsK:

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

Mehr  

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.
 

 

  Am 18.10.2023 um 12:34 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.

Mehr  

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

 

 

[Weingeist 176]

  Am 19.10.2023 um 08: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.

Mehr  

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.