Vorbereiten der VMware-Migration ohne Agent

Dieser Artikel enthält eine Übersicht über die Änderungen, die durchgeführt werden, wenn Sie mithilfe des Migrations- und Modernisierungstools VMware-VMs über die agentlose Migrationsmethode nach Azure migrieren.

Bevor Sie Ihre lokale VM zu Azure migrieren, müssen Sie möglicherweise einige Änderungen vornehmen, um die VM für Azure vorzubereiten. Diese Änderungen sind wichtig, um sicherzustellen, dass die migrierte VM erfolgreich in Azure gestartet werden kann und die Verbindung mit dem Azure-VM hergestellt werden kann. Azure Migrate behandelt diese Konfigurationsänderungen automatisch für die folgenden Betriebssystemversionen für Linux und Windows. Dieser Vorgang wird als Hydration bezeichnet.

Für die Hydration unterstützte Betriebssystemversionen

• Windows Server 2008 oder höher
• Red Hat Enterprise Linux 10.x, 9.5, 9.x, 8.x, 7.9, 7.8, 7.7, 7.6, 7.5, 7.4, 7.3, 7.2, 7.1, 7.0, 6.x
• CentOS Stream
• SUSE Linux Enterprise Server 15 SP6, 15 SP5, 15 SP4, 15 SP3, 15 SP2, 15 SP1, 15 SP0, 12, 11 SP4, 11 SP3
• Ubuntu 22.04, 21.04, 20.04, 19.04, 19.10, 18.04LTS, 16.04LTS, 14.04LTS
• Kali Linux (2016, 2017, 2018, 2019, 2020, 2021, 2022)
• Debian 13, 12, 11, 10, 9, 8, 7
• Oracle Linux 10, 9, 8, 7.7-CI, 7.7, 6
• Alma Linux 10.x, 8.x, 9.x
• Rocky Linux 10.x, 8.x, 9.x

Sie können diesen Artikel auch verwenden, um die virtuellen Computer manuell für die Migration auf Azure für die oben nicht aufgeführten Versionen von Betriebssystemen vorzubereiten. Diese Änderungen umfassen auf hoher Ebene Folgendes:

• Überprüfen des Vorhandenseins der erforderlichen Treiber
• Aktivieren der seriellen Konsole
• Konfigurieren der Netzwerkeinstellungen
• Installieren des VM-Gast-Agents

Hydrationsvorgang

Sie müssen vor der Migration einige Änderungen an der VMs-Konfiguration vornehmen, um sicherzustellen, dass die migrierten VMs auf Azure ordnungsgemäß funktionieren. Azure Migrate behandelt diese Konfigurationsänderungen über den Prozess hydration. Der Hydratationsprozess wird nur für die oben genannten Versionen von durch Azure unterstützten Betriebssystemen ausgeführt. Vor der Migration müssen Sie möglicherweise erforderliche Änderungen manuell für andere Betriebssystemversionen vornehmen, die oben nicht aufgeführt sind. Wenn die VM ohne die erforderlichen Änderungen migriert wird, wird sie möglicherweise nicht gestartet, oder Sie verfügen nicht über eine Verbindung mit der migrierten VM. Das folgende Diagramm zeigt, dass Azure Migrate den Hydratationsprozess ausführt.

Wenn ein Benutzer Test Migrate oder Migrate auslöst, führt Azure Migrate den Hydratationsprozess aus, um die lokale VM für die Migration zu Azure vorzubereiten. Um den Hydratationsprozess einzurichten, erstellt Azure Migrate einen temporären Azure virtuellen Computer und fügt die Datenträger der Quell-VM an, um Änderungen vorzunehmen, um die Quell-VM für Azure vorzubereiten. Die temporäre Azure VM ist eine zwischengeschaltete VM, die während des Migrationsprozesses erstellt wurde, bevor die endgültige migrierte VM erstellt wird. Die temporäre VM wird mit einem ähnlichen Betriebssystemtyp (Windows/Linux) unter Verwendung eines der Betriebssystem-Images aus dem Marketplace erstellt. Wenn die lokale VM Windows ausgeführt wird, wird der Betriebssystemdatenträger der lokalen VM als Datenträger an den temporären virtuellen Computer angefügt, um Änderungen auszuführen. Wenn es sich um einen Linux-Server handelt, werden alle Datenträger, die an die lokale VM angefügt sind, als Datenträger an die temporäre Azure VM angefügt.

Azure Migrate erstellt die Netzwerkschnittstelle, ein neues virtuelles Netzwerk, ein Subnetz und eine Netzwerksicherheitsgruppe (Network Security Group, NSG), um die temporäre VM zu hosten. Diese Ressourcen werden im Abonnement des Kunden erstellt. Wenn es in Konflikt stehende Richtlinien gibt, die die Erstellung der Netzwerkartefakte verhindern, versucht Azure Migrate, die temporäre Azure-VM im virtuellen Netzwerk und Subnetz zu erstellen, das als Teil der Optionen für die Replikationszieleinstellungen bereitgestellt wird.

Nachdem der virtuelle Computer erstellt wurde, ruft Azure Migrate die Custom Script Extension auf der temporären VM mithilfe der REST-API des Azure virtuellen Computers auf. Das Hilfsprogramm für die benutzerdefinierte Skripterweiterung führt ein Vorbereitungsskript mit der erforderlichen Konfiguration für die Azure-Bereitschaft auf den lokalen VM-Datenträgern aus, die an die temporäre Azure-VM angefügt sind. Das Vorbereitungsskript wird von einem von Azure Migrate verwalteten Speicherkonto heruntergeladen. Die Netzwerksicherheitsgruppenregeln des virtuellen Netzwerks werden so konfiguriert, dass die temporäre Azure VM auf das Azure Migrate Speicherkonto zugreifen kann, um das Skript aufrufen zu können.

Während des Hydrationsprozesses durchgeführte Änderungen

Das Vorbereitungsskript führt die folgenden Änderungen basierend auf dem Betriebssystemtyp der zu migrierenden Quell-VM aus. Sie können diesen Abschnitt auch als Leitfaden verwenden, um die VMs manuell auf die Migration für Betriebssystemversionen vorzubereiten, für die Hydration nicht unterstützt wird.

Änderungen, die auf Windows Servern ausgeführt wurden

1. Ermittlung und Vorbereiten des Windows Betriebssystemvolumes

   Vor dem Ausführen relevanter Konfigurationsänderungen überprüft das Vorbereitungsskript, ob der richtige Betriebssystemdatenträger für die Migration ausgewählt wurde. Das Vorbereitungsskript durchsucht alle angefügten Volumes, die für das System sichtbar sind, und sucht nach dem SYSTEM-Registrierungsstruktur-Dateipfad, um das Quellbetriebssystemvolume zu finden.

   Die folgenden Aktionen werden in diesem Schritt ausgeführt:

   • Einbinden jeder Partition auf dem Betriebssystemdatenträger, der an die temporäre VM angefügt ist.

   • Sucht nach \Windows\System32\Config\Systemregistrierungsdateien nach dem Einbinden der Partition.

   • Wenn die Dateien nicht gefunden werden, wird die Bereitstellung der Partition aufgehoben, und die Suche nach der richtigen Partition wird fortgesetzt.

   • Wenn die Dateien nicht auf einer der Partitionen vorhanden sind, kann dies darauf hinweisen, dass ein falscher Betriebssystemdatenträger ausgewählt wurde oder der Betriebssystemdatenträger beschädigt ist. Azure Migrate schlägt den Migrationsprozess mit einem entsprechenden Fehler fehl.

   Hinweis

   Dieser Schritt ist nicht relevant, wenn Sie die Server manuell für die Migration vorbereiten.

2. Vornehmen von Start- und Konnektivitätsänderungen

   Nachdem die Dateien des Quellbetriebssystemvolumes erkannt wurden, lädt das Vorbereitungsskript die SYSTEM-Registrierungsstruktur in den Registrierungs-Editor der temporären Azure-VM und führt die folgenden Änderungen aus, um den VM-Start und Konnektivität sicherzustellen. Sie müssen diese Einstellungen manuell konfigurieren, wenn die Betriebssystemversion nicht für Hydration unterstützt wird.

   1. Überprüfen des Vorhandenseins der erforderlichen Treiber

      Stellen Sie sicher, dass die erforderlichen Treiber installiert und so festgelegt sind, dass sie beim Start geladen werden. Diese Windows Treiber ermöglichen es dem Server, mit der Hardware und anderen verbundenen Geräten zu kommunizieren.

      • IntelIde.sys
      • Atapi
      • Storflt
      • Storvsc
      • VMbus

   2. Festlegen der SAN-Richtlinie (Storage Area Network) auf „Online All“

      Dadurch wird sichergestellt, dass die Windows-Volumes in der Azure-VM dieselben Laufwerksbuchstabenzuweisungen wie die lokalen VM verwenden. Standardmäßig werden Azure VMs Laufwerk D zugewiesen, die als temporärer Speicher verwendet werden sollen. Diese Laufwerkzuweisung führt dazu, dass alle anderen angefügten Zuweisungen von Speicherlaufwerken um einen Buchstaben inkrementiert werden. Um diese automatische Zuweisung zu verhindern und sicherzustellen, dass Azure dem temporären Volume den nächsten freien Laufwerkbuchstaben zuweist, legen Sie die SAN-Richtlinie (Storage Area Network) auf "Online All" fest.

      Konfigurieren Sie diese Einstellung manuell wie folgt:

      • Öffnen Sie auf dem lokalen Server die Eingabeaufforderung mit erhöhten Rechten, und geben Sie diskpart ein.

        

      • Geben Sie SAN ein. Wenn der Laufwerkbuchstabe des Gastbetriebssystems nicht beibehalten wird, wird Offline – Alle oder Offline – Freigegeben zurückgegeben.

      • Geben Sie an der Eingabeaufforderung DISKPART Folgendes ein: SAN Policy=OnlineAll. Durch diese Einstellung wird sichergestellt, dass Datenträger online geschaltet werden und dass Sie von beiden Datenträgern lesen sowie auf beide Datenträger schreiben können.

        

3. Festlegen des DHCP-Starttyps

   Das Vorbereitungsskript legt auch den Starttyp des DHCP-Diensts auf „Automatisch“ fest. Dadurch kann die migrierte VM eine IP-Adresse abrufen und Konnektivität nach der Migration herstellen. Stellen Sie sicher, dass der DHCP-Dienst konfiguriert ist und der Status „wird ausgeführt“ lautet.

   

   Führen Sie zum manuellen Bearbeiten der DHCP-Starteinstellungen das folgende Beispiel in Windows PowerShell aus:

   Get-Service -Name Dhcp
   Where-Object StartType -ne Automatic
   Set-Service -StartupType Automatic
   

4. Deaktivieren von VMware Tools

   Deaktivieren Sie den Dienststarttyp "VMware Tools", wenn er vorhanden ist, da sie für den virtuellen Computer in Azure nicht erforderlich sind.

   Hinweis

   Um eine Verbindung mit Windows Server 2003-VMs herzustellen, müssen Hyper-V Integrationsdienste auf dem virtuellen computer Azure installiert sein. Windows Server 2003-Computer haben dies nicht standardmäßig installiert. Weitere Informationen zur Installation und Vorbereitung der Migration finden Sie in diesem Artikel.

5. Installieren Sie den Windows Azure Gast-Agent

   Azure Migrate versucht, den Microsoft Azure Virtual Machine Agent (VM-Agent), einen sicheren, einfachen Prozess zu installieren, der die Interaktion virtueller Computer (VM) mit dem Azure Fabric Controller verwaltet. Der VM-Agent hat eine primäre Rolle beim Aktivieren und Ausführen von Azure Erweiterungen virtueller Computer, die die Konfiguration nach der Bereitstellung von VM ermöglichen, z. B. installieren und konfigurieren von Software. Azure Migrate installiert automatisch den Windows VM-Agent auf Windows Server 2008 R2 und höheren Versionen.

   Der Windows VM-Agent kann manuell mit einem Windows Installationspaket installiert werden. Um den Windows VM-Agent manuell zu installieren, laden Sie den VM-Agent-Installer herunter. Sie können auch in den GitHub Windows IaaS VM Agent-Versionen nach einer bestimmten Version suchen. Der VM-Agent wird unter Windows Server 2008 (64 Bit) und höher unterstützt.

   Um zu überprüfen, ob der Azure VM-Agent erfolgreich installiert wurde, wechseln Sie zur Registerkarte Task Manager, wählen Sie die Registerkarte Details aus, und suchen Sie nach dem Prozessnamen WindowsAzureGuestAgent.exe. Ist dieser Prozess vorhanden, ist der VM-Agent installiert. Sie können auch PowerShell verwenden, um den VM-Agent zu erkennen.

   

   Nachdem die oben genannten Änderungen vorgenommen wurden, wird die Systempartition entladen. Die VM ist nun bereit für die Migration. Weitere Informationen zu den Änderungen für Windows server.

Auf Linux-Servern vorgenommene Änderungen

1. Ermitteln und Einbinden von Partitionen des Linux-Betriebssystems

   Vor dem Ausführen relevanter Konfigurationsänderungen überprüft das Vorbereitungsskript, ob der richtige Betriebssystemdatenträger für die Migration ausgewählt wurde. Das Skript sammelt Informationen zu allen Partitionen, ihren UUIDs und Bereitstellungspunkten. Das Skript durchsucht alle diese sichtbaren Partitionen, um die Partitionen /boot und /root zu finden.

   Die folgenden Aktionen werden in diesem Schritt ausgeführt:

   • Entdecken der /root-Partition:
     • Binden Sie jede sichtbare Partition ein, und suchen Sie nach „etc/fstab“.
     • Wenn die fstab-Dateien nicht gefunden werden, wird die Bereitstellung der Partition aufgehoben, und die Suche nach der richtigen Partition wird fortgesetzt.
     • Wenn die fstab-Dateien gefunden werden, lesen Sie den fstab-Inhalt, um das Stammgerät zu identifizieren, und binden Sie es als Basisbereitstellungspunkt ein.
   • Entdecken der /boot-Partition und anderer Systempartitionen:
     • Verwenden Sie den fstab-Inhalt, um zu bestimmen, ob /boot eine separate Partition ist. Wenn es sich um eine separate Partition handelt, rufen Sie den Gerätenamen der Startpartition aus dem fstab-Inhalt ab, oder suchen Sie nach der Partition, die über das Startflag verfügt.
     • Das Skript wird mit der Suche und Einbinden der /boot-Partition und anderen erforderlichen Partitionen auf „/mnt/azure_sms_root“ fortfahren, um die Stammdateisystemstruktur zu erstellen, die für chroot jail benötigt wird. Andere erforderliche Partitionen sind: /boot/grub/menu.lst, /boot/grub/menu.lst, /boot/grub/grub.conf, /boot/grub2/grub.cfg, /boot/grub/grub.cfg, /boot/efi (for UEFI boot), /var, /lib, /etc, /usr und andere.

2. Ermitteln der Betriebssystemversion

   Nachdem die Stammpartition ermittelt wurde, verwendet das Skript die folgenden Dateien, um die Distribution und Version des Linux-Betriebssystems zu bestimmen.

   • RHEL: etc/redhat-release
   • OL: /etc/oracle-release
   • SLES: /etc/SuSE-release
   • Ubuntu: etc/lsb-release
   • Debian: /etc/debian_version

3. Install Hyper-V Linux Integration Services und regenerieren Sie das Kernelimage

   Der nächste Schritt besteht darin, das Kernelimage zu prüfen und das Linux-Init-Image neu zu erstellen, sodass es die erforderlichen Hyper-V Treiber (hv_vmbus, hv_storvsc, hv_netvsc) auf der ersten Ramdisk enthält. Durch die Neuerstellung des Init-Images wird sichergestellt, dass der virtuelle Computer in Azure gestartet wird.

   Azure wird auf dem Hyper-V Hypervisor ausgeführt. Daher erfordert Linux, dass bestimmte Kernelmodule in Azure ausgeführt werden. Sie müssen „initrd“ neu erstellen, damit mindestens die Kernelmodule „hv_vmbus“ und „hv_storvsc“ auf der anfänglichen Ramdisk verfügbar sind. Der Mechanismus für die Neuerstellung des Images "initrd" oder "initramfs" variiert je nach der Verteilung. In der Dokumentation zur Distribution oder über den Support erhalten Sie Informationen zur geeigneten Vorgehensweise. Hier sehen Sie ein Beispiel für die Neuerstellung von „initrd“ mit dem Hilfsprogramm mkinitrd:

   1. Suchen der Liste der auf dem System installierten Kernels (/lib/modules)

   2. Prüfen Sie für jedes Modul, ob die Hyper-V Treiber bereits enthalten sind.

   3. Wenn einer dieser Treiber fehlt, fügen Sie die erforderlichen Treiber hinzu, und generieren Sie das Image für die entsprechende Kernelversion neu.

      Hinweis

      Dieser Schritt gilt möglicherweise nicht für Ubuntu- und Debian-VMs, da die Hyper-V Treiber standardmäßig integriert sind. Weitere Informationen zu den Änderungen.

      Ein veranschaulichendes Beispiel für die Neuerstellung von „initrd“

      • Sichern des vorhandenen initrd-Images

       cd /boot
       sudo cp initrd-`uname -r`.img  initrd-`uname -r`.img.bak
      

      • Erstellen Sie „initrd“ mit den Kernelmodulen „hv_vmbus“ und „hv_storvsc“ neu:

         sudo mkinitrd --preload=hv_storvsc --preload=hv_vmbus -v -f initrd-`uname -r`.img `uname -r`
      

   In den meisten neuen Versionen von Linux-Distributionen ist dies standardmäßig enthalten. Andernfalls muss die Installation für alle nicht angegebenen Versionen manuell mithilfe der oben genannten Schritte durchgeführt werden.

4. Aktivieren der Azure-Protokollierung für serielle Konsolen

   Das Skript nimmt dann Änderungen vor, um Azure serielle Konsolenprotokollierung zu aktivieren. Das Aktivieren der Konsolenprotokollierung hilft bei der Problembehandlung auf dem virtuellen Computer Azure. Erfahren Sie mehr über Azure serielle Konsole für Linux Azure serielle Konsole für Linux – Virtual Machines | Microsoft-Dokumentation.

   Ändern Sie die Zeile für den Kernelstart in GRUB oder GRUB2 so, dass die folgenden Parameter eingeschlossen werden. Auf diese Weise werden alle Konsolennachrichten an den ersten seriellen Port gesendet. Diese Nachrichten können Azure-Support beim Debuggen von Problemen unterstützen.

    console=ttyS0,115200n8 earlyprintk=ttyS0,115200 rootdelay=300
   

   Wir empfehlen zudem, die folgenden Parameter zu entfernen, sofern sie vorhanden sind.

   rhgb quiet crashkernel=auto
   

   Weitere Informationen zu spezifischen Änderungen finden Sie in diesem Artikel.

5. Netzwerkänderungen für Konnektivität

   Basierend auf der Betriebssystemversion führt das Skript die erforderlichen Netzwerkänderungen für Konnektivität mit der migrierten VM aus. Zu den Änderungen zählt Folgendes:

   1. Verschieben (oder entfernen) Sie die udev-Regeln, um eine Generierung statischer Regeln für die Ethernet-Schnittstelle zu vermeiden. Diese Regeln verursachen Probleme, wenn Sie einen virtuellen Computer in Azure klonen.

      Ein veranschaulichendes Beispiel für RedHat-Server

         sudo ln -s /dev/null /etc/udev/rules.d/75-persistent-net-generator.rules
         sudo rm -f /etc/udev/rules.d/70-persistent-net.rules
      

   2. Entfernen Sie den Netzwerk-Manager, wenn erforderlich. Netzwerk-Manager kann den Azure Linux-Agent für einige Betriebssystemversionen beeinträchtigen. Es wird empfohlen, diese Änderungen für Server vorzunehmen, auf denen RedHat- und Ubuntu-Distributionen ausgeführt werden.

   3. Deinstallieren Sie dieses Paket, indem Sie den folgenden Befehl ausführen:

      Ein veranschaulichendes Beispiel für RedHat-Server

         sudo rpm -e --nodeps NetworkManager
      

   4. Sichern Sie vorhandene NIC-Einstellungen, und erstellen Sie eine eth0-NIC-Konfigurationsdatei mit DHCP-Einstellungen. Hierzu erstellt oder bearbeitet das Skript die Datei /etc/sysconfig/network-scripts/ifcfg-eth0 und fügt den folgenden Text hinzu:

      Ein veranschaulichendes Beispiel für RedHat-Server

         DEVICE=eth0
         ONBOOT=yes
         BOOTPROTO=dhcp
         TYPE=Ethernet
         USERCTL=no
         PEERDNS=yes
         IPV6INIT=no
         PERSISTENT_DHCLIENT=yes
         NM_CONTROLLED=yes
      

   5. Setzen Sie die Datei etc/sysconfig/network wie folgt zurück:

      Ein veranschaulichendes Beispiel für RedHat-Server

         NETWORKING=yes
         HOSTNAME=localhost.localdomain
      

6. Fstab-Prüfung

   Azure Migrate überprüft die Einträge der Datei "fstab" und ersetzt fstab-Einträge durch persistente Volumebezeichner bzw. UUIDs, wo immer nötig. Dadurch wird sichergestellt, dass der Laufwerks-/Partitionsname unabhängig von dem System, an das er angefügt ist, konstant bleibt.

   • Wenn der Gerätename ein Standardgerätename ist (z. B. /dev/sdb1), gilt Folgendes:
     • Wenn es sich um eine Stamm- oder Startpartition handelt, wird sie durch UUID ersetzt.
     • Wenn die Partition gleichzeitig mit der Stamm- oder Startpartition als Standardpartitionen auf demselben Datenträger vorhanden ist, wird sie durch UUID ersetzt.
   • Wenn der Gerätename UUID/LABEL/LV ist, werden keine Änderungen vorgenommen.
   • Wenn es sich um ein Netzwerkgerät (nfs, cifs, smbfs und etc) handelt, kommentiert das Skript den Eintrag. Um darauf zuzugreifen, können Sie die Auskommentierung aufheben und die Azure-VM neu starten.

7. Installieren Sie den Linux Azure Guest Agent

   Azure Migrate wird versuchen, den Microsoft Azure Linux-Agent (waagent) zu installieren, einen sicheren und leichten Prozess, der die Bereitstellung von Linux und FreeBSD sowie die Interaktion der VM mit dem Azure Fabric Controller verwaltet. Erfahren Sie mehr über die Funktionen, die für Linux- und FreeBSD-IaaS-Bereitstellungen über den Linux-Agent aktiviert sind.

   Sehen Sie sich die Liste der erforderlichen Pakete zum Installieren des Linux-VM-Agents an. Azure Migrate installiert den Linux-VM-Agent automatisch für RHEL 10.x, 9.x, 8.x/7.x/6.x, Ubuntu 14.04/16.04/18.04/19.04/19.10/20.04, SUSE 15 SP0/15 SP1/12, Debian 13/12/11/10/9/8/7 und Oracle 10/9/8/7/6 bei Verwendung der agentlosen Methode der VMware-Migration. Befolgen Sie diese Anweisungen, um den Linux-Agent manuell für andere Betriebssystemversionen zu installieren.

   Mit dem Befehl können Sie den Dienststatus des Azure Linux-Agents überprüfen, um sicherzustellen, dass er ausgeführt wird. Der Dienstname kann walinuxagent oder waagent lauten. Nachdem die Hydrationsänderungen vorgenommen wurden, hebt das Skript die Bereitstellung aller eingebundenen Partitionen auf, deaktiviert Volumegruppen und löscht dann die Geräte.

      sudo vgchange -an <vg-name>
      sudo lockdev –flushbufs <disk-device-name>
   

   Weitere Informationen zu den Änderungen für Linux-Server.

Bereinigen der temporären VM

Nachdem die erforderlichen Änderungen vorgenommen wurden, wird Azure Migrate den temporären virtuellen Computer herunterdrehen und die angefügten Betriebssystemdatenträger (und Datenträger) freigeben. Dieser Vorgang markiert das Ende des Hydrationsprozesses.

Danach werden der geänderte Betriebssystemdatenträger und die Datenträger, die die replizierten Daten enthalten, geklont. Ein neuer virtueller Computer wird in der Zielregion, im virtuellen Netzwerk und im Subnetz erstellt, und die geklonten Datenträger werden an den virtuellen Computer angefügt. Dieser Vorgang kennzeichnet den Abschluss des Migrationsprozesses.

Erfahren Sie mehr

• Vorbereiten lokaler Computer für die Migration zu Azure.