29
Umzug DC von Hyper-V auf Proxmox
Hallo zusammen,
ich plane bzw. bereite aktuell die Migration unserer Server vor.
Aktuell laufen diese auf Hyper-V (Server 2019) und sollen auf einen neuen Proxmox-PVE.
Grundsätzlich der Umzug klappt und habe ich auch bereits mehrfach getestet - jedoch mit folgenden Einschränkungen:
Plan wäre jetzt am Wochenende:
Danach die Clients testen und hoffentlich funktioniert alles ;)
Folgende Server sind betroffen: 2x SQL Server, 1x Domain-Controller (AD/DNS/DHCP).
Die SQL-Server sehe ich als unkritisch an.
Bedenken habe ich aktuell beim DC - hat hier jemand Erfahrung und weiß, ob es so klappen kann?
Als Rollback-Manöver hätte ich ja die Option, dass ich die Proxmox-VMs stoppe und Hyper-V wieder anwerfe.
Oder kann da was schief gehen und die Clients dann den alten DC auch nicht mehr akzeptieren (Hauptangst
)
Freu mich auf Eure Erfahrungen und Ideen!
Viele Grüße aus dem verschneiten Bayern!
MrHom3r
ich plane bzw. bereite aktuell die Migration unserer Server vor.
Aktuell laufen diese auf Hyper-V (Server 2019) und sollen auf einen neuen Proxmox-PVE.
Grundsätzlich der Umzug klappt und habe ich auch bereits mehrfach getestet - jedoch mit folgenden Einschränkungen:
- Maschinen sind beim Export im Hyper-V gelaufen
- Die migrierten Maschinen sind "problemlos" gebootet - aber ohne Netzwerkverbindung (sonst ja doppelt im Netzwerk)
Plan wäre jetzt am Wochenende:
- Herunterfahren der VMs im Hyper-V
- Export der Festplatten
- Konvertierung / Aufsetzen neue VM (mehrfach problemlos gelaufen)
- (NEU) Hochfahren auf Proxmox mit Netzwerk (gleiche IP wie auf HyperV) --> laufen lassen und Hyper-V nicht mehr hochfahren
Danach die Clients testen und hoffentlich funktioniert alles ;)
Folgende Server sind betroffen: 2x SQL Server, 1x Domain-Controller (AD/DNS/DHCP).
Die SQL-Server sehe ich als unkritisch an.
Bedenken habe ich aktuell beim DC - hat hier jemand Erfahrung und weiß, ob es so klappen kann?
Als Rollback-Manöver hätte ich ja die Option, dass ich die Proxmox-VMs stoppe und Hyper-V wieder anwerfe.
Oder kann da was schief gehen und die Clients dann den alten DC auch nicht mehr akzeptieren (Hauptangst
)Freu mich auf Eure Erfahrungen und Ideen!
Viele Grüße aus dem verschneiten Bayern!
MrHom3r
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 12193955210
Url: https://administrator.de/contentid/12193955210
Printed on: April 28, 2024 at 10:04 o'clock
29 Comments
Latest comment
Hallo!
Das würde ich mir nicht antun. Warum installierst Du nicht einen zweiten DC auf Proxmox. DNS ist dann sofort migriert. Bei DHCP eine Failoverbeziehung.
Dann den alten DC herunterstufen und raus nehmen.
Das würde ich mir nicht antun. Warum installierst Du nicht einen zweiten DC auf Proxmox. DNS ist dann sofort migriert. Bei DHCP eine Failoverbeziehung.
Dann den alten DC herunterstufen und raus nehmen.
3
Hi Phil,
naja dachte mir, wenn es mit dem Umzug so klappt, dann wäre es ggf. einfacher.
Hast du konkrete Bedenken oder weißt, dass so ein Umzug nicht klappen kann?
naja dachte mir, wenn es mit dem Umzug so klappt, dann wäre es ggf. einfacher.
Hast du konkrete Bedenken oder weißt, dass so ein Umzug nicht klappen kann?
Wo soll ich da anfangen:
- Ein einzelner Domaincontroller: SEHR schlechte Basis
- Snapshots bei Domaincontrollern: SEHR schlechte Idee
- Einen neuen Domaincontroller hinzufügen: 20 Minuten Arbeit
--> Warum so viel Arbeit machen, wenn es einfach geht?
- Ein einzelner Domaincontroller: SEHR schlechte Basis
- Snapshots bei Domaincontrollern: SEHR schlechte Idee
- Einen neuen Domaincontroller hinzufügen: 20 Minuten Arbeit
--> Warum so viel Arbeit machen, wenn es einfach geht?
3
@MrHom3r:
Die Sorge um den virtuellen DC wäre keine, wenn die (ver)alte(te) Weisheit, mind. einen DC in Blech zu führen, eben noch nicht als veraltet gälte.
Ich kann, was Funktionalität von Domäne, AD, DNS u. DHCP anbelangt, in meinen Hypervisoren treiben, was ich möchte oder muß, der phys. DC (der natürlich ein eig. Backup hat) steht wie ein Fels in der Brandung und hält alle wichtigen, vorgenannten zentralen Dienste, auch in solchen Umbauphasen. Das Henne-Ei-Problem bei der Verwendung von Hyper-V, wenn es nur einen virtuellen DC gibt, das ja angeblich gar keines sein soll, ist auf jeden Fall niemals eins, wenn der erste DC in Blech dasteht. Darauf werde ich niemals verzichten.
Viele Grüße
von
departure69
Die Sorge um den virtuellen DC wäre keine, wenn die (ver)alte(te) Weisheit, mind. einen DC in Blech zu führen, eben noch nicht als veraltet gälte.
Ich kann, was Funktionalität von Domäne, AD, DNS u. DHCP anbelangt, in meinen Hypervisoren treiben, was ich möchte oder muß, der phys. DC (der natürlich ein eig. Backup hat) steht wie ein Fels in der Brandung und hält alle wichtigen, vorgenannten zentralen Dienste, auch in solchen Umbauphasen. Das Henne-Ei-Problem bei der Verwendung von Hyper-V, wenn es nur einen virtuellen DC gibt, das ja angeblich gar keines sein soll, ist auf jeden Fall niemals eins, wenn der erste DC in Blech dasteht. Darauf werde ich niemals verzichten.
Viele Grüße
von
departure69
3
Moin,
Sehe ich auch so. Ich würde vorher noch ein Backup der DB machen für den Fall, dass doch was in die Grütze geht.
Die hätte ich auch.
Das wäre auch meine Befürchtung. Deshalb auch mein Rat: Neuen DC aufsetzen, Replikation abwarten, alten DC demoten und dann ist alles gut. Ein zweiter DC wäre natürlich schön.
hth
Erik
Zitat von @MrHom3r:
Folgende Server sind betroffen: 2x SQL Server, 1x Domain-Controller (AD/DNS/DHCP).
Die SQL-Server sehe ich als unkritisch an.
Folgende Server sind betroffen: 2x SQL Server, 1x Domain-Controller (AD/DNS/DHCP).
Die SQL-Server sehe ich als unkritisch an.
Sehe ich auch so. Ich würde vorher noch ein Backup der DB machen für den Fall, dass doch was in die Grütze geht.
Bedenken habe ich aktuell beim DC - hat hier jemand Erfahrung und weiß, ob es so klappen kann?
Die hätte ich auch.
Als Rollback-Manöver hätte ich ja die Option, dass ich die Proxmox-VMs stoppe und Hyper-V wieder anwerfe.
Oder kann da was schief gehen und die Clients dann den alten DC auch nicht mehr akzeptieren (Hauptangst )
Oder kann da was schief gehen und die Clients dann den alten DC auch nicht mehr akzeptieren (Hauptangst
)Das wäre auch meine Befürchtung. Deshalb auch mein Rat: Neuen DC aufsetzen, Replikation abwarten, alten DC demoten und dann ist alles gut. Ein zweiter DC wäre natürlich schön.
hth
Erik
Moin,
Gruß,
Dani
Aktuell laufen diese auf Hyper-V (Server 2019) und sollen auf einen neuen Proxmox-PVE.
hast du Langeweile weil es so viel Schnee hat oder warum willst du wechseln? Weil mit dem Wechsel des Hypervisor ändert sich auch grundlegend deine Backup-Strategie. Was sich erst einmal nicht kompliziert anhört, aber du wirst mehr oder weniger dazu verdonnert, die Backup-Lösung von Proxmox zu nutzen.Gruß,
Dani
1
Hi Dani,
klar ich komm nicht mehr aus dem Büro - daher die Idee mal zu Wechseln.
Das Hyper-V ist aktuell nur notdürftig konfiguriert und läuft auf 10 Jahre alter Hardware... Da muss was neues her
Backup Strategie wird auch neu.
Aber ich seh es schon - der Trend beim DC geht zum Neu-Aufsetzen.
Falls nicht doch noch jemand Erfahrung mit dem Umzug hat, bleibt mir wohl nichts anders übrig.
klar ich komm nicht mehr aus dem Büro - daher die Idee mal zu Wechseln.
Das Hyper-V ist aktuell nur notdürftig konfiguriert und läuft auf 10 Jahre alter Hardware... Da muss was neues her
Backup Strategie wird auch neu.
Aber ich seh es schon - der Trend beim DC geht zum Neu-Aufsetzen.
Falls nicht doch noch jemand Erfahrung mit dem Umzug hat, bleibt mir wohl nichts anders übrig.
1
Hallo,
für Testumgebung auch mal DCs mnter wiederhersgestellt.
Man kann Backup mit Application aware einkaufen oder Bordmittel nehmen. Die Windows Server Sicherung läuft problemlos. Die VM muss nur die gleiche Plattenaufteilung und größe haben - fertig.
Auf die gleiche Weise lässt sich auch ein Exchange Online sichern und im Anschluss mit eseutil kontrollieren oder fixen. Die Log Dateien liegen ja noch in der VM.
Altbacken, steif und etwas unflexibel. Aber im Ergebnis läuft es damit....
Anosnsten vorher Passwort für DSRM festlegen: https://learn.microsoft.com/de-de/windows-server/identity/ad-ds/manage/f ...
Ein reiner DC ist ja recht klein, was die Laufwerke angeht. Da du eh alles umstellst wäre nocho eine Offline Sicherung mögich. Vorher alles runterfahren und Image ziehen. Dann sollte es gut sein.
Treiber kann man nachinstallieren oder vorher hinterlegen. Windows ist Windows. Würde es mit einer normalen VM oder einer Server Trial testen, wie scih die Dinger verhalten. Hardware wird erkannt?
Wenn das in der Trockenübung schon so schön geht, sollte es im Ernstfall auch keine Probleme geben....
Kurzer VM Test: einfach mal machen! Gilt auch für den DC. Du kannst es ja wiederholen. Wenn die VMs in unterschiedlichen VLANs laufen passiert ja nichts. Dann hast du gleich eine Übersicht was so geht und was nicht.
mfg Crusher
für Testumgebung auch mal DCs mnter wiederhersgestellt.
Man kann Backup mit Application aware einkaufen oder Bordmittel nehmen. Die Windows Server Sicherung läuft problemlos. Die VM muss nur die gleiche Plattenaufteilung und größe haben - fertig.
Auf die gleiche Weise lässt sich auch ein Exchange Online sichern und im Anschluss mit eseutil kontrollieren oder fixen. Die Log Dateien liegen ja noch in der VM.
Altbacken, steif und etwas unflexibel. Aber im Ergebnis läuft es damit....
Anosnsten vorher Passwort für DSRM festlegen: https://learn.microsoft.com/de-de/windows-server/identity/ad-ds/manage/f ...
Ein reiner DC ist ja recht klein, was die Laufwerke angeht. Da du eh alles umstellst wäre nocho eine Offline Sicherung mögich. Vorher alles runterfahren und Image ziehen. Dann sollte es gut sein.
Treiber kann man nachinstallieren oder vorher hinterlegen. Windows ist Windows. Würde es mit einer normalen VM oder einer Server Trial testen, wie scih die Dinger verhalten. Hardware wird erkannt?
Wenn das in der Trockenübung schon so schön geht, sollte es im Ernstfall auch keine Probleme geben....
Kurzer VM Test: einfach mal machen! Gilt auch für den DC. Du kannst es ja wiederholen. Wenn die VMs in unterschiedlichen VLANs laufen passiert ja nichts. Dann hast du gleich eine Übersicht was so geht und was nicht.
mfg Crusher
Zitat von @Der-Phil:
Wo soll ich da anfangen:
- Ein einzelner Domaincontroller: SEHR schlechte Basis
- Snapshots bei Domaincontrollern: SEHR schlechte Idee
- Einen neuen Domaincontroller hinzufügen: 20 Minuten Arbeit
--> Warum so viel Arbeit machen, wenn es einfach geht?
Wo soll ich da anfangen:
- Ein einzelner Domaincontroller: SEHR schlechte Basis
- Snapshots bei Domaincontrollern: SEHR schlechte Idee
- Einen neuen Domaincontroller hinzufügen: 20 Minuten Arbeit
--> Warum so viel Arbeit machen, wenn es einfach geht?
Bitte den Beweis ins Studio. Eine Anleitung wo das in 20 Min. getan ist!
Hello!
Ich darf mich den Kollegen anschließen: einen DC auf diese Weise umzuziehen ist vermutlich keine so gute Idee. Tatsächlich wäre wohl ein zweiter DC die bessere Wahl. Diese dann abgleichen lassen und dann entsprechend "umstufen" ist bestimmt der sicherere Weg.
MfG
M.A.
Ich darf mich den Kollegen anschließen: einen DC auf diese Weise umzuziehen ist vermutlich keine so gute Idee. Tatsächlich wäre wohl ein zweiter DC die bessere Wahl. Diese dann abgleichen lassen und dann entsprechend "umstufen" ist bestimmt der sicherere Weg.
MfG
M.A.
Moin,
Wir reden an der Stelle von "Hinzufügen". D.h. die Zeiten für die Replication von LDAP, Sysvol, etc. sind da nicht berücksichtigt.
Gruß,
Dani
Bitte den Beweis ins Studio. Eine Anleitung wo das in 20 Min. getan ist!
wenn das AD sauer eingerichtet wurde und die "Standards" eingehalten worden sind, ist das 30 Minuten erledigt.Wir reden an der Stelle von "Hinzufügen". D.h. die Zeiten für die Replication von LDAP, Sysvol, etc. sind da nicht berücksichtigt.
Gruß,
Dani
1
Moin,
1. VM erstellen: Aufwand ca. 3 Minuten
2. Windows Server installieren: Nettoaufwand ca. 5 Minuten
3. DCpromo-Assistenten abarbeiten: Aufwand ca. 5 Minuten.
Et voilà
Liebe Grüße
Erik
1. VM erstellen: Aufwand ca. 3 Minuten
2. Windows Server installieren: Nettoaufwand ca. 5 Minuten
3. DCpromo-Assistenten abarbeiten: Aufwand ca. 5 Minuten.
Et voilà
Liebe Grüße
Erik
Naja oder einfach mal machen... Erfahrungen sammeln....
Hab öfters mal in Testumgebung VMs geschoben. 3x DC 2016 + 2x DC 2003 R2. ESXi 5.x auf 7.x.
Hardware Erkennung unter 2003 lief zwar, aber es dauerte. Vor allem musste ich noch die alten VMware Tools besorgen. Die sind nicht mehr inkludiert für 2003
Es stehen ja noch alle Wege offen. Man kann es ja auch einfach testen. Extra VLAN. Möchte man noch Internet dazu haben, einfach weiteres VLAN und Router dazwischen. Da kollidiert nichts und man hat 1:1 die gleichen IPs etc wie im echten Netz.
Dann ist die Fallhöhe relativ gering. Meine Testumgebung umfasste neben 2016 + 2003 DCs auch Exchange.
Es sind ja nur ein paar Klicks bis Recovery startet. Dann Geduld bis die neue Hardware eingebunden wurde und fertig. Auch da muss man nicht permanent dabei sitzen.
Sicherlich kann man über 2. DC + Replikation schneller sein. Nur hier hätte der TO gleich die Chance, sein DaSi Konzept zu prüfen. Online Exchange Sicherung sauber? etc. etc.
Auch wenn es nicht zwingend nötig ist wäre es eine gut Gelgenheit - 2. Hypervisor + unteschidliche Hardware - um mal Recovery durchzuspielen.
Auf gleicher Hardware später fällt dann so einiges raus. Aber man hat zumindest alles mal gesehen....
Windows Backup kann auch aus Netzwerk recovern. Kommt nur die Warnmeldung. Alles punkte die einen irritieren. Darum finde ich es nicht verkehrt das mal gemacht zu haben....
Hab öfters mal in Testumgebung VMs geschoben. 3x DC 2016 + 2x DC 2003 R2. ESXi 5.x auf 7.x.
Hardware Erkennung unter 2003 lief zwar, aber es dauerte. Vor allem musste ich noch die alten VMware Tools besorgen. Die sind nicht mehr inkludiert für 2003
Es stehen ja noch alle Wege offen. Man kann es ja auch einfach testen. Extra VLAN. Möchte man noch Internet dazu haben, einfach weiteres VLAN und Router dazwischen. Da kollidiert nichts und man hat 1:1 die gleichen IPs etc wie im echten Netz.
Dann ist die Fallhöhe relativ gering. Meine Testumgebung umfasste neben 2016 + 2003 DCs auch Exchange.
Es sind ja nur ein paar Klicks bis Recovery startet. Dann Geduld bis die neue Hardware eingebunden wurde und fertig. Auch da muss man nicht permanent dabei sitzen.
Sicherlich kann man über 2. DC + Replikation schneller sein. Nur hier hätte der TO gleich die Chance, sein DaSi Konzept zu prüfen. Online Exchange Sicherung sauber? etc. etc.
Auch wenn es nicht zwingend nötig ist wäre es eine gut Gelgenheit - 2. Hypervisor + unteschidliche Hardware - um mal Recovery durchzuspielen.
Auf gleicher Hardware später fällt dann so einiges raus. Aber man hat zumindest alles mal gesehen....
Windows Backup kann auch aus Netzwerk recovern. Kommt nur die Warnmeldung. Alles punkte die einen irritieren. Darum finde ich es nicht verkehrt das mal gemacht zu haben....
Zitat von @erikro:
Moin,
1. VM erstellen: Aufwand ca. 3 Minuten
2. Windows Server installieren: Nettoaufwand ca. 5 Minuten
3. DCpromo-Assistenten abarbeiten: Aufwand ca. 5 Minuten.
Et voilà
Liebe Grüße
Erik
Moin,
1. VM erstellen: Aufwand ca. 3 Minuten
2. Windows Server installieren: Nettoaufwand ca. 5 Minuten
3. DCpromo-Assistenten abarbeiten: Aufwand ca. 5 Minuten.
Et voilà
Liebe Grüße
Erik
Ah du bist das also mit den 5-minute craft youtube Videos
Naja er schrieb ja: "Migration unserer Server". Da ist ggf. noch Zeit zum Spielen drin. Durch die unterschiedlichen Plattformen sieht man schön wie sich die Server verhalten.
Auch wenn final 2. DC am einfachste wäre, ist es nicht vekehrt alles mal mitgemacht zu haben.
Wenn der TO angsetellt ist, sind es ja eh nur So-Da-Kosten. Gerade wenn man auf einmal neue Ressoucen hat bietet es sich an damit kurz zu spielen.
Moin
Nein, es gibt kein Henne-Ei-Problem. Ich betreue mehr als ein dutzend solcher Umgebungen mit jeweils genau einem virtuellen DC als VM auf Hyper-V. In meiner Donäne ist es identisch.
Ich kann jetzt sofort den einzigen DC herunterfahren und mich anschließend trotzdem per RDP auf dem Hyper-V-Host anmelden und alles mögliche erledigen, wozu ich kein AD brauche.
Der Hyper-V-Host ist auch Domänen-Mitglied.
Bei einem Neustart des Hyper-V-Hosts wird die DC-VM als 1. gestartet und die anderen zeitverzögert.
BTT:
Ich habe keinerlei Erfahrungen mit Proxmox, daher kann ich dazu nichts sagen.
Einige Umgebungen, die ich betreue wurden von mir von veralteten ESXi auf Hyper-V umgezogen. Dabei habe ich Tools von Veritas genutzt, um die VMs zu konvertieren. Die Server wurden sowieso von Backup Exec gesichert.
In mindestens einer dieser Umgebungen gab es damals nur einen virtuellen DC, den ich umgezogen habe, ohne einen zusätzlichen DC zu haben. Das macht man natürlich dann, wenn niemand im Netzwerk arbeitet.
Wenn man ein vernünftiges Backup (kein Snapshot) des DC hat, sehe ich da auch keine Probleme. Dieses kann man - wenn die Migration aus irgendeinem Grund nicht geklappt hat, in sehr kurzer Zeit wiederherstellen und dann von vorn anfangen.
Zitat von @departure69:
Die Sorge um den virtuellen DC wäre keine, wenn die (ver)alte(te) Weisheit, mind. einen DC in Blech zu führen, eben noch nicht als veraltet gälte.
Kann man so machen, muss man aber auch die Lizenzen und die Technik erwerben.Die Sorge um den virtuellen DC wäre keine, wenn die (ver)alte(te) Weisheit, mind. einen DC in Blech zu führen, eben noch nicht als veraltet gälte.
Das Henne-Ei-Problem bei der Verwendung von Hyper-V, wenn es nur einen virtuellen DC gibt, das ja angeblich gar keines sein soll, ist auf jeden Fall niemals eins, wenn der erste DC in Blech dasteht. Darauf werde ich niemals verzichten.
Ständig kommen diese Mythen wieder hoch.Nein, es gibt kein Henne-Ei-Problem. Ich betreue mehr als ein dutzend solcher Umgebungen mit jeweils genau einem virtuellen DC als VM auf Hyper-V. In meiner Donäne ist es identisch.
Ich kann jetzt sofort den einzigen DC herunterfahren und mich anschließend trotzdem per RDP auf dem Hyper-V-Host anmelden und alles mögliche erledigen, wozu ich kein AD brauche.
Der Hyper-V-Host ist auch Domänen-Mitglied.
Bei einem Neustart des Hyper-V-Hosts wird die DC-VM als 1. gestartet und die anderen zeitverzögert.
BTT:
Ich habe keinerlei Erfahrungen mit Proxmox, daher kann ich dazu nichts sagen.
Einige Umgebungen, die ich betreue wurden von mir von veralteten ESXi auf Hyper-V umgezogen. Dabei habe ich Tools von Veritas genutzt, um die VMs zu konvertieren. Die Server wurden sowieso von Backup Exec gesichert.
In mindestens einer dieser Umgebungen gab es damals nur einen virtuellen DC, den ich umgezogen habe, ohne einen zusätzlichen DC zu haben. Das macht man natürlich dann, wenn niemand im Netzwerk arbeitet.
Wenn man ein vernünftiges Backup (kein Snapshot) des DC hat, sehe ich da auch keine Probleme. Dieses kann man - wenn die Migration aus irgendeinem Grund nicht geklappt hat, in sehr kurzer Zeit wiederherstellen und dann von vorn anfangen.
Moin.
Kommen weitere Dienste wie z.B. Exchange ins Spiel, ist ein laufendes AD Grundvoraussetzung für deren Funktion. Daher sind zwei DCs in einem AD eigentlich Pflicht. Wenn einer spinnt => ausschalten, neu machen. Aber alles andere läuft weiter. Wenn dein Exchange steht und du dort den Fehler suchst, obwohl er beim einzigen DC zu suchen ist - viel Erfolg bei der Fehlerlösung.
*Just my 5 Cent*
Cheers,
jsysde
Zitat von @goscho:
[...]Ich kann jetzt sofort den einzigen DC herunterfahren und mich anschließend trotzdem per RDP auf dem Hyper-V-Host anmelden und alles mögliche erledigen, wozu ich kein AD brauche.
Und an dieser Stelle irrst du gewaltig - du brauchst das AD zur Anmeldung. Dass du dich auch ohne AD anmelden kannst, liegt einzig daran, dass du schon mal angemeldet warst und dich mittels Cached Credentials anmelden kannst. Wenn du mal komplett auf Kerberos umgestiegen bist, gehen da schnell die Lichter aus.[...]Ich kann jetzt sofort den einzigen DC herunterfahren und mich anschließend trotzdem per RDP auf dem Hyper-V-Host anmelden und alles mögliche erledigen, wozu ich kein AD brauche.
Kommen weitere Dienste wie z.B. Exchange ins Spiel, ist ein laufendes AD Grundvoraussetzung für deren Funktion. Daher sind zwei DCs in einem AD eigentlich Pflicht. Wenn einer spinnt => ausschalten, neu machen. Aber alles andere läuft weiter. Wenn dein Exchange steht und du dort den Fehler suchst, obwohl er beim einzigen DC zu suchen ist - viel Erfolg bei der Fehlerlösung.
*Just my 5 Cent*
Cheers,
jsysde
2
Ich werfe einmal meine 5 Pfennige in den Ring:
Wer den absolut sicheren Weg gehen will, mag einen neuen Domänkontroller installieren, diesen dem Active Directory hinzufügen und schließlich den ersetzten Hyper-V-VM-DC demoten. Er mag auch so bei den anderen virtuellen Maschinen verfahren.
Ob für eine Virtualisierung wirklich Proxmox gebraucht wird, mag ebenfalls jeder für sich entscheiden. Egal wie ändert das aber nichts daran, dass Promox lediglich eine Webshell um QEMU/KVM ist. Alternative bietet der Virtual Machine Manager (VMM) eine dem Hyper-V-Manager sehr ähnliche, intuitiv bedienbare Bedienoberfläche. Mit den (zugehörigen) Konsolentools virtsh und virt-viewer ist sogar eine powershell-vergleichbare Steuerung ohne GUI möglich. Wer nicht per ssh zugreifen möchte, kann den VMM - wie auch beim Hyper-V-Manager - auf jeder anderen Linux-Maschine installieren und so QEMU/KVM bequem fernbedienen. Alles ganz leicht.
Das vorab.
Eine Migration einer Windows-/Linux-VM nach QEMU/KVM ist äußerst simpel und funktioniert problemfrei. Dazu ist es "lediglich" erforderlich, die VHDX-Dateien mit qemu-img nach QCOW2 zu konvertieren und (im VMM) eine neue virtuelle Maschine anzuleigen. Dank der Fähigkeiten von QEMU können bei gravierenden Hardwareunterschieden geeignete Einstellungen zu CPU und Chipsatz getroffen werden, so dass die alte Hyper-V-VM nunmehr freudig als QEMU/KVM-VM werkelt. Das gilt auch und gerade für einen oder mehrere Domänkontroller.
Auf diese Art und Weise lässt sich sogar adhoc ein Umzug von Hyper-V auf QEMU/KVM auf ein und derselben Hardware erfolgreich umsetzen. Der Zeitbedarf liegt dann lediglich darin, die VHDX-Dateien zu konvertieren und die bisherigen virtuellen Maschinen nunmehr unter QEMU/KVM anzulegen. Bei guter Planung ist das je nach Umfang der Dateien innerhalb weniger Stunden durchgezogen und alles läuft so, als sei alles noch wie vorher.
So jedenfalls mein praktisches Erfahrungsbild.
Viele Grüße
HansDampf06
Wer den absolut sicheren Weg gehen will, mag einen neuen Domänkontroller installieren, diesen dem Active Directory hinzufügen und schließlich den ersetzten Hyper-V-VM-DC demoten. Er mag auch so bei den anderen virtuellen Maschinen verfahren.
Ob für eine Virtualisierung wirklich Proxmox gebraucht wird, mag ebenfalls jeder für sich entscheiden. Egal wie ändert das aber nichts daran, dass Promox lediglich eine Webshell um QEMU/KVM ist. Alternative bietet der Virtual Machine Manager (VMM) eine dem Hyper-V-Manager sehr ähnliche, intuitiv bedienbare Bedienoberfläche. Mit den (zugehörigen) Konsolentools virtsh und virt-viewer ist sogar eine powershell-vergleichbare Steuerung ohne GUI möglich. Wer nicht per ssh zugreifen möchte, kann den VMM - wie auch beim Hyper-V-Manager - auf jeder anderen Linux-Maschine installieren und so QEMU/KVM bequem fernbedienen. Alles ganz leicht.
Das vorab.
Eine Migration einer Windows-/Linux-VM nach QEMU/KVM ist äußerst simpel und funktioniert problemfrei. Dazu ist es "lediglich" erforderlich, die VHDX-Dateien mit qemu-img nach QCOW2 zu konvertieren und (im VMM) eine neue virtuelle Maschine anzuleigen. Dank der Fähigkeiten von QEMU können bei gravierenden Hardwareunterschieden geeignete Einstellungen zu CPU und Chipsatz getroffen werden, so dass die alte Hyper-V-VM nunmehr freudig als QEMU/KVM-VM werkelt. Das gilt auch und gerade für einen oder mehrere Domänkontroller.
Auf diese Art und Weise lässt sich sogar adhoc ein Umzug von Hyper-V auf QEMU/KVM auf ein und derselben Hardware erfolgreich umsetzen. Der Zeitbedarf liegt dann lediglich darin, die VHDX-Dateien zu konvertieren und die bisherigen virtuellen Maschinen nunmehr unter QEMU/KVM anzulegen. Bei guter Planung ist das je nach Umfang der Dateien innerhalb weniger Stunden durchgezogen und alles läuft so, als sei alles noch wie vorher.
So jedenfalls mein praktisches Erfahrungsbild.
Viele Grüße
HansDampf06
Zitat von @HansDampf06:
Bei guter Planung ist das je nach Umfang der Dateien innerhalb weniger Stunden durchgezogen und alles läuft so, als sei alles noch wie vorher.
Bei guter Planung ist das je nach Umfang der Dateien innerhalb weniger Stunden durchgezogen und alles läuft so, als sei alles noch wie vorher.
Hallo Hansdampf,
da gebe ich dir Recht - wie gesagt ich habe alle betroffenen Maschinen bereits zum Test umgezogen. Einzig Zeit kostet der Export und das Konvertieren - Rest geht easy von der Hand...
Einzige Einschränkung ist, dass ich alle Maschinen ohne Netzwerk betreibe - damit keine Konflikte mit den "echten" Maschinen. Beim DC startet der AD-Service aktuell nicht sauber - ich denke, dass könnte aber auch der Tatsache geschuldet sein, dass kein Netzwerk verbunden ist...
Ich denke ist handelt sich um diesen Fehler:
Der Dienst "Standortübergreifender Messagingdienst" wurde mit folgenden Fehler beendet: Der angegebene Server kann den angeforderten Vorgang nicht ausführen. Quelle: Service Control Manager Kann jemand bestätigen, dass der Fehler auf fehlendes Netzwerk hindeutet?
Ansonsten muss/werde ich die Server in einen eigenen VLAN "koppeln" und dann nochmal einen Client auf dem PVE herstellen und dort dann alles testen. Ist halt mehr Aufwand, dafür hat man ja dann eine ziemlich vergleichbare Migration.
Grüße
Hom3r
@MrHom3r Oder mit VLANs und Router alles ausräumen.
VLAN 1 = 192.168.10.0 normales Netz
Router 1
VLAN 2 = 10.10.20.0 Netz zwischen Prod und Test
Router 2
VLAN 3 = 192.168.10.10 Testumgebung
Können auch VM Router sein - pfsense/ OPNsense.
Wenn du alles vorher testen willst mach separates Testnetz. Wenn die IPs gleich bleiben sollen und du nur ein 1x Internet Gateway hast geht das z.B. wie oben beschrieben.
Oder eben zumindest mit einen getrennten VLAN die Maschinen starten.
Ohne Netzwerk bekommst du Fehler oder komisches Verhalten. 1:1 vorab Test gelingt nur, wenn Netzwerk vorhanden ist. Sollte aber kein Problem sein.
VLAN 1 = 192.168.10.0 normales Netz
Router 1
VLAN 2 = 10.10.20.0 Netz zwischen Prod und Test
Router 2
VLAN 3 = 192.168.10.10 Testumgebung
Können auch VM Router sein - pfsense/ OPNsense.
Wenn du alles vorher testen willst mach separates Testnetz. Wenn die IPs gleich bleiben sollen und du nur ein 1x Internet Gateway hast geht das z.B. wie oben beschrieben.
Oder eben zumindest mit einen getrennten VLAN die Maschinen starten.
Ohne Netzwerk bekommst du Fehler oder komisches Verhalten. 1:1 vorab Test gelingt nur, wenn Netzwerk vorhanden ist. Sollte aber kein Problem sein.
1
https://www.virtualizationhowto.com/2015/02/create-isolated-test-environ ...
Da auch nochmal eine techn. Umsetzung, wo in Prod und Test environoment die gleichen IPs beibehalten werden.
Alternativ kannst du auch ans test VLAN LTE Router hängen und hast da nochmal dedizierten Zugriff.
Gibt mehrere Varianten. Am einfafchsten ist es die Netze zu trennen und Routing - zwecks I-Net Zugriff - zu realisieren.
Mailserver haben nochmal eine Besonderheit. Ggf. liegt da ein Mailgateway vorweg. Aber für reinen DC Test sollte das ausreichend sein. Einschl. Internet für Updates - neue Hardware....
Da auch nochmal eine techn. Umsetzung, wo in Prod und Test environoment die gleichen IPs beibehalten werden.
Alternativ kannst du auch ans test VLAN LTE Router hängen und hast da nochmal dedizierten Zugriff.
Gibt mehrere Varianten. Am einfafchsten ist es die Netze zu trennen und Routing - zwecks I-Net Zugriff - zu realisieren.
Mailserver haben nochmal eine Besonderheit. Ggf. liegt da ein Mailgateway vorweg. Aber für reinen DC Test sollte das ausreichend sein. Einschl. Internet für Updates - neue Hardware....
Zitat von @jsysde:
Und an dieser Stelle irrst du gewaltig - du brauchst das AD zur Anmeldung. Dass du dich auch ohne AD anmelden kannst, liegt einzig daran, dass du schon mal angemeldet warst und dich mittels Cached Credentials anmelden kannst.
Es gibt auf dem Hyper-V Horst natürlich auch einen lokalen Benutzer, den man anmelden kann.Und an dieser Stelle irrst du gewaltig - du brauchst das AD zur Anmeldung. Dass du dich auch ohne AD anmelden kannst, liegt einzig daran, dass du schon mal angemeldet warst und dich mittels Cached Credentials anmelden kannst.
Warum muss ich mir ständig von jemandem erklären lassen, was geht und was nicht.
Ich betreue seit mehr als 25 Jahren ausschließlich KMU.
Kommen weitere Dienste wie z.B. Exchange ins Spiel, ist ein laufendes AD Grundvoraussetzung für deren Funktion. Daher sind zwei DCs in einem AD eigentlich Pflicht.
Ich habe ja auch nix dagegen, dass du mehr als einen DC einsetzt.Jetzt erkläre mir bitte, warum ich bei meinem Unternehmen mehr als einen haben sollte?
2-Mann-Firma - Hyper-V 2019 mit diversen VMs (u.a. DC, Exchange, etc)
Wenn der DC spinnen sollte und ich den fehler nicht zeitnah finde, stelle ich den DC oder nur AD aus dem Backup wieder her.
Wenn einer spinnt => ausschalten, neu machen. Aber alles andere läuft weiter. Wenn dein Exchange steht und du dort den Fehler suchst, obwohl er beim einzigen DC zu suchen ist - viel Erfolg bei der Fehlerlösung.
Mein 1. eigener Exchange war ein 4.5 auf NT aus einer Zeit, da gab es (auch für mich schon) DM -> Mitte/Ende 90-er.Seither habe ich keine Exchange-Version ausgelassen.
Moin @goscho,
du hast beim ersten Zitat den letzten Satz (unbewusst) abgeschnitten. Das ist nämlich an der Stelle wichtig. Die Aussage von @jsysde in Kombination mit Kerberos ist nämlich elementar. In dieser Konstellation funktioniert nämlich wirklich die lokale Anmeldung nicht mehr. Das "Local kdc" wird erst mit der nächsten Windows Server Edition funktionieren.
Gruß,
Dani
du hast beim ersten Zitat den letzten Satz (unbewusst) abgeschnitten. Das ist nämlich an der Stelle wichtig. Die Aussage von @jsysde in Kombination mit Kerberos ist nämlich elementar. In dieser Konstellation funktioniert nämlich wirklich die lokale Anmeldung nicht mehr. Das "Local kdc" wird erst mit der nächsten Windows Server Edition funktionieren.
Gruß,
Dani
Unfassbar wie viel Offtopic in den ersten Kommentaren abgegeben wird. Auch die Frage wieso man von Hyper V auf Proxmox migrieren möchte. Alleine dafür gibt es mehr als genug Gründe, warum man genau dies in Erwägung ziehen kann.
Ich würde wie folgt vorgehen:
1. Alle wichtigen Maschinen herunterfahren
2. DC runterfahren und migrieren
3. DC auf Proxmox starten und die jeweiligen Treiber via WinRE installieren, wenn nicht im Vorhinein angepasst.
4. DC hochfahren und und die Startkonfiguration (msconfig) sowie die ursprüngliche IP Adresse statisch setzen.
5. Fertig
Ich kenne deine Infrastruktur nicht, jedoch ist nichts an deiner Idee auszusetzen, da du es ja im Vorhinein getestet hast, was auch funktioniert hat..
Im Endeffekt ist es jedem seine eigene Entscheidung, ob er einen oder fünf DC laufen lässt, ob er die Backup Strategie abgewogen hat oder auch nicht. Jeder der in dem Bereich arbeitet, sollte wissen, womit er es zu tun hat und nicht von jedem stetig belehrt werden, wie man was genau umsetzt. Jeder Infrastruktur hat spezielle Bedürfnisse und kann nicht gleichgesetzt werden.
Ich würde wie folgt vorgehen:
1. Alle wichtigen Maschinen herunterfahren
2. DC runterfahren und migrieren
3. DC auf Proxmox starten und die jeweiligen Treiber via WinRE installieren, wenn nicht im Vorhinein angepasst.
4. DC hochfahren und und die Startkonfiguration (msconfig) sowie die ursprüngliche IP Adresse statisch setzen.
5. Fertig
Ich kenne deine Infrastruktur nicht, jedoch ist nichts an deiner Idee auszusetzen, da du es ja im Vorhinein getestet hast, was auch funktioniert hat..
Im Endeffekt ist es jedem seine eigene Entscheidung, ob er einen oder fünf DC laufen lässt, ob er die Backup Strategie abgewogen hat oder auch nicht. Jeder der in dem Bereich arbeitet, sollte wissen, womit er es zu tun hat und nicht von jedem stetig belehrt werden, wie man was genau umsetzt. Jeder Infrastruktur hat spezielle Bedürfnisse und kann nicht gleichgesetzt werden.
Zitat von @goscho:
Es gibt auf dem Hyper-V Horst natürlich auch einen lokalen Benutzer, den man anmelden kann.
Warum muss ich mir ständig von jemandem erklären lassen, was geht und was nicht.
Ich betreue seit mehr als 25 Jahren ausschließlich KMU.
Das ist völlig zutreffend. Ist hier in einem KMU über zehn Jahre hinweg so nutzbar gewesen.Es gibt auf dem Hyper-V Horst natürlich auch einen lokalen Benutzer, den man anmelden kann.
Warum muss ich mir ständig von jemandem erklären lassen, was geht und was nicht.
Ich betreue seit mehr als 25 Jahren ausschließlich KMU.
Vorteil: Ist die Domäne nicht da, weil der (einzige oder mehrere) DC auf dem Hyper-V als VM laufen und diese eine/mehrere VM's noch nicht gestartet sind, kann trotzdem auf den Hyper-V-Host zugegriffen und alle relevanten Arbeiten erledigt werden. Das lokale Konto war somit immer die Rückversicherung. Unter dieser Maßgabe ist es nicht wirklich tragisch, dass kein weiterer DC auf einem anderen Blech/Hypervisor läuft, obschon das von Microsoft und auch hier im Forum so empfohlen wird.
Freilich: In einem größeren Netzwerk sind die Dinge natürlich ganz anders zu stricken.
Ich habe ja auch nix dagegen, dass du mehr als einen DC einsetzt.
Jetzt erkläre mir bitte, warum ich bei meinem Unternehmen mehr als einen haben sollte?
2-Mann-Firma - Hyper-V 2019 mit diversen VMs (u.a. DC, Exchange, etc)
Wenn der DC spinnen sollte und ich den fehler nicht zeitnah finde, stelle ich den DC oder nur AD aus dem Backup wieder her.
Auch hier kann ich Dir aus langjähriger praktischer Erfahrung bestätigen, dass mit einem einzigen DC in einem kleinen Netzwerk alles ruhig läuft. Ein DC, der nur als DC (AD, DNS und vielleicht noch DHCP) werkelt, läuft sogar eher unscheinbar vor sich hin. Viele Faxen muss man da nicht wirklich machen, außer eben die ganz normale Wartung / Pflege.Jetzt erkläre mir bitte, warum ich bei meinem Unternehmen mehr als einen haben sollte?
2-Mann-Firma - Hyper-V 2019 mit diversen VMs (u.a. DC, Exchange, etc)
Wenn der DC spinnen sollte und ich den fehler nicht zeitnah finde, stelle ich den DC oder nur AD aus dem Backup wieder her.
Dennoch habe ich den subjektiven Eindruck, dass ein zweiter DC (oder mehr) für eine gewisse Beschleunigung zu sorgen scheint. Das dürfte vor allem dem dennoch nicht geringen DNS-Anfrage-Aufkommen auch in einem kleinen Netzwerk geschuldet sein. Denn der Syslog-Mitschnitt von einem Samba-AD-DC offenbart einen äußerst regen Anfrageverkehr und das zu einem großen Teil die AD-bezogenen FQDN.
Viele Grüße
HansDampf06
2Zitat von @goscho:
Wenn du mal komplett auf Kerberos umgestiegen bist, gehen da schnell die Lichter aus.Zitat von @Dani:
du hast beim ersten Zitat den letzten Satz (unbewusst) abgeschnitten. Das ist nämlich an der Stelle wichtig. ... Das "Local kdc" wird erst mit der nächsten Windows Server Edition funktionieren.
Viele Grüße
HansDampf06
Zitat von @surreal1:
3. DC auf Proxmox starten und die jeweiligen Treiber via WinRE installieren, wenn nicht im Vorhinein angepasst.
Ich würde diesen Schritt - Treiberinstallation und Anpassungen an die neue Hardware - sogar möglichst immer schon als ersten Schritt ausführen, weil es nämlich nach der Migration schwieriger sein kann - Windows grüßt sehr gerne mit BlueScreens etc. Freilich vorausgesetzt, dass sich die Treiber ohne das Vorhandensein der (neuen) Hardware bereits installieren lassen. Andernfalls geht es natürlich erst nach der Migration auf der neuen Hardware.3. DC auf Proxmox starten und die jeweiligen Treiber via WinRE installieren, wenn nicht im Vorhinein angepasst.
Viele Grüße
HansDampf06
PS: Durch die vorherige Virtualisierung unter Hyper-V ist das aber ohnehin nicht wirklich tragisch, sofern der neue Hypervisor keine völlig abweichende Hardware präsentiert. Denn dann läuft die virtuelle Maschine ja schon auf einer "abstrahierten" Basis.
Hallo zusammen,
vielen Dank für den ganzen Input!
Ich konnte gestern nochmal alle Maschinen "testmigrieren" und werde nun versuchen diese in einem separaten Netz sauber mit Netzwerk zum Laufen zu bringen.
Sobald ich mehr weiß, gibt's ein Statusupdate - ggf. ist es ja zukünftig für den ein oder anderen auch relevant!
Viele Grüße
MrHom3r
vielen Dank für den ganzen Input!
Ich konnte gestern nochmal alle Maschinen "testmigrieren" und werde nun versuchen diese in einem separaten Netz sauber mit Netzwerk zum Laufen zu bringen.
Sobald ich mehr weiß, gibt's ein Statusupdate - ggf. ist es ja zukünftig für den ein oder anderen auch relevant!
Viele Grüße
MrHom3r
1
Evtl bereits zu spät - aber als Idee:
1zu1 Migration funktioniert perfekt mit Veeam. Die alten Server mit Veeam sichern(Veeam Windows Agent free), Veeam Boot ISO oder USB Stick mit Virtio-Treibern erstellen, booten, die Server in den Proxmox wiederherstellen.
Beim AD/DC müsste ggfs "bcdedit /deletevalue safeboot" notwendig sein.
Ansonsten surren die Maschinen, als wäre nichts gewesen....
Gruß Alex
ps: Vorteil von Veeam ist - die Virtio SCSI/Sata Treiber werden im Widerherstellungsprozess installiert, automatisch.
ps2: VIEL sauberer als vhdx zu konvertieren.
1zu1 Migration funktioniert perfekt mit Veeam. Die alten Server mit Veeam sichern(Veeam Windows Agent free), Veeam Boot ISO oder USB Stick mit Virtio-Treibern erstellen, booten, die Server in den Proxmox wiederherstellen.
Beim AD/DC müsste ggfs "bcdedit /deletevalue safeboot" notwendig sein.
Ansonsten surren die Maschinen, als wäre nichts gewesen....
Gruß Alex
ps: Vorteil von Veeam ist - die Virtio SCSI/Sata Treiber werden im Widerherstellungsprozess installiert, automatisch.
ps2: VIEL sauberer als vhdx zu konvertieren.
Hallo zusammen,
nochmal vielen Dank für Euren zahlreichen Input - ich möchte Euch nun mal kurz vom Wochenende berichten.
Kurzform: VM --> Export Hyper-V | Import mit Konvertieren --> Hochfahren unter gleicher IP --> Fertig
Und nochmal etwas ausführlicher
Zunächst einmal die gute Nachricht - ich habe den DC und 2x SQL Server erfolgreich umgezogen.
Wie geplant und vorab auch schon ausprobiert mit Export der VM im Hyper-V, Import mit Konvertierung, 1:1 Übernahme IP und mehrfachen Boot kamen die Maschinen dann auf die Beine. Laufen seitdem gut und ich konnte noch keine Probleme feststellen. Drückt mir die Daumen...
Nächster Schritt ist dann noch ein Server Bare-Metal-Umzug mittels Synology Active Backup for Business. Klar, einige würden wohl Veeam / [dein Favorit einfügen] bevorzugen, aber mir steht ABB zur Verfügung und die Maschinen werden ja auch mit ABB weiter gesichert. Klappte zum Test bereits sehr gut und ich denke das klappt auch nochmal
Insgesamt bin ich aktuell zufrieden und hoffe, dass die Maschinen jetzt nicht doch irgendwann die Grätsche machen... Wenn Ihr auch sowas vor habt oder Detailfragen - schreibt mir einfach ne PM.
Viele Grüße
MrHom3r
ps: Ich markiere das Thema mal als gelöst - danke!
nochmal vielen Dank für Euren zahlreichen Input - ich möchte Euch nun mal kurz vom Wochenende berichten.
Kurzform: VM --> Export Hyper-V | Import mit Konvertieren --> Hochfahren unter gleicher IP --> Fertig
Und nochmal etwas ausführlicher
Zunächst einmal die gute Nachricht - ich habe den DC und 2x SQL Server erfolgreich umgezogen.
Wie geplant und vorab auch schon ausprobiert mit Export der VM im Hyper-V, Import mit Konvertierung, 1:1 Übernahme IP und mehrfachen Boot kamen die Maschinen dann auf die Beine. Laufen seitdem gut und ich konnte noch keine Probleme feststellen. Drückt mir die Daumen...
Nächster Schritt ist dann noch ein Server Bare-Metal-Umzug mittels Synology Active Backup for Business. Klar, einige würden wohl Veeam / [dein Favorit einfügen] bevorzugen, aber mir steht ABB zur Verfügung und die Maschinen werden ja auch mit ABB weiter gesichert. Klappte zum Test bereits sehr gut und ich denke das klappt auch nochmal
Insgesamt bin ich aktuell zufrieden und hoffe, dass die Maschinen jetzt nicht doch irgendwann die Grätsche machen... Wenn Ihr auch sowas vor habt oder Detailfragen - schreibt mir einfach ne PM.
Viele Grüße
MrHom3r
ps: Ich markiere das Thema mal als gelöst - danke!
