Preparare Linux per la creazione di immagini in Azure

Si applica a: ✔️ macchine virtuali di Linux ✔️ set di scalabilità flessibili

Il contratto di servizio della piattaforma Azure si applica alle macchine virtuali (VM) che eseguono il sistema operativo Linux solo quando si usa una delle distribuzioni approvate. Per le distribuzioni approvate, Azure Marketplace fornisce immagini Linux preconfigurate. Per ulteriori informazioni consulta:

• Distribuzioni Linux supportate in Azure
• Supporto per Linux e le tecnologie open source in Azure

Tutte le altre distribuzioni in esecuzione in Azure, incluse le distribuzioni supportate dalla community e non approvate, hanno alcuni prerequisiti.

Questo articolo è incentrato sulle linee guida generali per l'esecuzione della distribuzione linux in Azure. Questo articolo non può essere completo, perché ogni distribuzione è diversa. Anche se si soddisfano tutti i criteri descritti in questo articolo, potrebbe essere necessario modificare in modo significativo il sistema Linux in modo che venga eseguito correttamente.

Note generali sull'installazione di Linux

• Azure non supporta il formato Hyper-V disco rigido virtuale (VHDX). Azure supporta solo dischi rigidi virtuali a dimensione fissa. È possibile convertire il disco in formato VHD usando Hyper-V Manager o il cmdlet Convert-VHD. Se si usa VirtualBox, selezionare Dimensioni fisse anziché l'impostazione predefinita (allocata dinamicamente) durante la creazione del disco.

• Azure supporta macchine virtuali Gen1 (avvio BIOS) e Gen2 (avvio UEFI).

• Il modulo kernel VFAT (Virtual File Allocation Table) deve essere abilitato nel kernel.

• La dimensione massima consentita per il VHD è di 1.023 GB.

• Quando si installa il sistema Linux, è consigliabile usare partizioni standard anziché Gestione volumi logici (LVM). LVM è l'impostazione predefinita per molte installazioni.

  L'uso di partizioni standard consente di evitare conflitti di nome LVM con macchine virtuali clonate, in particolare se un disco del sistema operativo è mai collegato a un'altra macchina virtuale identica per la risoluzione dei problemi. È possibile usare LVM o RAID nei dischi dati.

• È necessario il supporto del kernel per il montaggio di file system UDF (User-Defined Function). Al primo avvio in Azure, la configurazione di provisioning viene passata alla macchina virtuale Linux tramite supporti formattati UDF collegati alla macchina guest. L'agente Linux Azure deve montare il file system UDF per leggerne la configurazione ed effettuare il provisioning della macchina virtuale.

• Le versioni del kernel Linux precedenti alla 2.6.37 non supportano NUMA (Non-Uniform Memory Access) in Hyper-V con dimensioni di vm maggiori. Questo problema riguarda principalmente le distribuzioni precedenti che usano il kernel upstream Red Hat 2.6.32. È stato corretto in Red Hat Enterprise Linux (RHEL) 6.6 (kernel-2.6.32-504).

  I sistemi che eseguono kernel personalizzati precedenti alla 2.6.37 o kernel basati su RHEL precedenti alla versione 2.6.32-504 devono impostare il parametro numa=off di avvio nella riga di comando del kernel in grub.conf. Per altre informazioni, vedere l'articolo KB 436883 di Red Hat.

• Non configurare una partizione di scambio sul disco del sistema operativo. È possibile configurare l'agente Linux per creare un file di scambio sul disco risorse temporaneo, come descritto più avanti in questo articolo.

• Tutti i VHD in Azure devono avere una dimensione virtuale allineata a 1 MB (1024 x 1024 byte). Quando si converte un disco raw in un VHD, assicurarsi che la dimensione del disco raw sia un multiplo di 1 MB prima della conversione, come descritto più avanti in questo articolo.

• Utilizzare la versione della distribuzione, i pacchetti e il software più aggiornati.

• Rimuovere utenti e account di sistema, chiavi pubbliche, dati sensibili, software non necessario e applicazioni.

Installare moduli kernel senza Hyper-V

Azure viene eseguito nell'hypervisor Hyper-V, quindi Linux richiede l'esecuzione di alcuni moduli kernel in Azure. Se si dispone di una macchina virtuale creata all'esterno di Hyper-V, i programmi di installazione di Linux potrebbero non includere i driver per Hyper-V nel disco RAM iniziale (initrd o initramfs), a meno che la macchina virtuale non rilevi che sia in esecuzione in un ambiente Hyper-V.

Quando si usa un sistema di virtualizzazione diverso(ad esempio VirtualBox o KVM) per preparare l'immagine Linux, potrebbe essere necessario ricompilare initrd in modo che almeno i hv_vmbus moduli kernel e hv_storvsc siano disponibili nel disco RAM iniziale. Questo problema noto riguarda i sistemi basati sulla distribuzione upstream di Red Hat e possibilmente su altri.

Il meccanismo per la ricostruzione dell'immagine initrd o initramfs può variare a seconda della distribuzione. Per la procedura appropriata, consultare la documentazione della distribuzione o il supporto. Ecco un esempio di come rigenerare initrd utilizzando l'utilità mkinitrd:

1. Effettua un backup dell'immagine initrd esistente:

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

2. Rigenerare initrd utilizzando i moduli del kernel hv_vmbus e hv_storvsc:

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

Ridimensionare i dischi rigidi virtuali

Le dimensioni virtuali delle immagini VHD su Azure devono essere allineate a 1 MB. In genere, i VHD creati con Hyper-V sono allineati correttamente. Se il disco rigido virtuale non è allineato correttamente, è possibile che venga visualizzato un messaggio di errore simile all'esempio seguente quando si tenta di creare un'immagine dal disco rigido virtuale:

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

In questo caso, ridimensionare la macchina virtuale usando la console di Hyper-V Manager o il cmdlet di PowerShell Resize-VHD. Se non utilizzi un ambiente Windows, consigliamo di usare qemu-img per convertire (se necessario) e ridimensionare il VHD.

1. Il ridimensionamento diretto del disco rigido virtuale tramite strumenti come qemu-img o vbox-manage può comportare un disco rigido virtuale non avviabile. Si consiglia di convertire prima il VHD in un'immagine disco raw utilizzando il codice seguente.

   Se l'immagine della macchina virtuale è stata creata come immagine del disco non elaborato, è possibile ignorare questo passaggio. La creazione dell'immagine di macchina virtuale come immagine del disco non elaborato è l'impostazione predefinita in alcuni hypervisor, ad esempio KVM.

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

2. Calcolare le dimensioni necessarie dell'immagine del disco in modo che le dimensioni virtuali siano allineate a 1 MB. Il seguente script della shell Bash usa qemu-img info per determinare le dimensioni virtuali dell'immagine disco, quindi calcola le dimensioni al successivo 1 MB:

   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. Ridimensionare il disco non elaborato usando $rounded_size:

   sudo qemu-img resize MyLinuxVM.raw $rounded_size
   

4. Converti nuovamente il disco raw in un VHD a dimensione fissa:

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

   In alternativa, con le versioni QEMU precedenti alla 2.6, rimuovere l'opzione force_size :

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

Requisiti del kernel Linux

I driver LIS (Linux Integration Services) per Hyper-V e Azure vengono forniti direttamente al kernel Linux upstream. Molte distribuzioni che includono una versione recente del kernel Linux (ad esempio 3.x) hanno già questi driver oppure forniscono versioni backported di questi driver con i kernel.

I driver LIS vengono costantemente aggiornati nel kernel upstream con nuove correzioni e funzionalità. Quando possibile, è consigliabile eseguire una distribuzione approvata che include queste correzioni e gli aggiornamenti.

Se si esegue una variante di RHEL versione 6.0 alla 6.3, è necessario installare i driver LIS latest LIS per Hyper-V. A partire da RHEL 6.4+ (e derivati), i driver LIS sono già inclusi nel kernel, quindi non sono necessari pacchetti di installazione aggiuntivi.

Se è necessario un kernel personalizzato, è consigliabile usare una versione recente del kernel( ad esempio 3.8+). Per le distribuzioni o i fornitori che mantengono il proprio kernel, è necessario eseguire regolarmente il backport dei driver LIS dal kernel upstream al kernel personalizzato.

Anche se si sta già eseguendo una versione del kernel relativamente recente, è consigliabile tenere traccia di eventuali correzioni upstream nei driver LIS e di eseguirne il backporting in base alle esigenze. I percorsi dei file di origine del driver LIS vengono specificati nel file MAINTAINERS nell'albero di origine del kernel 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/

Il kernel attivo della macchina virtuale deve includere le patch seguenti. Non è possibile completare l'elenco per tutte le distribuzioni.

• ata_piix: rinvia i dischi ai driver di Hyper-V per impostazione predefinita
• storvsc: tenere conto dei pacchetti in transito nel percorso di RESET
• storvsc: evitare l'utilizzo di WRITE_SAME
• storvsc: Disabilita WRITE SAME per i driver RAID e degli adattatori host virtuali
• storvsc: correzione della dereferenziazione di un puntatore NULL
• storvsc: gli errori del buffer circolare possono causare un blocco di I/O
• scsi_sysfs: protezione dalla doppia esecuzione di __scsi_remove_device

Agente Linux di Azure

L'agente Linux Azure (waagent) effettua il provisioning di una macchina virtuale Linux in Azure. È possibile ottenere la versione più recente, segnalare i problemi o inviare richieste pull nel repository Linux Agent GitHub.

Di seguito sono riportate alcune considerazioni sull'uso dell'agente Linux Azure:

• L'agente Linux viene rilasciato con la licenza apache 2.0. Molte distribuzioni forniscono già pacchetti rpm o .deb per l'agente. È possibile installare e aggiornare facilmente questi pacchetti.
• L'agente Linux Azure richiede Python v2.6+.
• L'agente richiede anche il python-pyasn1 modulo . La maggior parte delle distribuzioni fornisce questo modulo come pacchetto separato da installare.
• In alcuni casi, l'agente Linux Azure potrebbe non essere compatibile con NetworkManager. Molti dei pacchetti (rpm o .deb) forniti dalle distribuzioni configurano NetworkManager come conflitto con il waagent pacchetto. In questi casi, l'agente disinstalla NetworkManager quando si installa il pacchetto dell'agente Linux.
• Azure Linux Agent deve avere una versione pari o superiore alla versione minima supportata.

Requisiti di sistema Linux generali

1. Modificare la riga di avvio del kernel in GRUB o GRUB2 in modo da includere i parametri seguenti, perché tutti i messaggi della console vengano inviati alla prima porta seriale. Questi messaggi possono aiutare il supporto di Azure per il debug di eventuali problemi.

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

   È anche consigliabile rimuovere i parametri seguenti, se esistenti:

   rhgb quiet crashkernel=auto
   

   L'avvio grafico e non silenzioso non è utile in un ambiente cloud, in cui si vogliono inviare tutti i log alla porta seriale. È possibile lasciare l'opzione crashkernel configurata se necessario, ma questo parametro riduce la quantità di memoria disponibile nella macchina virtuale di almeno 128 MB. La riduzione della memoria disponibile potrebbe essere problematica per le dimensioni delle macchine virtuali più piccole.

2. Dopo aver completato la modifica di /etc/default/grub, ricompilare la configurazione GRUB. Eseguire solo il comando appropriato per la distribuzione.

   Per le distribuzioni basate su Debian o Ubuntu, eseguire:

   sudo update-grub
   

   Per le distribuzioni che forniscono grub2-mkconfig, ad esempio RHEL, Oracle Linux e SUSE, eseguire:

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

   Nelle distribuzioni che forniscono grub-mkconfig invece eseguire:

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

   Il percorso di configurazione GRUB può essere diverso per le installazioni UEFI. Se la distribuzione usa un altro percorso, usare il percorso documentato per tale distribuzione.

3. Aggiungere i moduli Hyper-V al disco RAM iniziale. Eseguire solo la procedura corrispondente agli strumenti usati dalla distribuzione.

   1. Per una distribuzione basata su dracut, eseguire:

   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. Per una distribuzione che usa mkinitramfs, eseguire questa procedura anziché la procedura 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. Solo se si sta creando un'immagine per un controller disco NVMe remoto, configurare e verificare il supporto dell'avvio NVMe. In caso contrario, ignorare questo passaggio. I comandi esatti possono variare in base alla distribuzione.

   1. Rigenerare l'initramfs con i driver NVMe utilizzando il metodo previsto per la propria distribuzione.

      Per una distribuzione basata su dracut, rendere persistenti i driver NVMe nelle immagini initramfs future e ricompilare le initramfs correnti:

      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
      

      Per una distribuzione basata su initramfs-tools, rendere persistenti i driver NVMe e ricostruire initramfs:

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

   2. Aggiungere nvme_core.io_timeout=240 alla riga di comando del kernel esistente in /etc/default/grube quindi ricompilare la configurazione GRUB usando il comando appropriato per la distribuzione.

   3. Verificare che nel sistema siano disponibili entrambi i moduli driver NVMe. Eseguire entrambi i comandi:

      modinfo nvme
      modinfo nvme_core
      

      Ogni comando deve restituire informazioni sul relativo modulo. Se uno dei moduli non viene trovato, installarlo o abilitarlo seguendo la documentazione della distribuzione prima di continuare.

   4. Verificare che entrambi i driver NVMe siano inclusi in initramfs. Esegui solo il comando in base alla tua distribuzione.

      Per una distribuzione basata su dracut, eseguire:

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

      Per una distribuzione basata su initramfs-tools, eseguire:

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

      L'output deve mostrare entrambi i driver nvme_core e nvme. In caso contrario, consultare la documentazione della distribuzione e ricompilare il disco RAM iniziale prima di continuare.

5. Verificare che il server SSH sia installato e configurato per l'esecuzione all'avvio. Questa configurazione è in genere l'impostazione predefinita.

6. Installare l'agente Linux Azure.

   L'agente Linux Azure è necessario per il provisioning di un'immagine Linux in Azure. Molte distribuzioni forniscono l'agente come pacchetto rpm o .deb. Il pacchetto viene in genere chiamato WALinuxAgent o walinuxagent. È anche possibile installare manualmente l'agente seguendo la procedura descritta nella guida all'agente Linux Azure.

   Note

   Assicurarsi che i udf moduli e vfat siano abilitati. La loro rimozione o disabilitazione causerà un errore di provisioning o di avvio. Cloud-init dalla versione 21.2 in poi elimina il requisito UDF.

   Installare l'agente Linux Azure, cloud-init e altre utilità necessarie. Eseguire solo il comando per la gestione pacchetti disponibile nel sistema.

   Per dnf, eseguire:

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

   Se il sistema fornisce yum invece di dnf, sostituire dnf con yum nel comando precedente.

   Per apt, eseguire:

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

   Per zypper, eseguire:

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

   Abilitare quindi l'agente e cloud-init in tutte le distribuzioni:

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

7. Non creare spazio di scambio sul disco del sistema operativo.

   È possibile usare l'agente Linux Azure o cloud-init per configurare lo spazio di scambio tramite il disco delle risorse locale. Azure collega questo disco di risorse alla macchina virtuale dopo il provisioning. Il disco della risorsa locale è temporaneo e potrebbe essere svuotato quando viene eseguito il deprovisioning della macchina virtuale.

   Importante

   Queste istruzioni si applicano se il controller del disco remoto è SCSI o NVMe. Richiedono dimensioni di macchina virtuale che includono un disco risorse temporaneo locale. Il tipo di controller disco remoto non determina se è disponibile un disco di risorse.

   1. Scegliere e configurare un metodo per gestire lo spazio di scambio.

      Per usare l'agente Linux Azure, modificare i parametri seguenti 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.
      

      Per usare invece cloud-init, configurare cloud-init per gestire il provisioning e impedire ad Azure Linux Agent di formattare il disco risorse o creare spazio di swap:

      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. Se si sceglie cloud-init, scegliere come specificare la configurazione dello scambio.

      È possibile passare una configurazione cloud-init tramite customdata ogni volta che si crea una VM. Utilizzare questo metodo.

      In alternativa, aggiungere una direttiva cloud-init all'immagine in modo che lo spazio di scambio venga configurato ogni volta che viene creata una macchina virtuale. Per usare questo metodo, creare un file con estensione 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. Configurare cloud-init per gestire il provisioning:

   1. Configurare waagent per 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
      

      Se si esegue la migrazione di una macchina virtuale specifica e non si vuole creare un'immagine generalizzata, impostare Provisioning.Agent=disabled nella configurazione /etc/waagent.conf .

   2. Configurare i punti di montaggio

      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. Configurare l'origine dati di 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. Rimuovere il file di scambio esistente se ne è stato configurato uno:

      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. Configurare la registrazione dei log di 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. Convalidare la configurazione del montaggio del disco prima di eseguire il deprovisioning della macchina virtuale. Questa convalida si applica alle immagini NVMe remote e SCSI.

   1. Esaminare /etc/fstab. Non usare nomi di dispositivo come /dev/sd* o /dev/nvme*, perché i nomi dei dispositivi possono cambiare tra riavvii o quando il controller del disco cambia. Usare invece gli UUID del file system o altri identificatori persistenti.

      Elencare i dispositivi di blocco e i relativi identificatori permanenti in modo che sia possibile confrontarli con le voci in /etc/fstab:

      sudo blkid
      

   2. Verificare la presenza /etc/fstab di errori di sintassi, opzioni di montaggio non valide e riferimenti che non possono essere risolti:

      sudo findmnt --verify --verbose
      

   3. Solo se si sta creando un'immagine per un controller disco NVMe remoto, verificare il timeout di I/O configurato. Se la macchina virtuale di origine usa attualmente NVMe, eseguire:

      cat /sys/module/nvme_core/parameters/io_timeout
      

      Il valore deve essere 240. Una macchina virtuale di origine SCSI potrebbe non esporre questo parametro di runtime; in tal caso, verificare che nvme_core.io_timeout=240 sia presente nella configurazione GRUB e che la configurazione ricompilata lo contenga.

10. Eseguire i comandi seguenti per effettuare il deprovisioning della macchina virtuale.

    Attenzione

    Se si esegue la migrazione di una macchina virtuale specifica e non si vuole creare un'immagine generalizzata, ignorare il passaggio di deprovisioning. L'esecuzione del comando waagent -force -deprovision+user renderà inutilizzabile il computer di origine. Questo passaggio è destinato solo a creare un'immagine generalizzata.

    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, potresti visualizzare un messaggio di errore dopo aver eseguito waagent -force -deprovision, che dice [Errno 5] Input/output error. Questo messaggio di errore non è critico ed è possibile ignorarlo.

11. Spegnere la macchina virtuale e caricare il VHD in Azure.

Passaggi successivi

Creare una macchina virtuale Linux da un disco personalizzato usando il interfaccia della riga di comando di Azure

Per una macchina virtuale Azure esistente che è necessario passare da SCSI a NVMe, usare Convertire Linux e Windows macchine virtuali da SCSI a NVMe. Per informazioni sull'architettura e sul supporto, vedere Panoramica di NVMe.