Préparer Linux pour l'imagerie dans Azure

Attention

Cet article fait référence à CentOS, une distribution Linux ayant atteint l’état EOL (fin du service). Faites le point sur votre utilisation et organisez-vous en conséquence. Pour plus d’informations, consultez les conseils d’aide relatifs à la fin de vie de CentOS.

S’applique à : ✔️ Machines virtuelles Linux ✔️ Groupes identiques flexibles

Le contrat de niveau de service (SLA) de la plateforme Azure s'applique aux machines virtuelles (MV) exécutant le système d'exploitation Linux uniquement lorsque vous utilisez l'une des distributions approuvées. Pour les distributions approuvées, la Place de marché Azure fournit des images Linux préconfigurées. Pour en savoir plus, consultez :

• Distributions Linux approuvées sur Azure
• Prise en charge des technologies Linux et open source dans Azure

Toutes les autres distributions fonctionnant sur Azure, notamment les distributions prises en charge par la communauté et les distributions non approuvées, sont soumises à des conditions préalables.

Cet article fournit des conseils généraux pour exécuter votre distribution Linux sur Azure. Cet article ne peut pas être exhaustif, car chaque distribution est différente. Même si vous répondez à tous les critères décrits dans cet article, il se peut que vous deviez apporter des modifications importantes à votre système Linux pour qu'il fonctionne bien.

Notes générales relatives à l'installation de Linux

• Azure ne prend pas en charge le format de disque dur virtuel Hyper-V (VHDX). Azure prend uniquement en charge les VHD fixes. Vous pouvez convertir le disque au format VHD en utilisant Hyper-V Manager ou la cmdlet Convert-VHD. Si vous utilisez VirtualBox, sélectionnez Taille fixe plutôt que la valeur par défaut (allouée dynamiquement) lorsque vous créez le disque.

• Azure prend en charge les machines virtuelles Gen1 (BIOS Boot) et Gen2 (amorçage UEFI).

• Le module de noyau de la table d'allocation de fichiers virtuels (VFAT) doit être activé dans le noyau.

• La taille maximale autorisée pour le disque dur virtuel s’élève à 1 023 Go.

• Lorsque vous installez le système Linux, nous vous recommandons d'utiliser des partitions standard plutôt que le gestionnaire de volumes logiques (LVM). LVM est la valeur par défaut pour plusieurs installations.

  L’utilisation des partitions standard permet d’éviter les conflits de noms avec des machines virtuelles clonées, notamment si un disque de système d’exploitation est attaché à une autre machine virtuelle identique à des fins de dépannage. Vous pouvez utiliser LVM ou RAID sur les disques de données.

• La prise en charge par le noyau du montage des systèmes de fichiers à fonction définis par l'utilisateur (UDF) est requise. Lors du premier démarrage sur Azure, la configuration d'approvisionnement est transmise à la machine virtuelle Linux par des médias formatés UDF joints à l'invité. L’agent Linux Azure doit monter le système de fichiers UDF pour lire sa configuration et approvisionner la machine virtuelle.

• Les versions du noyau Linux antérieures à la version 2.6.37 ne prennent pas en charge l'accès à la mémoire non uniforme (NUMA) sur Hyper-V avec des tailles de machines virtuelles plus grandes. Ce problème concerne principalement les anciennes distributions qui utilisent le noyau Red Hat 2.6.32 en amont. Il a été corrigé dans Red Hat Enterprise Linux (RHEL) 6.6 (noyau-2.6.32-504).

  Pour les systèmes exécutant des noyaux personnalisés dont la version est antérieure à la version 2.6.37 ou des noyaux basés sur RHEL dont la version est antérieure à la version 2.6.32-504, le paramètre de démarrage numa=off doit être défini sur la ligne de commande du noyau dans grub.conf. Pour plus d’informations, consultez l’article KB 436883 sur Red Hat.

• Ne configurez pas une partition d’échange sur le disque du système d’exploitation. Vous pouvez configurer l'agent Linux pour créer un fichier d'échange sur le disque de ressources temporaire, comme décrit plus loin dans cet article.

• Tous les VHD sur Azure doivent avoir une taille virtuelle alignée sur 1 Mo (1 024 x 1 024 octets). Lorsque vous effectuez une conversion d'un disque brut en disque dur virtuel, vérifiez que la taille du disque brut est un multiple de 1 Mo avant la conversion, comme décrit plus loin dans cet article.

• Utilisez la version de distribution, les packages et les logiciels les plus à jour.

• Supprimez les comptes utilisateurs et système, les clés publiques, les données sensibles, les logiciels et les applications inutiles.

Remarque

Cloud-init version 21.2 ou ultérieure supprime l'exigence UDF. Toutefois, si le module udf n'est pas activé, le CD-ROM ne sera pas monté pendant l'approvisionnement, ce qui empêche l'application des données personnalisées. Une solution consiste à appliquer les données utilisateur. Toutefois, contrairement aux données personnalisées, les données utilisateur ne sont pas chiffrées. Pour en savoir plus, reportez-vous à Formats des données utilisateur dans la documentation de cloud-init.

Installer les modules du noyau sans Hyper-V

Azure s’exécute sur l’hyperviseur Hyper-V. Linux nécessite donc l’exécution de certains modules de noyau dans Azure. Si vous possédez une machine virtuelle qui a été créée en dehors d'Hyper-V, les programmes d'installation Linux peuvent ne pas inclure les pilotes pour Hyper-V dans le disque RAM initial (initrd ou initramfs), à moins que la machine virtuelle ne détecte qu'elle s'exécute dans un environnement Hyper-V.

Lorsque vous utilisez un système de virtualisation différent (comme VirtualBox ou KVM) pour préparer votre image Linux, vous devrez peut-être régénérer initrd pour qu'au moins les modules de noyau hv_vmbus et hv_storvsc soient disponibles sur le disque RAM initial. Ce problème connu concerne les systèmes basés sur la distribution Red Hat en amont, et peut-être d’autres systèmes.

Le mécanisme de régénération de l'image initrd ou initramfs peut varier en fonction de la distribution. Consultez la documentation ou le support de votre distribution pour trouver la procédure appropriée. L'exemple suivant illustre la régénération d'initrd à l'aide de l'utilitaire mkinitrd :

1. Sauvegardez l’image initrd existante :

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

2. régénérer initrd en utilisant les modules de noyau hv_vmbus et hv_storvsc :

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

Redimensionner des VHD

Les images de disque dur virtuel sur Azure doivent avoir une taille virtuelle alignée à 1 Mo. En règle générale, les VHD créés par Hyper-V sont bien alignés. Si le VHD n'est pas bien aligné, vous pouvez recevoir un message d'erreur similaire à l'exemple suivant lorsque vous essayez de créer une image à partir de votre VHD :

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).

Dans ce cas, redimensionnez la machine virtuelle à l'aide de la console Hyper-V Manager ou de la cmdlet PowerShell Redimensionner-VHD PowerShell cmdlet. Si vous n’utilisez pas un environnement Windows, nous vous recommandons d’utiliser qemu-img pour convertir (si nécessaire) le disque dur virtuel et le redimensionner.

Remarque

Il existe un bogue connu dans qemu-img pour QEMU version 2.2.1 et certaines versions ultérieures qui cause un formatage incorrect du VHD. Le problème a été résolu dans QEMU 2.6. Nous recommandons d'utiliser la version 2.2.0 ou une version antérieure, ou d'utiliser la version 2.6 ou une version ultérieure.

1. Le redimensionnement du VHD directement à l'aide d'outils comme qemu-img ou vbox-manage peut entraîner un VHD non démarrable. Il est recommandé de convertir au préalable le VHD en une image disque brute en utilisant le code suivant.

   Si l'image de machine virtuelle a été créée comme image de disque brute, vous pouvez ignorer cette étape. La création de l'image de machine virtuelle comme image de disque brute est la valeur par défaut dans certains hyperviseurs, comme KVM.

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

2. Calculez la taille nécessaire de l’image de disque afin que la taille virtuelle soit alignée sur 1 Mo. Le script d'interpréteur de commandes Bash suivant utilise qemu-img info pour déterminer la taille virtuelle de l'image disque, puis calcule la taille au 1 Mo suivant :

   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. redimensionnez le disque brut en utilisant $rounded_size :

   sudo qemu-img resize MyLinuxVM.raw $rounded_size
   

4. reconvertissez le disque brut en un VHD de taille fixe :

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

   vous pouvez également, avec les versions de QEMU antérieures à 2.6, supprimez l'option force_size :

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

exigences relatives au noyau Linux

Les pilotes LIS (Linux Integration Services) pour Hyper-V et Azure sont directement liés au noyau Linux en amont. Ces pilotes sont déjà disponibles dans de nombreuses distributions qui incluent une version récente du noyau Linux (3.x par exemple). Sinon, ces distributions fournissent des versions rétroportées de ces pilotes avec leurs noyaux.

Les pilotes LIS sont régulièrement mis à jour dans le noyau en amont avec de nouveaux correctifs et de nouvelles caractéristiques. Nous recommandons, dans la mesure du possible, d'exécuter une distribution approuvée qui inclut ces correctifs et mises à jour.

Si vous exécutez une variante des versions 6.0 à 6.3 de RHEL, vous devez installer les pilotes LIS les plus récents pour Hyper-V. À partir de RHEL 6.4+ (et dérivés), les pilotes LIS sont déjà inclus dans le noyau, de sorte que vous n'avez pas besoin de packages d'installation supplémentaires.

Si un noyau personnalisé est requis, nous vous recommandons d’utiliser une version plus récente du noyau (par exemple 3.8+). Pour les distributions ou les fournisseurs qui maintiennent leur propre noyau, vous devez régulièrement rétroporter les pilotes LIS du noyau en amont vers votre noyau personnalisé.

Même si vous exécutez déjà une version relativement récente du noyau, nous vous recommandons vivement de suivre les correctifs apportés en amont aux pilotes LIS et de les rétroporter le cas échéant. Les emplacements des fichiers sources des pilotes LIS sont spécifiés dans le fichier MAINTAINERS dans l’arborescence source du noyau Linux :

    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/

Le noyau actif de la machine virtuelle doit inclure les patchs suivants. Cette liste ne peut pas être complète pour toutes les distributions.

• ata_piix : reporter des disques dans les pilotes Hyper-V par défaut
• storvsc : prendre en compte les paquets en transit dans le chemin RESET
• storvsc : éviter l’utilisation de WRITE_SAME
• storvsc : désactiver WRITE_SAME pour RAID et les pilotes adaptateurs de l’hôte virtuel
• storvsc : correctif de déréférencement de pointeur NULL
• storvsc : des défaillances de la mémoire tampon de l’anneau peuvent entraîner un gel des E/S
• scsi_sysfs : se protéger contre une double exécution de __scsi_remove_device

Agent Linux Azure

L'agent Azure Linux (waagent) approvisionne une machine virtuelle Linux dans Azure. Vous pouvez obtenir la dernière version, signaler des problèmes ou soumettre des requêtes de tirage sur le référentiel de l'agent Linux à partir de GitHub.

Vous trouverez ci-dessous quelques considérations relatives à l'utilisation de l'agent Linux Azure :

• L'agent Linux est publié avec la licence Apache 2.0. plusieurs distributions fournissent déjà des packages .rpm ou .deb pour l'agent. Vous pouvez facilement installer et mettre à jour ces packages.
• L'agent Linux Azure nécessite Python v2.6+.
• L'agent requiert également le module python-pyasn1. La plupart des distributions fournissent ce module sous la forme d’un package distinct à installer.
• Dans certains cas, l'agent Linux Azure peut ne pas être compatible avec NetworkManager. Plusieurs packages (.rpm ou .deb) fournis par les distributions configurent NetworkManager en conflit avec le package waagent. Dans ces cas, l'agent désinstallera NetworkManager lorsque vous installerez le package de l'agent Linux.
• La version de l’agent Linux Azure doit être supérieure ou égale à la version minimale prise en charge.

Remarque

Assurez-vous que les modules udf et vfat sont activés. La désactivation du module udf entraînera une défaillance de l'approvisionnement. La désactivation du module vfat entraînera des défaillances de l'approvisionnement et du démarrage. Cloud-init version 21.2 ou une version ultérieure peut approvisionner les machines virtuelles sans nécessiter la fonction UDF si les deux conditions suivantes sont réunies :

• vous avez créé la machine virtuelle en utilisant des clés publiques SSH et non des mots de passe.
• Vous n'avez pas fourni de données personnalisées.

Configuration générale requise pour le système Linux

1. Modifiez la ligne de démarrage du noyau dans GRUB ou GRUB2 afin d’inclure les paramètres suivants pour que tous les messages de la console soient envoyés au premier port série. Ces messages peuvent aider l’équipe du support Azure à procéder au débogage.

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

   Nous recommandons également de supprimer les paramètres suivants s'ils existent :

   rhgb quiet crashkernel=auto
   

   Le démarrage graphique et silencieux n'est pas utile dans un environnement cloud, dans lequel vous souhaitez que tous les journaux soient envoyés au port série. Vous pouvez laisser l'option crashkernel configurée au besoin. Toutefois, ce paramètre réduit la quantité de mémoire disponible dans la machine virtuelle d'au moins 128 Mo. La réduction de la mémoire disponible peut poser problème pour les tailles de machine virtuelle plus petites.

2. Après avoir modifié /etc/default/grub, exécutez la commande suivante pour régénérer la configuration GRUB :

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

3. ajoutez le module Hyper-V pour initramfs en utilisant dracut :

   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"
   sudo grub-mkconfig -o /boot/grub/grub.cfg
   sudo grub2-mkconfig -o /boot/grub2/grub.cfg
   

   ajoutez le module Hyper-V pour initrd en utilisant mkinitramfs :

   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
   sudo update-grub
   

4. Vérifiez que le serveur SSH est installé et configuré pour démarrer au moment prévu. Cette configuration est généralement définie par défaut.

5. Installez l'agent Linux Azure.

   L'agent Linux Azure est requis pour approvisionner une image Linux sur Azure. de nombreuses distributions approvisionnent l'agent sous la forme d'un package .rpm ou .deb. Le package est généralement appelé WALinuxAgent ou walinuxagent. Vous pouvez également installer l'agent manuellement en suivant les étapes du guide de l'agent Linux Azure.

   Remarque

   Assurez-vous que les modules udf et vfat sont activés. La suppression ou la désactivation de ces modules entraînera une défaillance de l'approvisionnement ou du démarrage. Cloud-init version 21.2 ou ultérieure supprime l'exigence UDF.

   Installez l'agent Linux Azure, cloud-init, ainsi que les autres utilitaires requis en exécutant l'une des commandes suivantes.

   Utilisez cette commande pour Red Hat ou CentOS :

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

   utilisez cette commande pour Ubuntu/Debian :

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

   utilisez cette commande pour SUSE :

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

   activez ensuite l'agent et cloud-init sur toutes les distributions :

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

6. Ne créez pas d’espace d’échange sur le disque du système d’exploitation.

   vous pouvez utiliser l'agent Linux Azure ou cloud-init pour configurer l'espace d'échange par le biais du disque de ressources local. Ce disque de ressources est attaché à la machine virtuelle après l’approvisionnement sur Azure. Le disque de ressources local est un disque temporaire, et il peut être vidé lorsque la machine virtuelle est déprovisionnée. Les blocs suivants montrent comment configurer cet échange.

   Si vous choisissez l'agent Linux Azure, modifiez les paramètres suivants dans /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.
   

   si vous choisissez cloud-init, configurez cloud-init pour gérer l'approvisionnement :

   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
   

   pour configurer cloud-init afin qu'il formate et crée l'espace d'échange, vous avez deux options :

   • transmettez une configuration cloud-init à chaque fois que vous créez une machine virtuelle par l'intermédiaire de customdata. Nous recommandons cette méthode.
   • Utilisez une directive cloud-init dans l'image pour configurer l'espace d'échange à chaque fois que la machine virtuelle est créée.

   Créez un fichier .cfg pour configurer l'espace d'échange en utilisant cloud-init :

   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
   

7. Configurez cloud-init pour gérer le provisionnement :

   1. configurez waagent pour cloud-init :

      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
      

      Si vous migrez une machine virtuelle spécifique et ne souhaitez pas créer une image généralisée, définissez Provisioning.Agent=disabled dans la configuration /etc/waagent.conf.

   2. Configurez les montages :

      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. Configurez la source de données Azure :

      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. supprimez le fichier d'échange existant si vous en avez configuré un :

      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. Configurez la journalisation cloud-init :

      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
      

8. Exécutez les commandes suivantes pour déprovisionner la machine virtuelle.

   Attention

   si vous migrez une machine virtuelle spécifique et ne souhaitez pas créer une image généralisée, ignorez l'étape de déprovisionnement. L'exécution de la commande waagent -force -deprovision+user rendra la machine source inutilisable. Cette étape est destinée uniquement à créer une image généralisée.

   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
   

   Sur VirtualBox, un message d'erreur s'affiche après exécution de waagent -force -deprovision qui dit [Errno 5] Input/output error. Ce message d'erreur n'est pas critique et vous pouvez l'ignorer.

9. Arrêtez la machine virtuelle et chargez le disque dur virtuel sur Azure.

Étapes suivantes

Créer une machine virtuelle Linux à partir d'un disque personnalisé à l'aide de l'interface de ligne de commande Azure