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 immagini VHD in Azure devono avere dimensioni virtuali 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 Bash utilizza qemu-img info per determinare la dimensione virtuale dell'immagine del disco e quindi calcola la dimensione arrotondandola al MB successivo:

   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, eseguire il comando seguente per ricompilare la configurazione GRUB:

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

3. Aggiungere il modulo Hyper-V per initramfs usando 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
   

   Aggiungere il modulo Hyper-V per initrd usando 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. Verificare che il server SSH sia installato e configurato per l'esecuzione all'avvio. Questa configurazione è in genere l'impostazione predefinita.

5. 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 rimozione o la disabilitazione causeranno 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 eseguendo uno dei comandi seguenti.

   Usare questo comando per Red Hat o CentOS:

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

   Usare questo comando per Ubuntu/Debian:

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

   Usare questo comando per SUSE:

   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
   

6. 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. Questo disco di risorse viene collegato alla macchina virtuale dopo il provisioning in Azure. Il disco della risorsa locale è un disco temporaneo e potrebbe essere svuotato quando viene eseguito il deprovisioning della macchina virtuale. I blocchi seguenti illustrano come configurare questo scambio.

   Se si sceglie Azure Agente Linux, 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.
   

   Se si sceglie cloud-init, configurare cloud-init per gestire il provisioning:

   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
   

   Per configurare cloud-init per formattare e creare spazio di scambio, sono disponibili due opzioni:

   • Specifica una configurazione cloud-init ogni volta che crei una macchina virtuale attraverso customdata. È consigliabile adottare questa soluzione.
   • Usare una direttiva cloud-init nell'immagine per configurare lo spazio di scambio ogni volta che viene creata la macchina virtuale.

   Creare un file con estensione cfg per configurare lo spazio di scambio usando 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. 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
      

8. Eseguire i comandi seguenti per eseguire 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.

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