Vorbereiten von Linux für die Imageerstellung in Azure

Gilt für: ✔️ Linux-VMs ✔️ Flexible Skalierungsgruppen

Der Azure Service Level Agreement (SLA) der Plattform gilt nur für virtuelle Computer (VMs), die das Linux-Betriebssystem ausführen, wenn Sie eine der unterstützten Distributionen verwenden. Für unterstützte Verteilungen stellt Azure Marketplace vorkonfigurierte Linux-Images bereit. Weitere Informationen findest du unter:

• Unterstützte Linux-Distributionen auf Azure
• Unterstützung für Linux und Open-Source-Technologie in Azure

Für alle anderen Distributionen, die auf Azure ausgeführt werden, einschließlich von der Community unterstützter und nicht empfohlener Distributionen, gelten einige Voraussetzungen.

Dieser Artikel konzentriert sich auf allgemeine Anleitungen für die Ausführung Ihrer Linux-Verteilung auf Azure. Dieser Artikel kann nicht umfassend sein, da jede Verteilung anders ist. Auch wenn Sie alle in diesem Artikel beschriebenen Kriterien erfüllen, müssen Sie ihr Linux-System möglicherweise erheblich optimieren, damit es ordnungsgemäß ausgeführt wird.

Allgemeine Linux-Installationshinweise

• Azure unterstützt das Hyper-V virtuellen Festplattenformat (VHDX) nicht. Azure unterstützt nur feste virtuelle Festplatten. Sie können den Datenträger in das VHD-Format konvertieren, indem Sie Hyper-V Manager oder das Cmdlet Convert-VHD verwenden. Wenn Sie VirtualBox verwenden, wählen Sie beim Erstellen des Datenträgers die Option "Feste Größe" anstelle der Standardgröße (dynamisch zugewiesen) aus.

• Azure unterstützt virtuelle Gen1-Computer (BIOS-Start) und Gen2 (UEFI-Start).

• Das Kernelmodul für die virtuelle Dateizuordnungstabelle (VFAT) muss im Kernel aktiviert sein.

• Die für die VHD zulässige maximale Größe beträgt 1.023 GB.

• Wenn Sie das Linux-System installieren, empfehlen wir, Standardpartitionen anstelle von Logical Volume Manager (LVM) zu verwenden. LVM ist die Standardeinstellung für viele Installationen.

  Durch die Verwendung von Standardpartitionen werden LVM-Namenskonflikte mit geklonten VMs vermieden, insbesondere, wenn ein Betriebssystemdatenträger jemals an eine andere identische VM zur Problembehandlung angefügt ist. Sie können LVM oder RAID auf Datenträgern verwenden.

• Kernelunterstützung für das Einbinden von benutzerdefinierten Funktionsdateisystemen (User-Defined Function, UDF) ist erforderlich. Beim ersten Start auf Azure wird die Bereitstellungskonfiguration über UDF-formatierte Medien, die an den Gast angefügt sind, an die Linux-VM übergeben. Der Azure Linux-Agent muss das UDF-Dateisystem bereitstellen, um seine Konfiguration zu lesen und die VM bereitzustellen.

• Linux-Kernelversionen vor 2.6.37 unterstützen keinen nicht uniformen Speicherzugriff (NON-Uniform Memory Access, NUMA) auf Hyper-V mit größeren VM-Größen. Dieses Problem betrifft in erster Linie ältere Distributionen, die den upstream-Red Hat 2.6.32-Kernel verwenden. Es wurde in Red Hat Enterprise Linux (RHEL) 6.6 (kernel-2.6.32-504) behoben.

  Systeme mit benutzerdefinierten Kerneln, die älter als 2.6.37 sind, oder RHEL-basierte Kernel, die älter als 2.6.32-504 sind, müssen den Startparameter numa=off in der Kernel-Befehlszeile in grub.conf festlegen. Weitere Informationen finden Sie unter Red Hat KB 436883.

• Konfigurieren Sie keine Auslagerungspartition auf dem Betriebssystemdatenträger. Sie können den Linux-Agent so konfigurieren, dass eine Swapdatei auf dem temporären Ressourcendatenträger erstellt wird, wie weiter unten in diesem Artikel beschrieben.

• Alle VHDs auf Azure müssen eine virtuelle Größe aufweisen, die auf 1 MB ausgerichtet ist (1024 x 1024 Byte). Stellen Sie beim Konvertieren von einem Rohdatenträger in VHD sicher, dass die Rohdatenträgergröße vor der Konvertierung ein Vielfaches von 1 MB ist, wie weiter unten in diesem Artikel beschrieben.

• Verwenden Sie die neuesten Versionen der Distribution, der Pakete und der Software.

• Entfernen Sie Benutzer und Systemkonten, öffentliche Schlüssel, vertrauliche Daten, unnötige Software und Anwendungen.

Installieren von Kernelmodulen ohne Hyper-V

Azure läuft auf dem Hyper-V-Hypervisor, daher benötigt Linux bestimmte Kernelmodule, um in Azure ausgeführt zu werden. Wenn Sie über einen virtuellen Computer verfügen, der außerhalb Hyper-V erstellt wurde, enthalten die Linux-Installationsprogramme möglicherweise nicht die Treiber für Hyper-V in der ersten RAM-Festplatte (initrd oder initramfs), es sei denn, die VM erkennt, dass sie in einer Hyper-V Umgebung ausgeführt wird.

Wenn Sie ein anderes Virtualisierungssystem (z. B. VirtualBox oder KVM) zur Vorbereitung Ihres Linux-Images verwenden, müssen Sie initrd möglicherweise neu erstellen, damit mindestens die hv_vmbus- und hv_storvsc-Kernelmodule in der initialen RAM-Disk verfügbar sind. Dieses bekannte Problem betrifft Systeme, die auf der Upstream-Distribution von Red Hat basieren, und möglicherweise auch andere.

Der Mechanismus zum Neuerstellen des Initrd- oder Initramfs-Bilds kann je nach Verteilung variieren. 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. Sichern Sie das vorhandene initrd-Bild:

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

2. Erstellen Sie die initrd mithilfe der Kernelmodule hv_vmbus und hv_storvsc neu:

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

Ändern der Größe von VHDs

VHD-Images in Azure müssen eine virtuelle Größe haben, die an 1 MB ausgerichtet ist. Normalerweise werden VHDs, die über Hyper-V erstellt wurden, korrekt ausgerichtet. Wenn die VHD nicht ordnungsgemäß ausgerichtet ist, wird möglicherweise eine Fehlermeldung wie im folgenden Beispiel angezeigt, wenn Sie versuchen, ein Bild aus Ihrer VHD zu erstellen:

The VHD http://<mystorageaccount>.blob.core.windows.net/vhds/MyLinuxVM.vhd has an unsupported virtual size of 21475270656 bytes. The size must be a whole number (in MBs).

Ändern Sie in diesem Fall die Größe des virtuellen Computers mithilfe der Hyper-V-Manager-Konsole oder des PowerShell-Cmdlets "Resize-VHD ". Wenn Sie nicht in einer Windows-Umgebung arbeiten, empfehlen wir die Verwendung von qemu-img, um die VHD zu konvertieren (falls erforderlich) und ihre Größe zu ändern.

1. Das direkte Ändern der Größe der virtuellen Festplatte mithilfe von Tools wie qemu-img oder vbox-manage kann dazu führen, dass die virtuelle Festplatte nicht startfähig ist. Es wird empfohlen, zuerst die VHD in ein Rohdatenträgerimage mithilfe des folgenden Codes zu konvertieren.

   Wenn das VM-Image als Rohdatenträgerimage erstellt wurde, können Sie diesen Schritt überspringen. Das Erstellen des VM-Images als Rohdatenträgerabbild ist bei einigen Hypervisoren, etwa KVM, die Standardeinstellung.

   sudo qemu-img convert -f vpc -O raw MyLinuxVM.vhd MyLinuxVM.raw
   

2. Berechnen Sie die erforderliche Größe des Festplatten-Images, so dass die virtuelle Größe an 1 MB ausgerichtet ist. Das folgende Bash-Shell-Skript verwendet qemu-img info, um die virtuelle Größe des Datenträgerimages zu ermitteln, und berechnet dann die Größe bis zum nächsten MB-Wert:

   rawdisk="MyLinuxVM.raw"
   vhddisk="MyLinuxVM.vhd"
   
   MB=$((1024*1024))
   size=$(qemu-img info -f raw --output json "$rawdisk" | \
   gawk 'match($0, /"virtual-size": ([0-9]+),/, val) {print val[1]}')
   
   rounded_size=$(((($size+$MB-1)/$MB)*$MB))
   
   echo "Rounded Size = $rounded_size"
   

3. Ändern Sie die Größe des Rohdatenträgers mithilfe von $rounded_size:

   sudo qemu-img resize MyLinuxVM.raw $rounded_size
   

4. Konvertieren Sie den Rohdatenträger wieder in eine VHD mit fester Größe:

   sudo qemu-img convert -f raw -o subformat=fixed,force_size -O vpc MyLinuxVM.raw MyLinuxVM.vhd
   

   Oder entfernen Sie mit QEMU-Versionen vor 2.6 die force_size Option:

   sudo qemu-img convert -f raw -o subformat=fixed -O vpc MyLinuxVM.raw MyLinuxVM.vhd
   

Linux-Kernelanforderungen

Die LiS-Treiber (Linux Integration Services) für Hyper-V und Azure werden direkt zum upstream Linux-Kernel beigetragen. Viele Distributionen, die eine aktuelle Linux-Kernelversion enthalten (z. B. 3.x), verfügen bereits über diese Treiber oder stellen auf andere Weise backportierte Versionen dieser Treiber mit ihren Kerneln bereit.

LIS-Treiber werden ständig im Upstream-Kernel mit neuen Fixes und Features aktualisiert. Wenn möglich, empfehlen wir, eine genehmigte Verteilung auszuführen, die diese Fixes und Updates enthält.

Wenn Sie eine Variante von RHEL-Versionen 6.0 bis 6.3 ausführen, müssen Sie die neuesten LIS-Treiber für Hyper-V installieren. Ab RHEL 6.4+ (und Ableitungen) sind die LIS-Treiber bereits im Kernel enthalten, daher benötigen Sie keine zusätzlichen Installationspakete.

Wenn ein benutzerdefinierter Kernel erforderlich ist, empfehlen wir eine aktuelle Kernelversion (z. B. 3.8+). Für Verteilungen oder Anbieter, die ihren eigenen Kernel verwalten, müssen Sie die LIS-Treiber regelmäßig vom Upstream-Kernel in Ihren benutzerdefinierten Kernel zurückportieren.

Selbst wenn Sie bereits eine relativ aktuelle Kernelversion ausführen, empfehlen wir dringend, alle Upstream-Fixes in den LIS-Treibern nach Bedarf nachzuverfolgen und zu portieren. Die Speicherorte der LIS-Treiberquelldateien werden in der MAINTAINERS-Datei in der Linux-Kernelquellstruktur angegeben:

    F:    arch/x86/include/asm/mshyperv.h
    F:    arch/x86/include/uapi/asm/hyperv.h
    F:    arch/x86/kernel/cpu/mshyperv.c
    F:    drivers/hid/hid-hyperv.c
    F:    drivers/hv/
    F:    drivers/input/serio/hyperv-keyboard.c
    F:    drivers/net/hyperv/
    F:    drivers/scsi/storvsc_drv.c
    F:    drivers/video/fbdev/hyperv_fb.c
    F:    include/linux/hyperv.h
    F:    tools/hv/

Der aktive Kernel des virtuellen Computers muss die folgenden Patches enthalten. Diese Liste kann nicht für alle Distributionen vollständig sein.

• ata_piix: Datenträger standardmäßig an die Hyper-V-Treiber übergeben
• storvsc: Berücksichtigung von Paketen während der Übertragung im RESET-Pfad
• storvsc: Verwendung von WRITE_SAME vermeiden
• storvsc: Deaktivierung von WRITE SAME für RAID- und virtuelle Hostadaptertreiber
• storvsc: Behebung der NULL-Zeiger-Dereferenzierung
• storvsc: Ringpufferfehler können dazu führen, dass E/A eingefroren wird.
• scsi_sysfs: Schutz vor doppelter Ausführung von __scsi_remove_device

Azure Linux-Agent

Der Azure Linux-Agent (waagent) stellt einen virtuellen Linux-Computer in Azure bereit. Sie können die neueste Version abrufen, Probleme melden oder Pullanforderungen an den Linux-Agent GitHub Repository übermitteln.

Im Folgenden finden Sie einige Überlegungen zur Verwendung des Azure Linux-Agents:

• Der Linux-Agent wird unter der Apache 2.0-Lizenz veröffentlicht. Viele Distributionen stellen bereits .rpm- oder .deb-Pakete für den Agent bereit. Sie können diese Pakete ganz einfach installieren und aktualisieren.
• Der Azure Linux-Agent erfordert Python v2.6+.
• Der Agent erfordert auch das python-pyasn1 Modul. Die meisten Verteilungen stellen dieses Modul als separates Paket bereit, das installiert werden soll.
• In einigen Fällen ist der Azure Linux-Agent möglicherweise nicht mit NetworkManager kompatibel. Viele der von Distributionen bereitgestellten Pakete (.rpm oder .deb) deklarieren NetworkManager als in Konflikt mit dem Paket waagent. In diesen Fällen deinstalliert der Agent NetworkManager, wenn Sie das Linux-Agent-Paket installieren.
• Der Azure Linux-Agent muss in der mindestens unterstützten Version oder höher sein.

Allgemeine Linux-Systemanforderungen

1. Ä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 helfen dem Azure-Supportteam beim Debuggen von Problemen.

   GRUB_CMDLINE_LINUX="rootdelay=300 console=ttyS0 earlyprintk=ttyS0 net.ifnames=0"
   

   Es wird auch empfohlen, die folgenden Parameter zu entfernen , falls vorhanden:

   rhgb quiet crashkernel=auto
   

   Der grafische und ruhige Start ist in einer Cloudumgebung nicht hilfreich, in der alle Protokolle an den seriellen Port gesendet werden sollen. Sie können die crashkernel Option bei Bedarf konfigurieren, aber dieser Parameter reduziert den verfügbaren Arbeitsspeicher auf dem virtuellen Computer um mindestens 128 MB. Das Verringern des verfügbaren Arbeitsspeichers kann für kleinere VM-Größen problematisch sein.

2. Nachdem Sie die Bearbeitung von /etc/default/grub abgeschlossen haben, erstellen Sie die GRUB-Konfiguration neu. Führen Sie nur den befehl aus, der für Ihre Verteilung geeignet ist.

   Führen Sie für Distributionen, die auf Debian oder Ubuntu basieren, Folgendes aus:

   sudo update-grub
   

   Führen Sie für Distributionen, die grub2-mkconfig bereitstellen, z. B. RHEL, Oracle Linux und SUSE, Folgendes aus:

   sudo grub2-mkconfig -o /boot/grub2/grub.cfg
   

   Auf Distributionen, die stattdessen grub-mkconfig bereitstellen, führen Sie Folgendes aus:

   sudo grub-mkconfig -o /boot/grub/grub.cfg
   

   Der GRUB-Konfigurationspfad kann sich für UEFI-Installationen unterscheiden. Wenn Ihre Verteilung einen anderen Pfad verwendet, verwenden Sie den für diese Verteilung dokumentierten Pfad.

3. Fügen Sie die Hyper-V Module zum ersten RAM-Datenträger hinzu. Führen Sie nur die Prozedur aus, die den von Ihrer Verteilung verwendeten Tools entspricht.

   1. Führen Sie für eine dracut-basierte Verteilung Folgendes aus:

   cd /boot
   sudo cp initramfs-<kernel-version>.img <kernel-version>.img.bak
   sudo dracut -f -v initramfs-<kernel-version>.img <kernel-version> --add-drivers "hv_vmbus hv_netvsc hv_storvsc"
   

   1. Führen Sie bei einer Verteilung, die mkinitramfs verwendet, dieses Verfahren anstelle des dracut-Verfahrens aus:

   cd /boot
   sudo cp initrd.img-<kernel-version> initrd.img-<kernel-version>.bak
   sudo mkinitramfs -o initrd.img-<kernel-version> <kernel-version> --with=hv_vmbus,hv_netvsc,hv_storvsc
   

4. Nur wenn Sie ein Image für einen NVMe-Remotedatenträgercontroller erstellen, konfigurieren und überprüfen Sie die NVMe-Startunterstützung. Überspringen Sie andernfalls diesen Schritt. Die genauen Befehle können je nach Verteilung variieren.

   1. Erstellen Sie das Initramfs mithilfe der für Ihre Distribution vorgesehenen Methode mit den NVMe-Treibern neu.

      Sorgen Sie bei einer dracut-basierten Distribution dafür, dass die NVMe-Treiber in zukünftigen initramfs-Images beibehalten werden, und erstellen Sie das aktuelle initramfs neu:

      sudo mkdir -p /etc/dracut.conf.d
      printf '%s\n' 'add_drivers+=" nvme nvme_core "' | sudo tee /etc/dracut.conf.d/azure-nvme.conf
      sudo dracut --force
      

      Für eine initramfs-tools-basierte Distribution machen Sie die NVMe-Treiber dauerhaft verfügbar und erstellen das Initramfs neu:

      printf '%s\n' nvme nvme_core | sudo tee -a /etc/initramfs-tools/modules
      sudo update-initramfs -u -k all
      

   2. Fügen Sie nvme_core.io_timeout=240 zur vorhandenen Kernel-Befehlszeile in /etc/default/grub hinzu, und erstellen Sie dann die GRUB-Konfiguration neu, indem Sie den für Ihre Distribution passenden Befehl verwenden.

   3. Stellen Sie sicher, dass beide NVMe-Treibermodule auf dem System verfügbar sind. Führen Sie beide Befehle aus:

      modinfo nvme
      modinfo nvme_core
      

      Jeder Befehl muss Informationen zu seinem Modul zurückgeben. Wenn eines der beiden Module nicht gefunden wird, installieren oder aktivieren Sie es gemäß der Dokumentation Ihrer Distribution, bevor Sie fortfahren.

   4. Stellen Sie sicher, dass beide NVMe-Treiber in initramfs enthalten sind. Führen Sie nur den Befehl für Ihre Verteilung aus.

      Führen Sie für eine dracut-basierte Verteilung Folgendes aus:

      sudo lsinitrd /boot/initramfs-$(uname -r).img | grep -E 'nvme(_core)?\.ko'
      

      Führen Sie für eine initramfs-tools-basierte Verteilung Folgendes aus:

      sudo lsinitramfs /boot/initrd.img-$(uname -r) | grep -E 'nvme(_core)?\.ko'
      

      Die Ausgabe muss sowohl nvme_core als auch nvme Treiber anzeigen. Wenn dies nicht der Fall ist, lesen Sie die Dokumentation Ihrer Verteilung, und erstellen Sie den ursprünglichen RAM-Datenträger neu, bevor Sie fortfahren.

5. Stellen Sie sicher, dass der SSH-Server installiert und konfiguriert ist, damit er beim Booten hochfährt. Diese Konfiguration ist in der Regel die Standardeinstellung.

6. Installieren Sie den Azure Linux-Agent.

   Der Azure Linux-Agent ist für die Bereitstellung eines Linux-Images auf Azure erforderlich. Viele Verteilungen stellen den Agent als .rpm- oder .deb-Paket bereit. Das Paket wird in der Regel WALinuxAgent oder walinuxagent genannt. Sie können den Agent auch manuell installieren, indem Sie die Schritte im Handbuch zum Azure Linux-Agent ausführen.

   Note

   Stellen Sie sicher, dass die Module udf und vfat aktiviert sind. Das Entfernen oder Deaktivieren führt zu einem Bereitstellungs- oder Startfehler. Cloud-init Version 21.2 oder höher entfernt die UDF-Anforderung.

   Installieren Sie den Azure Linux-Agent, cloudinit und andere erforderliche Dienstprogramme. Führen Sie nur den Befehl für den Paket-Manager aus, der auf Ihrem System verfügbar ist.

   Führen Sie für dnf Folgendes aus:

    sudo dnf install -y WALinuxAgent cloud-init cloud-utils-growpart gdisk hyperv-daemons
   

   Wenn Ihr System yum anstelle von dnf bereitstellt, ersetzen Sie dnf im vorhergehenden Befehl durch yum.

   Führen Sie für apt Folgendes aus:

   sudo apt install walinuxagent cloud-init cloud-utils-growpart gdisk hyperv-daemons
   

   Führen Sie für zypper Folgendes aus:

   sudo zypper install python-azure-agent cloud-init cloud-utils-growpart gdisk hyperv-daemons
   

   Aktivieren Sie dann den Agent und die Cloud-Init für alle Verteilungen:

   sudo systemctl enable waagent.service
   sudo systemctl enable cloud-init.service
   

7. Erstellen Sie keinen Auslagerungsbereich auf dem Betriebssystemdatenträger.

   Sie können den Azure Linux-Agent oder cloudinit verwenden, um Swapspace über den lokalen Ressourcendatenträger zu konfigurieren. Azure fügt diesen Ressourcendatenträger nach der Bereitstellung an die VM an. Der lokale Ressourcendatenträger ist vorübergehend und wird möglicherweise geleert, wenn die Bereitstellung der VM aufgehoben wird.

   Important

   Diese Anweisungen gelten unabhängig davon, ob der Remote-Datenträgercontroller SCSI oder NVMe ist. Sie benötigen eine VM-Größe, die einen lokalen temporären Ressourcendatenträger enthält. Der Typ des Remotedatenträgercontrollers bestimmt nicht, ob ein Ressourcendatenträger verfügbar ist.

   1. Wählen Und konfigurieren Sie eine Methode zum Verwalten des Swapspaces.

      Um den Azure Linux-Agent zu verwenden, ändern Sie die folgenden Parameter in /etc/waagent.conf:

      ResourceDisk.Format=y
      ResourceDisk.Filesystem=ext4
      ResourceDisk.MountPoint=/mnt/resource
      ResourceDisk.EnableSwap=y
      ResourceDisk.SwapSizeMB=2048    ## NOTE: Set this to your desired size.
      

      Um stattdessen cloud-init zu verwenden, konfigurieren Sie cloud-init, um die Bereitstellung zu verarbeiten und zu verhindern, dass der Azure Linux-Agent den Ressourcendatenträger formatiert oder Swapspace erstellt:

      sudo sed -i 's/Provisioning.Agent=auto/Provisioning.Agent=cloud-init/g' /etc/waagent.conf
      sudo sed -i 's/ResourceDisk.Format=y/ResourceDisk.Format=n/g' /etc/waagent.conf
      sudo sed -i 's/ResourceDisk.EnableSwap=y/ResourceDisk.EnableSwap=n/g' /etc/waagent.conf
      

   2. Wenn Sie cloud-init ausgewählt haben, wählen Sie aus, wie die Swapkonfiguration bereitgestellt werden soll.

      Sie können jedes Mal, wenn Sie eine VM erstellen, eine cloud-init-Konfiguration über customdata übergeben. Verwenden Sie diese Methode.

      Fügen Sie dem Image alternativ eine cloud-init-Direktive hinzu, sodass jedes Mal, wenn eine VM erstellt wird, Auslagerungsspeicher konfiguriert wird. Um diese Methode zu verwenden, erstellen Sie eine CFG-Datei:

      echo 'DefaultEnvironment="CLOUD_CFG=/etc/cloud/cloud.cfg.d/00-azure-swap.cfg"' | sudo tee -a /etc/systemd/system.conf
      cat << EOF | sudo tee /etc/cloud/cloud.cfg.d/00-azure-swap.cfg
      #cloud-config
      # Generated by Azure cloud image build
      disk_setup:
        ephemeral0:
          table_type: mbr
          layout: [66, [33, 82]]
          overwrite: True
      fs_setup:
        - device: ephemeral0.1
          filesystem: ext4
        - device: ephemeral0.2
          filesystem: swap
      mounts:
        - ["ephemeral0.1", "/mnt/resource"]
        - ["ephemeral0.2", "none", "swap", "sw,nofail,x-systemd.requires=cloud-init.service,x-systemd.device-timeout=2", "0", "0"]
      EOF
      

8. Konfigurieren Sie cloud-init für die Bereitstellung:

   1. waagent für cloud-init konfigurieren:

      sudo sed -i 's/Provisioning.Agent=auto/Provisioning.Agent=cloud-init/g' /etc/waagent.conf
      sudo sed -i 's/ResourceDisk.Format=y/ResourceDisk.Format=n/g' /etc/waagent.conf
      sudo sed -i 's/ResourceDisk.EnableSwap=y/ResourceDisk.EnableSwap=n/g' /etc/waagent.conf
      

      Wenn Sie eine bestimmte virtuelle Maschine migrieren und kein generalisiertes Image erstellen möchten, legen Sie Provisioning.Agent=disabled in der Konfiguration /etc/waagent.conf fest.

   2. Konfigurieren der Einbindungen:

      echo "Adding mounts and disk_setup to init stage"
      sudo sed -i '/ - mounts/d' /etc/cloud/cloud.cfg
      sudo sed -i '/ - disk_setup/d' /etc/cloud/cloud.cfg
      sudo sed -i '/cloud_init_modules/a\\ - mounts' /etc/cloud/cloud.cfg
      sudo sed -i '/cloud_init_modules/a\\ - disk_setup' /etc/cloud/cloud.cfg
      
      

   3. Konfigurieren Sie die Azure-Datenquelle:

      echo "Allow only Azure datasource, disable fetching network setting via IMDS"
      cat << EOF | sudo tee /etc/cloud/cloud.cfg.d/91-azure_datasource.cfg
      datasource_list: [ Azure ]
      datasource:
         Azure:
           apply_network_config: False
      EOF
      

   4. Entfernen Sie die vorhandene Auslagerungsdatei, wenn Sie eine konfiguriert haben:

      if [[ -f /mnt/resource/swapfile ]]; then
      echo "Removing swapfile" #RHEL uses a swap file by default
      swapoff /mnt/resource/swapfile
      rm /mnt/resource/swapfile -f
      fi
      

   5. Konfigurieren der Cloud-Init-Protokollierung:

      echo "Add console log file"
      cat << EOF | sudo tee -a /etc/cloud/cloud.cfg.d/05_logging.cfg
      
      # This tells cloud-init to redirect its stdout and stderr to
      # 'tee -a /var/log/cloud-init-output.log' so the user can see output
      # there without needing to look on the console.
      output: {all: '| tee -a /var/log/cloud-init-output.log'}
      EOF
      

9. Überprüfen Sie die Bereitstellungskonfiguration des Datenträgers, bevor Sie die Bereitstellung des virtuellen Computers aufheben. Diese Überprüfung gilt sowohl für SCSI- als auch für Remote-NVMe-Images.

   1. Überprüfen Sie /etc/fstab. Verwenden Sie keine Gerätenamen wie /dev/sd* oder /dev/nvme*, da sich Gerätenamen nach einem Neustart oder beim Wechsel des Datenträgercontrollers ändern können. Verwenden Sie stattdessen UUIDs des Dateisystems oder andere persistente IDs.

      Listen Sie die Blockgeräte und ihre persistenten IDs auf, damit Sie sie mit den Einträgen vergleichen können in /etc/fstab:

      sudo blkid
      

   2. Überprüfen Sie /etc/fstab auf Syntaxfehler, ungültige Mount-Optionen und Verweise, die nicht aufgelöst werden können:

      sudo findmnt --verify --verbose
      

   3. Nur wenn Sie ein Image für einen NVMe-Controller für entfernte Datenträger erstellen, überprüfen Sie das konfigurierte E/A-Timeout. Wenn der virtuelle Quellcomputer derzeit NVMe verwendet, führen Sie Folgendes aus:

      cat /sys/module/nvme_core/parameters/io_timeout
      

      Der Wert muss 240 sein. Eine SCSI-Quell-VM macht diesen Laufzeitparameter möglicherweise nicht verfügbar; stellen Sie in diesem Fall sicher, dass nvme_core.io_timeout=240 sie in der GRUB-Konfiguration vorhanden ist und dass die neu erstellte Konfiguration sie enthält.

10. Führen Sie die folgenden Befehle aus, um die Bereitstellung des virtuellen Computers zu aufheben.

    Vorsicht

    Wenn Sie eine bestimmte virtuelle Maschine migrieren und kein generalisiertes Image erstellen möchten, überspringen Sie den Schritt zur Aufhebung der Bereitstellung. Wenn Sie den Befehl waagent -force -deprovision+user ausführen, wird der Quellcomputer nicht verwendbar gerendert. Dieser Schritt soll nur ein generalisiertes Image erstellen.

    sudo rm -f /var/log/waagent.log
    sudo cloud-init clean
    sudo waagent -force -deprovision+user
    sudo rm -f ~/.bash_history
    sudo export HISTSIZE=0
    

    In VirtualBox wird nach dem Ausführen von waagent -force -deprovision möglicherweise eine Fehlermeldung mit folgendem Inhalt angezeigt: [Errno 5] Input/output error. Diese Fehlermeldung ist nicht kritisch, und Sie können sie ignorieren.

11. Beenden Sie den virtuellen Computer, und laden Sie die VHD in Azure hoch.

Nächste Schritte

Erstellen einer Linux-VM von einem benutzerdefinierten Datenträger mithilfe der Azure CLI

Für eine vorhandene Azure-VM, die Sie von SCSI zu NVMe migrieren müssen, verwenden Sie Linux- und Windows-VMs von SCSI zu NVMe konvertieren. Informationen zu Architektur und Support finden Sie in der NVMe-Übersicht.