Preparare una macchina virtuale SLES o openSUSE Leap per Azure

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

In alcuni casi, potrebbe essere necessario usare SUSE Linux Enterprise Server (SLES) personalizzato o openSUSE Leap Linux virtual machines (VM) nell'ambiente Azure ed essere in grado di compilare questi tipi di macchine virtuali tramite l'automazione. Questo articolo illustra come creare e caricare un disco rigido virtuale di Azure personalizzato contenente un sistema operativo SUSE Linux.

Prerequisiti

Questo articolo presuppone che sia già stato installato un sistema operativo SLES o openSUSE Leap Linux in un disco rigido virtuale. Sono disponibili vari strumenti per la creazione di file VHD. Ad esempio, è possibile usare una soluzione di virtualizzazione, ad esempio Hyper-V. Per istruzioni, vedere Installare il ruolo Hyper-V e configurare una macchina virtuale.

Note sull'installazione di SLES/openSUSE Leap

  • Per altri suggerimenti sulla preparazione di immagini Linux per Azure, vedere Note generali sull'installazione di Linux.
  • Azure non supporta i file Immagine disco rigido Windows (con estensione vhdx). Solo i file VHD (con estensione vhd) sono supportati all'esterno delle macchine virtuali. È possibile convertire il disco in formato VHD tramite la console di gestione di Hyper-V o il cmdlet Convert-VHD.
  • 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.
  • Non configurare una partizione swap nel disco del sistema operativo. È possibile configurare l'agente Linux per poter creare un file di scambio sul disco temporaneo delle risorse. I passaggi successivi in questo articolo forniscono altre informazioni sulla configurazione dello spazio di scambio.
  • Le dimensioni di tutti i dischi rigidi virtuali in Azure devono essere allineate a 1 MB. 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. Per altre informazioni, vedere Note generali sull'installazione di Linux.

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.

Usare SUSE Studio

SUSE Studio può creare e gestire facilmente le immagini SLES e openSUSE Leap per Azure e Hyper-V. SUSE Studio è l'approccio consigliato per personalizzare le proprie immagini SLES e openSUSE Leap.

In alternativa alla creazione di un disco rigido virtuale personalizzato, SUSE pubblica anche immagini BYOS (Bring Your Own Subscription) per SLES in VM Depot.

Preparare SLES per Azure

  1. Configurare i moduli Azure e Hyper-V, se necessario.

    Se l'hypervisor software non è Hyper-V, è necessario aggiungere altri moduli nel disco RAM iniziale (initramfs) per eseguire correttamente l'avvio in Azure.

    Modificare il file /etc/dracut.conf e aggiungere la riga seguente al file:

    add_drivers+=" hv_vmbus hv_netvsc hv_storvsc "
    

    Eseguire il dracut comando per ricompilare il file initramfs:

    sudo dracut --verbose --force
    
  2. Configurare la console seriale.

    Per usare correttamente la console seriale, è necessario configurare diverse variabili nel file /etc/defaults/grub e ricreare GRUB nel server:

    # Add console=ttyS0 and earlyprintk=ttS0 to the variable.
    # Remove "splash=silent" and "quiet" options.
    GRUB_CMDLINE_LINUX_DEFAULT="audit=1 no-scroll fbcon=scrollback:0 mitigations=auto security=apparmor crashkernel=228M,high crashkernel=72M,low console=ttyS0 earlyprintk=ttyS0"
    
    # Add "console serial" to GRUB_TERMINAL.
    GRUB_TERMINAL="console serial"
    
    # Set the GRUB_SERIAL_COMMAND variable.
    
    GRUB_SERIAL_COMMAND="serial --speed=115200 --unit=0 --word=8 --parity=no --stop=1"
    
    /usr/sbin/grub2-mkconfig -o /boot/grub2/grub.cfg
    
  3. Registrare il sistema SUSE Linux Enterprise per scaricare gli aggiornamenti e installare i pacchetti.

  4. Aggiornare il sistema con tutte le patch più recenti:

    sudo zypper update
    
  5. Installare l'agente di macchine virtuali Linux di Azure (waagent) e cloud-init:

    sudo SUSEConnect -p sle-module-public-cloud/15.2/x86_64  (SLES 15 SP2)
    sudo zypper refresh
    sudo zypper install python-azure-agent
    sudo zypper install cloud-init
    
  6. Abilitare waagent e cloud-init per l'avvio:

    sudo systemctl enable  waagent
    sudo systemctl enable cloud-init-local.service
    sudo systemctl enable cloud-init.service
    sudo systemctl enable cloud-config.service
    sudo systemctl enable cloud-final.service
    sudo systemctl daemon-reload
    sudo cloud-init clean
    
  7. Aggiornare la configurazione di cloud-init:

    cat <<EOF | sudo tee /etc/cloud/cloud.cfg.d/91-azure_datasource.cfg
    datasource_list: [ Azure ]
    datasource:
        Azure:
            apply_network_config: False
    
    EOF
    
    sudo cat <<EOF | sudo tee  /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
    
    # Make sure mounts and disk_setup are in the init stage:
    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
    
  8. Se si vuole montare, formattare e creare una partizione di scambio, è possibile passare una configurazione cloud-init ogni volta che si crea una macchina virtuale.

    Un'altra opzione consiste nell'usare una direttiva cloud-init nell'immagine per configurare lo spazio di scambio ogni volta che viene creata la macchina virtuale:

    cat  <<EOF | sudo tee -a /etc/systemd/system.conf
    'DefaultEnvironment="CLOUD_CFG=/etc/cloud/cloud.cfg.d/00-azure-swap.cfg"'
    EOF
    
    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"]
      - ["ephemeral0.2", "none", "swap", "sw,nofail,x-systemd.requires=cloud-init.service,x-systemd.device-timeout=2", "0", "0"]
    EOF
    
  9. In precedenza, l'agente Linux di Azure veniva usato per configurare automaticamente lo spazio di scambio usando il disco delle risorse locale collegato alla macchina virtuale dopo il provisioning della macchina virtuale in Azure. Poiché cloud-init gestisce ora questo passaggio, non è necessario usare l'agente Linux di Azure per formattare il disco delle risorse o creare il file di scambio. Usare questi comandi per modificare /etc/waagent.conf in modo appropriato:

    sudo sed -i 's/Provisioning.UseCloudInit=n/Provisioning.UseCloudInit=auto/g' /etc/waagent.conf
    sudo sed -i 's/Provisioning.Enabled=y/Provisioning.Enabled=n/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
    

    Nota

    Se si usa una versione cloud-init precedente alla 21.2, assicurarsi che il udf modulo sia abilitato. La rimozione o la disabilitazione del modulo causeranno un errore di provisioning o avvio. Cloud-init versione 21.2 o successiva rimuove il requisito della funzione definita dall'utente.

  10. Assicurarsi che il file /etc/fstab faccia riferimento al disco usando il relativo UUID (by-uuid).

  11. Rimuovere le regole udev e i file di configurazione della scheda di rete per evitare di generare regole statiche per le interfacce Ethernet. Queste regole possono causare problemi durante la clonazione di una macchina virtuale in Microsoft Azure o Hyper-V.

    sudo rm -f /etc/udev/rules.d/70-persistent-net.rules
    sudo rm -f /etc/udev/rules.d/85-persistent-net-cloud-init.rules
    sudo rm -f /etc/sysconfig/network/ifcfg-eth*
    
  12. È consigliabile modificare il file /etc/sysconfig/network/dhcp e modificare il DHCLIENT_SET_HOSTNAME parametro come segue:

    DHCLIENT_SET_HOSTNAME="no"
    
  13. Nel file /etc/sudoers impostare come commento o rimuovere le righe seguenti, se presenti:

    Defaults targetpw   # Ask for the password of the target user i.e. root
    ALL    ALL=(ALL) ALL   # WARNING! Only use this setting together with 'Defaults targetpw'!
    
  14. Assicurarsi che il server Secure Shell (SSH) sia installato e configurato per l'avvio in fase di avvio:

    sudo systemctl enable sshd
    
  15. Pulire la fase cloud-init:

    sudo cloud-init clean --seed --logs
    
  16. Eseguire i comandi seguenti per eseguire il deprovisioning della macchina virtuale e prepararlo per il provisioning in Azure.

    Se si esegue la migrazione di una macchina virtuale specifica e non si vuole creare un'immagine generalizzata, ignorare il passaggio di deprovisioning.

    sudo rm -f /var/log/waagent.log
    sudo waagent -force -deprovision+user
    sudo export HISTSIZE=0
    sudo rm -f ~/.bash_history
    

Preparare openSUSE 15.4+

  1. Nel riquadro centrale della console di gestione di Hyper-V selezionare la macchina virtuale.

  2. Selezionare Connetti per aprire la finestra per la macchina virtuale.

  3. In un terminale eseguire il comando zypper lr. Se questo comando restituisce un output simile all'esempio seguente, i repository vengono configurati come previsto e non sono necessarie modifiche. I numeri di versione possono variare.

    # Alias Nome Attivata Controllo Criteri di gruppo Refresh
    1 Cloud:Tools_15.4 Cloud:Tools-> (r ) Sì
    2 openSUSE_stable_OSS openSUSE_st-> (r ) Sì
    3 openSUSE_stable_Updates openSUSE_st-> (r ) Sì

    Se il messaggio "Nessun repository definito" viene visualizzato dai zypper lr repository deve essere aggiunto manualmente.

    Di seguito sono riportati esempi di comandi per l'aggiunta di questi repository (le versioni e i collegamenti possono variare):

    sudo zypper ar -f https://download.opensuse.org/update/openSUSE-stable openSUSE_stable_Updates
    sudo zypper ar -f https://download.opensuse.org/repositories/Cloud:/Tools/15.4 Cloud:Tools_15.4
    sudo zypper ar -f https://download.opensuse.org/distribution/openSUSE-stable/repo/oss openSUSE_stable_OSS
    

    È quindi possibile verificare che i repository siano stati aggiunti eseguendo di nuovo il comando zypper lr . Se uno dei repository di aggiornamento pertinenti non è abilitato, abilitarlo usando il comando seguente:

    sudo zypper mr -e [NUMBER OF REPOSITORY]
    
  4. Aggiornare il kernel all'ultima versione disponibile:

    sudo zypper up kernel-default
    

    In alternativa, aggiornare il sistema operativo con tutte le patch più recenti:

    sudo zypper update
    
  5. Installare l'agente Linux di Azure:

    sudo zypper install WALinuxAgent
    
  6. Modificare la riga di avvio del kernel nella configurazione GRUB per includere altri parametri del kernel per Azure. A tale scopo, aprire /boot/grub/menu.lst in un editor di testo e assicurarsi che il kernel predefinito includa i parametri seguenti:

    console=ttyS0 earlyprintk=ttyS0
    

    Questa opzione garantisce che tutti i messaggi della console vengano inviati alla prima porta seriale, che consente di supporto tecnico di Azure con problemi di debug. Rimuovere inoltre i messaggi seguenti dalla riga di avvio del kernel, se presenti:

     libata.atapi_enabled=0 reserve=0x1f0,0x8
    
  7. È consigliabile modificare il file /etc/sysconfig/network/dhcp e modificare il DHCLIENT_SET_HOSTNAME parametro con l'impostazione seguente:

     DHCLIENT_SET_HOSTNAME="no"
    
  8. Nel file /etc/sudoers impostare come commento o rimuovere le righe seguenti, se presenti. Questo è un passaggio importante.

    Defaults targetpw   # ask for the password of the target user i.e. root
    ALL    ALL=(ALL) ALL   # WARNING! Only use this together with 'Defaults targetpw'!
    
  9. Verificare che il server SSH sia installato e configurato per l'esecuzione all'avvio.

  10. Non creare l'area di swap sul disco del sistema operativo.

    L'agente Linux di Azure può configurare automaticamente lo spazio di scambio usando il disco delle risorse locale collegato alla macchina virtuale dopo il provisioning in Azure. Il disco della risorsa locale è un disco temporaneo e verrà svuotato quando viene eseguito il deprovisioning della macchina virtuale.

    Dopo aver installato l'agente Linux di Azure, modificare i parametri in /etc/waagent.conf come indicato di seguito:

    ResourceDisk.Format=n
    ResourceDisk.Filesystem=ext4
    ResourceDisk.MountPoint=/mnt/resource
    ResourceDisk.EnableSwap=n
    ResourceDisk.SwapSizeMB=2048    ## NOTE: set the size to whatever you need it to be.
    
  11. Assicurarsi che l'agente Linux di Azure venga eseguito all'avvio:

    sudo systemctl enable waagent.service
    
  12. Eseguire i comandi seguenti per eseguire il deprovisioning della macchina virtuale e prepararlo per il provisioning in Azure.

    Se si esegue la migrazione di una macchina virtuale specifica e non si vuole creare un'immagine generalizzata, ignorare il passaggio di deprovisioning.

    sudo rm -f ~/.bash_history # Remove current user history
    sudo rm -rf /var/lib/waagent/
    sudo rm -f /var/log/waagent.log
    sudo waagent -force -deprovision+user
    sudo rm -f ~/.bash_history # Remove root user history
    sudo export HISTSIZE=0
    
  13. Selezionare Azione>Arresta nella Console di gestione di Hyper-V.

Passaggi successivi

È ora possibile usare il disco rigido virtuale SUSE Linux per creare nuove macchine virtuali in Azure. Se è la prima volta che si carica il file VHD in Azure, vedere Creare una macchina virtuale Linux da un disco personalizzato.