Préparer Linux pour l'imagerie dans Azure

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 VHD est de 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.

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 reconstruction d’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 les VHD

Les images VHD sur Azure doivent avoir une taille virtuelle alignée sur 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’êtes pas dans un environnement Windows, nous vous recommandons d’utiliser qemu-img pour convertir le VHD, si nécessaire, et le redimensionner.

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: laisser les pilotes Hyper-V gérer les disques par défaut
• storvsc : prendre en compte les paquets en transit dans le chemin de réinitialisation
• storvsc : éviter l’utilisation de WRITE_SAME
• storvsc : Désactiver WRITE SAME pour les pilotes RAID et d’adaptateur d’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 pour Azure

L'agent Azure Linux (waagent) approvisionne une machine virtuelle Linux dans Azure. Vous pouvez télécharger la dernière version, signaler des problèmes ou soumettre des pull requests dans le dépôt GitHub de l’agent Linux.

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.

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 le support Azure à déboguer tout problème.

   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 en mode silencieux n’est pas utile dans un environnement cloud où nous voulons tous les journaux d’activité 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. Une fois que vous avez terminé la modification de /etc/default/grub, régénérez la configuration grub. Exécutez uniquement la commande appropriée pour votre distribution.

   Pour les distributions basées sur Debian ou Ubuntu, exécutez :

   sudo update-grub
   

   Pour les distributions qui fournissent grub2-mkconfig, telles que RHEL, Oracle Linux et SUSE, exécutez :

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

   Sur les distributions qui fournissent grub-mkconfig à la place, exécutez :

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

   Le chemin de configuration GRUB peut différer pour les installations UEFI. Si votre distribution utilise un autre chemin, utilisez le chemin documenté pour cette distribution.

3. Ajoutez les modules Hyper-V au disque RAM initial. Exécutez uniquement la procédure qui correspond aux outils utilisés par votre distribution.

   1. Pour une distribution basée sur dracut, exécutez :

   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. Pour une distribution qui utilise mkinitramfs, exécutez cette procédure au lieu de la procédure dracut :

   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. Uniquement si vous créez une image pour un contrôleur de disque NVMe distant, configurez et vérifiez la prise en charge du démarrage NVMe. Sinon, ignorez cette étape. Les commandes exactes peuvent varier en fonction de la distribution.

   1. Reconstruisez le initramfs en y intégrant les pilotes NVMe, en utilisant la méthode propre à votre distribution.

      Pour une distribution basée sur dracut, rendez les pilotes NVMe persistants dans les futures images initramfs et régénérez l’image initramfs actuelle :

      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
      

      Pour une distribution basée sur initramfs-tools, rendez les pilotes NVMe persistants et régénérez initramfs :

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

   2. Ajoutez nvme_core.io_timeout=240 à la ligne de commande existante du noyau dans /etc/default/grub, puis régénérez la configuration GRUB à l’aide de la commande appropriée à votre distribution.

   3. Vérifiez que les deux modules de pilote NVMe sont disponibles sur le système. Exécutez les deux commandes :

      modinfo nvme
      modinfo nvme_core
      

      Chaque commande doit retourner des informations sur son module. Si aucun module n’est trouvé, installez ou activez-le en suivant la documentation de votre distribution avant de continuer.

   4. Vérifiez que les deux pilotes NVMe sont inclus dans initramfs. Exécutez uniquement la commande pour votre distribution.

      Pour une distribution basée sur dracut, exécutez :

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

      Pour une distribution basée sur initramfs-tools, exécutez :

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

      La sortie doit afficher les pilotes nvme_core et nvme. Si ce n’est pas le cas, consultez la documentation de votre distribution et régénérez le disque RAM initial avant de continuer.

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

6. 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 et d’autres utilitaires nécessaires. Exécutez uniquement la commande du gestionnaire de package disponible sur votre système.

   Pour dnf, exécutez :

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

   Si votre système fournit yum au lieu de dnf, remplacez dnf par yum dans la commande précédente.

   Pour apt, exécutez :

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

   Pour zypper, exécutez :

   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
   

7. 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. Azure attache ce disque de ressources à la machine virtuelle après l’approvisionnement. Le disque de ressource local est temporaire et peut être vidé lorsque la machine virtuelle est déprovisionnée.

   Important

   Ces instructions s’appliquent si le contrôleur de disque distant est SCSI ou NVMe. Ils nécessitent une taille de machine virtuelle qui inclut un disque de ressources temporaire local. Le type de contrôleur de disque distant ne détermine pas si un disque de ressource est disponible.

   1. Choisissez et configurez une méthode pour gérer l’espace d’échange.

      Pour utiliser 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.
      

      Pour utiliser cloud-init à la place, configurez cloud-init pour gérer l’approvisionnement et empêcher l’agent Linux Azure de mettre en forme le disque de ressource ou de créer un espace d’échange :

      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. Si vous avez choisi cloud-init, choisissez comment fournir la configuration de l’échange.

      Vous pouvez transmettre une configuration cloud-init via customdata chaque fois que vous créez une machine virtuelle. Utilisez cette méthode.

      Vous pouvez également ajouter une directive cloud-init à l’image afin que l’espace d’échange soit configuré chaque fois qu’une machine virtuelle est créée. Pour utiliser cette méthode, créez un fichier .cfg :

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

9. Validez la configuration du montage du disque avant de déprovisionner la machine virtuelle. Cette validation s’applique aux images NVMe distantes et SCSI.

   1. Vérifiez /etc/fstab. N’utilisez pas de noms d’appareils tels que /dev/sd* ou /dev/nvme*, car les noms d’appareils peuvent changer entre les redémarrages ou lorsque le contrôleur de disque change. Utilisez plutôt des UUID de système de fichiers ou d’autres identificateurs persistants.

      Répertoriez les appareils de blocage et leurs identificateurs persistants afin de pouvoir les comparer aux entrées dans /etc/fstab:

      sudo blkid
      

   2. Vérifiez /etc/fstab pour détecter les erreurs de syntaxe, les options de montage non valides et les références qui ne peuvent pas être résolues :

      sudo findmnt --verify --verbose
      

   3. Seulement si vous créez une image pour un contrôleur de disque NVMe distant, vérifiez le délai d’expiration d’E/S configuré. Si la machine virtuelle source utilise actuellement NVMe, exécutez :

      cat /sys/module/nvme_core/parameters/io_timeout
      

      La valeur doit être 240. Une machine virtuelle source SCSI peut ne pas exposer ce paramètre d’exécution ; dans ce cas, vérifiez qu’elle nvme_core.io_timeout=240 est présente dans la configuration GRUB et que la configuration reconstruite la contient.

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

    Mise en garde

    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.

11. Arrêtez la machine virtuelle et téléchargez le VHD vers Azure.

Étapes suivantes

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

Pour une machine virtuelle Azure existante que vous devez passer de SCSI à NVMe, utilisez Convertir des machines virtuelles Linux et Windows de SCSI en NVMe. Pour plus d’informations sur l’architecture et la prise en charge, consultez la vue d’ensemble de NVMe.