Preparare Linux per la creazione di immagini in Azure

Attenzione

Questo articolo fa riferimento a CentOS, una distribuzione di Linux che ha raggiunto lo stato di fine del servizio (EOL). Valutare le proprie esigenze e pianificare di conseguenza. Per ulteriori informazioni, consultare la Guida alla fine del ciclo di vita di CentOS.

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 altre informazioni, vedi:

• Distribuzioni linux approvate in Azure
• Supporto per Linux e la tecnologia 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 VHDX (Virtual Hard Disk) Hyper-V. Azure supporta solo dischi rigidi virtuali a dimensione fissa. È possibile convertire il disco in formato VHD usando la console di gestione di Hyper-V o il cmdlet Convert-VHD . Se si usa VirtualBox, selezionare Dimensioni fisse anziché l'impostazione predefinita (allocata dinamicamente) durante la creazione del disco.

• supporto tecnico di Azure gen1 (avvio BIOS) e macchine virtuali Gen2 (avvio UEFI).

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

• La dimensione massima consentita per il disco rigido virtuale è 1023 GB.

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

  In questo modo, sarà possibile evitare conflitti di nome LVM con le macchine virtuali clonate, in particolare se sarà mai necessario collegare un disco del sistema operativo 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 del provisioning viene passata alla macchina virtuale Linux tramite supporti in formato UDF collegati al guest. È necessario che l'agente Linux di Azure possa 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 swap nel 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 dischi rigidi virtuali in Azure devono avere dimensioni virtuali allineate a 1 MB (1024 x 1024 byte). Quando si esegue la conversione da un disco non elaborato a un disco rigido virtuale, assicurarsi che le dimensioni del disco non elaborato siano multiple di 1 MB prima della conversione, come descritto più avanti in questo articolo.

• Usare la versione di distribuzione, i pacchetti e il software più aggiornati.

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

Nota

Cloud-init versione 21.2 o successiva rimuove il requisito della funzione definita dall'utente. Ma senza il udf modulo abilitato, il CD-ROM non verrà montato durante il provisioning, impedendo l'applicazione dei dati personalizzati. Una soluzione alternativa consiste nell'applicare i dati utente. Tuttavia, a differenza dei dati personalizzati, i dati utente non vengono crittografati. Per altre informazioni, vedere Formati di dati utente nella documentazione di cloud-init.

Installare moduli kernel senza Hyper-V

Poiché Azure viene eseguito nell'hypervisor Hyper-V, 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 è un problema noto per i sistemi basati sulla distribuzione upstream di Red Hat e può esserlo anche per altri sistemi.

Il meccanismo per la ricompilazione 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 per la ricompilazione di initrd usando l'utilità mkinitrd :

1. Eseguire il backup dell'immagine initrd esistente:

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

2. Ricompilare initrd usando i hv_vmbus moduli kernel 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 dischi rigidi virtuali creati tramite 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 gestione di Hyper-V o il cmdlet PowerShell Resize-VHD . Se l'ambiente di esecuzione non è Windows, è consigliabile usare qemu-img per convertire (se necessario) e ridimensionare il disco rigido virtuale.

Nota

C'è un bug noto in qemu-img per QEMU versione 2.2.1 e alcune versioni successive che generano un disco rigido virtuale formattato in modo non corretto. Il problema è stato risolto in QEMU 2.6. È consigliabile usare la versione 2.2.0 o precedente oppure la versione 2.6 o successiva.

1. Il ridimensionamento diretto del disco rigido virtuale tramite strumenti come qemu-img o vbox-manage può comportare un disco rigido virtuale non avviabile. È consigliabile prima convertire il disco rigido virtuale in un'immagine disco non elaborata usando 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 disco per assicurarsi che le dimensioni virtuali siano allineate a 1 MB. Lo script della shell Bash seguente usa qemu-img info per determinare le dimensioni virtuali dell'immagine del disco e 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. Convertire di nuovo il disco non elaborato in un disco rigido virtuale di dimensioni fisse:

   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 di Linux Integration Services (LIS) per Hyper-V e Azure vengono forniti direttamente nel kernel Linux upstream. Per molte distribuzioni che includono una versione recente del kernel Linux (ad esempio, 3.x) questi driver sono già disponibili o, in alternativa, forniscono versioni backport dei driver con i rispettivi 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 versioni da 6.0 a 6.3, è necessario installare i driver LIS più recenti 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 più recente del kernel, ad esempio la versione 3.8 e successive. 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 file di origine dei driver LIS si trovano 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. Questo elenco non può essere completato per tutte le distribuzioni.

• ata_piix: defer disks to the Hyper-V drivers by default
• storvsc: Account for in-transit packets in the RESET path
• storvsc: avoid usage of WRITE_SAME
• storvsc: Disable WRITE SAME for RAID and virtual host adapter drivers
• storvsc: NULL pointer dereference fix
• storvsc: ring buffer failures may result in I/O freeze
• scsi_sysfs: protect against double execution of __scsi_remove_device

Agente Linux di Azure

L'agente Linux di 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 GitHub dell'agente Linux.

Ecco alcune considerazioni sull'uso dell'agente Linux di 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 di Azure richiede Python 2.6 o versioni successive.
• L'agente richiede anche il python-pyasn1 modulo . La maggior parte delle distribuzioni fornisce questo modulo come pacchetto separato per l'installazione.
• In alcuni casi, l'agente Linux di 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.
• La versione dell'agente Linux di Azure deve essere successiva alla versione minima supportata.

Nota

Assicurarsi che i udf moduli e vfat siano abilitati. La disabilitazione del udf modulo causerà un errore di provisioning. La disabilitazione del vfat modulo causerà sia errori di provisioning che di avvio. Cloud-init versione 21.2 o successiva può effettuare il provisioning di macchine virtuali senza richiedere funzioni definite dall'utente se esistono entrambe queste condizioni:

• La macchina virtuale è stata creata usando chiavi pubbliche SSH e non password.
• Non sono stati forniti dati personalizzati.

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

5. Installare l'agente Linux di Azure.

   L'agente Linux di Azure è necessario per eseguire il provisioning di un'immagine Linux su 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 dell'agente Linux di Azure.

   Nota

   Assicurarsi che i udf moduli e vfat siano abilitati. La rimozione o la disabilitazione causeranno un errore di provisioning o avvio. Cloud-init versione 21.2 o successiva rimuove il requisito della funzione definita dall'utente.

   Installare l'agente Linux di 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 l'area di swap sul disco del sistema operativo.

   È possibile usare l'agente Linux di 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 risorse locale è un disco temporaneo e potrebbe essere svuotato in seguito al deprovisioning della macchina virtuale. I blocchi seguenti illustrano come configurare questo scambio.

   Se si sceglie l'agente Linux di 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.
   

   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:

   • Passare una configurazione cloud-init ogni volta che si crea una macchina virtuale tramite 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 montaggi:

      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 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 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 potrebbe essere visualizzato un messaggio di errore dopo l'esecuzione waagent -force -deprovision di .[Errno 5] Input/output error Questo messaggio di errore non è critico ed è possibile ignorarlo.

9. Arrestare la macchina virtuale e caricare il VHD in Azure.

Passaggi successivi

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