Vorbereiten eines virtuellen SLES- oder openSUSE Leap-Computers für Azure
Gilt für: ✔️ Linux-VMs ✔️ Flexible Skalierungsgruppen Gilt für: ✔️ Einheitliche Skalierungsgruppen
In einigen Fällen möchten Sie möglicherweise angepasste SUSE Linux Enterprise Server (SLES) oder openSUSE Leap Linux Virtual Machines (VMs) in Ihrer Azure-Umgebung verwenden und diese Arten von virtuellen Computern über Automatisierung erstellen können. In diesem Artikel erfahren Sie, wie Sie eine benutzerdefinierte virtuelle Azure-Festplatte (Virtual Hard Disk, VHD) erstellen und hochladen, die ein SUSE-Linux-Betriebssystem enthält.
Voraussetzungen
In diesem Artikel wird davon ausgegangen, dass Sie bereits ein SUSE- oder openSUSE Leap-Linux-Betriebssystem auf einer virtuellen Festplatte installiert haben. Zum Erstellen von VHD-Dateien stehen mehrere verschiedene Tools bereit. Sie können beispielsweise eine Virtualisierungslösung wie Hyper-V verwenden. Anweisungen hierzu finden Sie unter Installieren von Hyper-V und Erstellen eines virtuellen Computers.
Installationshinweise zu SLES/openSUSE Leap
- Weitere Tipps zur Vorbereitung von Linux-Images für Azure finden Sie unter Allgemeine Installationshinweise für Linux.
- Azure unterstützt keine Windows-Festplattenimagedateien (VHDX-Dateien). Nur VHD (.vhd)-Dateien werden außerhalb virtueller Computer unterstützt. Sie können den Datenträger mit dem Hyper-V-Manager oder dem
Convert-VHD
-Cmdlet in das VHD-Format konvertieren. - Azure unterstützt virtuelle Computer der Gen1 (BIOS-Start) und Gen2 (UEFI-Start).
- Das Kernelmodul für die virtuelle Dateizuordnungstabelle (VFAT) muss im Kernel aktiviert sein.
- Konfigurieren Sie keine Auslagerungspartition auf dem Betriebssystemdatenträger. Sie können den Linux-Agent zur Erstellung einer Auslagerungsdatei auf dem temporären Ressourcendatenträger konfigurieren. Weitere Informationen zum Konfigurieren eines Auslagerungsbereichs finden Sie in den Schritten später in diesem Artikel.
- Alle VHDs in Azure benötigen eine virtuelle Größe, die auf 1 MB ausgerichtet ist. Stellen Sie beim Konvertieren von einem RAW-Datenträger in VHD sicher, dass die Größe des RAW-Datenträgers vor der Konvertierung ein Vielfaches von 1 MB beträgt. Weitere Informationen finden Sie in den Allgemeinen Linux-Installationshinweisen.
Hinweis
Cloud-init-Version 21.2 oder höher entfernt die Anforderung der benutzerdefinierten Funktion (UDF). Aber ohne das aktivierte udf
-Modul wird die CD-ROM während der Bereitstellung nicht eingebunden, was verhindert, dass die benutzerdefinierten Daten angewendet werden. Eine Problemumgehung besteht darin, Benutzerdaten anzuwenden. Im Gegensatz zu benutzerdefinierten Daten werden Benutzerdaten jedoch nicht verschlüsselt. Weitere Informationen finden Sie unter Benutzerdatenformate in der cloud-init-Dokumentation.
Verwenden von SUSE Studio
SUSE Studio können Sie Ihre SLES- und openSUSE Leap-Images für Azure und Hyper-V auf einfache Weise erstellen und verwalten. SUSE Studio wird zum Anpassen Ihrer eigenen SLES- und openSUSE Leap-Images empfohlen.
Als Alternative zum Erstellen einer eigenen VHD veröffentlicht SUSE auf VM Depot auch BYOS-Images (Bring Your Own Subscription) für SLES.
Vorbereiten von SLES für Azure
Konfigurieren Sie die Azure- und Hyper-V-Module bei Bedarf.
Wenn Ihr Software-Hypervisor nicht Hyper-V ist, müssen andere Module zum erfolgreichen Starten in Azure zum ersten RAM-Datenträger (initramfs) hinzugefügt werden.
Bearbeiten Sie die Datei /etc/dracut.conf und fügen Sie der Datei die folgende Zeile hinzu:
add_drivers+=" hv_vmbus hv_netvsc hv_storvsc "
Führen Sie den
dracut
-Befehl aus, um die initramfs-Datei neu zu erstellen:sudo dracut --verbose --force
Richten Sie die serielle Konsole ein.
Um erfolgreich mit der seriellen Konsole zu arbeiten, müssen Sie mehrere Variablen in der Datei /etc/defaults/grub einrichten und GRUB auf dem Server erneut erstellen:
# Add console=ttyS0 and earlyprintk=ttS0 to the variable. # Remove "splash=silent" and "quiet" options. GRUB_CMDLINE_LINUX_DEFAULT="audit=1 no-scroll fbcon=scrollback:0 mitigations=auto security=apparmor crashkernel=228M,high crashkernel=72M,low console=ttyS0 earlyprintk=ttyS0" # Add "console serial" to GRUB_TERMINAL. GRUB_TERMINAL="console serial" # Set the GRUB_SERIAL_COMMAND variable. GRUB_SERIAL_COMMAND="serial --speed=115200 --unit=0 --word=8 --parity=no --stop=1"
/usr/sbin/grub2-mkconfig -o /boot/grub2/grub.cfg
Registrieren Sie Ihr SUSE Linux Enterprise-System, um das Herunterladen von Updates und das Installieren von Paketen zu ermöglichen.
Aktualisieren Sie das System mit den neuesten Patches:
sudo zypper update
Installieren Sie den Azure Linux-VM-Agent (
waagent
) und den cloud-init:sudo SUSEConnect -p sle-module-public-cloud/15.2/x86_64 (SLES 15 SP2) sudo zypper refresh sudo zypper install python-azure-agent sudo zypper install cloud-init
Aktivieren Sie
waagent
und cloud-init, um beim Systemstart ausgeführt zu werden:sudo systemctl enable waagent sudo systemctl enable cloud-init-local.service sudo systemctl enable cloud-init.service sudo systemctl enable cloud-config.service sudo systemctl enable cloud-final.service sudo systemctl daemon-reload sudo cloud-init clean
Aktualisieren sie die cloud-init-Konfiguration:
cat <<EOF | sudo tee /etc/cloud/cloud.cfg.d/91-azure_datasource.cfg datasource_list: [ Azure ] datasource: Azure: apply_network_config: False EOF
sudo cat <<EOF | sudo tee /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 # Make sure mounts and disk_setup are in the init stage: 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
Wenn Sie eine Swap-Partition bereitstellen, formatieren und erstellen möchten, besteht eine Option darin, bei jedem Erstellen einer VM eine cloud-init-Konfiguration zu übergeben.
Eine weitere Option besteht darin, eine cloud-init-Direktive im Image zu verwenden, um jedes Mal einen Auslagerungsbereich zu konfigurieren, wenn die VM erstellt wird:
cat <<EOF | sudo tee -a /etc/systemd/system.conf 'DefaultEnvironment="CLOUD_CFG=/etc/cloud/cloud.cfg.d/00-azure-swap.cfg"' EOF 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"] - ["ephemeral0.2", "none", "swap", "sw,nofail,x-systemd.requires=cloud-init.service,x-systemd.device-timeout=2", "0", "0"] EOF
Früher wurde der Azure Linux-Agent zum automatischen Konfigurieren des Auslagerungsbereichs mit dem lokalen Ressourcendatenträger verwendet, der nach der Bereitstellung der VM in Azure an die VM angefügt ist. Weil dieser Schritt jetzt von cloud-init verarbeitet wird, darf der Azure Linux-Agent nicht zum Formatieren des Ressourcendatenträgers oder Erstellen der Auslagerungsdatei verwendet werden. Verwenden Sie diese Befehle, um /etc/waagent.conf entsprechend zu ändern:
sudo sed -i 's/Provisioning.UseCloudInit=n/Provisioning.UseCloudInit=auto/g' /etc/waagent.conf sudo sed -i 's/Provisioning.Enabled=y/Provisioning.Enabled=n/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
Hinweis
Wenn Sie eine cloud-init-Version vor 21.2 verwenden, stellen Sie sicher, dass das
udf
-Modul aktiviert ist. Durch das Entfernen oder Deaktivieren wird ein Bereitstellungs- oder Startfehler verursacht. Cloud-init-Version 21.2 oder höher entfernt die UDF-Anforderung.Stellen Sie sicher, dass von der Datei /etc/fstab per UUID (
by-uuid
) auf den Datenträger verwiesen wird.Entfernen Sie udev-Regeln und Netzwerkadapterkonfigurationsdateien, um eine Generierung statischer Regeln für die Ethernet-Schnittstellen zu vermeiden. Diese Regeln können beim Klonen eines virtuellen Computers unter Microsoft Azure oder Hyper-V zu Problemen führen.
sudo rm -f /etc/udev/rules.d/70-persistent-net.rules sudo rm -f /etc/udev/rules.d/85-persistent-net-cloud-init.rules sudo rm -f /etc/sysconfig/network/ifcfg-eth*
Es wird empfohlen, die Datei /etc/sysconfig/network/dhcp zu bearbeiten und den
DHCLIENT_SET_HOSTNAME
-Parameter wie folgt zu ändern:DHCLIENT_SET_HOSTNAME="no"
Kommentieren Sie in /etc/sudoers die folgenden Zeilen aus, sofern sie vorhanden sind, oder entfernen Sie sie:
Defaults targetpw # Ask for the password of the target user i.e. root ALL ALL=(ALL) ALL # WARNING! Only use this setting together with 'Defaults targetpw'!
Stellen Sie sicher, dass der Secure Shell (SSH)-Server installiert und so konfiguriert ist, dass er beim Booten hochfährt:
sudo systemctl enable sshd
Bereinigen Sie die cloud-init-Phase:
sudo cloud-init clean --seed --logs
Führen Sie die folgenden Befehle aus, um die Bereitstellung des virtuellen Computers aufzuheben und ihn für die Bereitstellung in Azure vorzubereiten.
Wenn Sie eine bestimmte VM migrieren und kein generalisiertes Image erstellen möchten, überspringen Sie den Schritt zum Aufheben der Bereitstellung.
sudo rm -f /var/log/waagent.log sudo waagent -force -deprovision+user sudo export HISTSIZE=0 sudo rm -f ~/.bash_history
Vorbereiten von openSUSE 15.4+
Wählen Sie den virtuellen Computer im mittleren Fensterbereich des Hyper-V-Managers.
Klicken Sie auf Verbinden, um das Fenster für den virtuellen Computer zu öffnen.
Führen Sie im Terminal den Befehl
zypper lr
aus. Wenn dieser Befehl die Ausgabe ähnlich wie im folgenden Beispiel zurückgibt, sind die Repositorys wie erwartet konfiguriert, und es sind keine Anpassungen erforderlich. (Versionsnummern können variieren.)# Alias Name Aktiviert GPG-Überprüfung Refresh 1 Cloud:Tools_15.4 Cloud:Tools-> Ja (r ) Ja Ja 2 openSUSE_stable_OSS openSUSE_st-> Ja (r ) Ja Ja 3 openSUSE_stable_Updates openSUSE_st-> Ja (r ) Ja Ja Wenn der Befehl
zypper lr
die Meldung „Keine Repositorys definiert“ zurückgibt, müssen die Repositorys manuell hinzugefügt werden.Nachfolgend finden Sie Beispiele für Befehle zum Hinzufügen dieser Repositorys (Versionen und Links können variieren):
sudo zypper ar -f https://download.opensuse.org/update/openSUSE-stable openSUSE_stable_Updates sudo zypper ar -f https://download.opensuse.org/repositories/Cloud:/Tools/15.4 Cloud:Tools_15.4 sudo zypper ar -f https://download.opensuse.org/distribution/openSUSE-stable/repo/oss openSUSE_stable_OSS
Sie können dann überprüfen, ob die Repositorys hinzugefügt wurden, indem Sie den Befehl
zypper lr
erneut ausführen. Falls eins der relevanten Updaterepositorys nicht aktiviert ist, können Sie es mit dem folgenden Befehl aktivieren:sudo zypper mr -e [NUMBER OF REPOSITORY]
Aktualisieren Sie den Kernel auf die neueste verfügbare Version:
sudo zypper up kernel-default
Oder aktualisieren Sie das Betriebssystem mit allen neuen Patches:
sudo zypper update
Installieren des Azure Linux Agent:
sudo zypper install WALinuxAgent
Ändern Sie die Bootzeile des Kernels in Ihrer GRUB-Konfiguration, um weitere Kernel-Parameter für Azure einzubinden. Öffnen Sie dafür /boot/grub/menu.lst in einem Text-Editor. Stellen Sie sicher, dass der Standardkernel die folgenden Parameter enthält:
console=ttyS0 earlyprintk=ttyS0
Mit dieser Option wird sichergestellt, dass alle Konsolennachrichten an den ersten seriellen Port gesendet werden. Dies kann Azure bei der Behebung von Fehlern unterstützen. Entfernen Sie außerdem die folgenden Parameter aus der Kernel-Boot-Zeile, sofern diese vorhanden sind:
libata.atapi_enabled=0 reserve=0x1f0,0x8
Es wird empfohlen, die Datei /etc/sysconfig/network/dhcp zu bearbeiten und den
DHCLIENT_SET_HOSTNAME
-Parameter in folgende Einstellung zu ändern:DHCLIENT_SET_HOSTNAME="no"
Kommentieren Sie in /etc/sudoers die folgenden Zeilen aus, sofern sie vorhanden sind, oder entfernen Sie sie. Dies ist ein wichtiger Schritt.
Defaults targetpw # ask for the password of the target user i.e. root ALL ALL=(ALL) ALL # WARNING! Only use this together with 'Defaults targetpw'!
Stellen Sie sicher, dass der SSH-Server installiert und konfiguriert ist, damit er beim Booten hochfährt.
Erstellen Sie keinen Auslagerungsbereich auf dem Betriebssystemdatenträger.
Der Azure Linux Agent kann SWAP-Raum automatisch mit dem lokalen Ressourcendatenträger konfigurieren, der nach der Bereitstellung in Azure mit dem virtuellen Computer verknüpft ist. Der lokale Ressourcendatenträger ist ein temporärer Datenträger und wird geleert werden, wenn die Bereitstellung des virtuellen Computers aufgehoben wird.
Ändern Sie nach der Installation des Azure Linux-Agents die Parameter in /etc/waagent.conf wie folgt:
ResourceDisk.Format=n ResourceDisk.Filesystem=ext4 ResourceDisk.MountPoint=/mnt/resource ResourceDisk.EnableSwap=n ResourceDisk.SwapSizeMB=2048 ## NOTE: set the size to whatever you need it to be.
Stellen Sie sicher, dass der Azure Linux Agent beim Start ausgeführt wird:
sudo systemctl enable waagent.service
Führen Sie die folgenden Befehle aus, um die Bereitstellung des virtuellen Computers aufzuheben und ihn für die Bereitstellung in Azure vorzubereiten.
Wenn Sie eine bestimmte VM migrieren und kein generalisiertes Image erstellen möchten, überspringen Sie den Schritt zum Aufheben der Bereitstellung.
sudo rm -f ~/.bash_history # Remove current user history sudo rm -rf /var/lib/waagent/ sudo rm -f /var/log/waagent.log sudo waagent -force -deprovision+user sudo rm -f ~/.bash_history # Remove root user history sudo export HISTSIZE=0
Wählen Sie im Hyper-V-Manager Aktion>Herunterfahren aus.
Nächste Schritte
Nun können Sie mit Ihrer SUSE-Linux-VHD-Datei neue virtuelle Computer in Azure erstellen. Wenn Sie zum ersten Mal die VHD-Datei in Azure hochladen, lesen Sie den Artikel Erstellen eines virtuellen Linux-Computers aus einem benutzerdefinierten Datenträger mithilfe der Azure CLI 2.0.