Preparar o Linux para criação de imagem no Azure

Aplica-se a: ✔️ Linux VMs ✔️ Conjuntos de escala flexível

O acordo de nível de serviço (SLA) da plataforma Azure aplica-se às máquinas virtuais (VMs) que executam o sistema operativo Linux apenas quando está a usar uma das distribuições endossadas. Para distribuições endossadas, o Azure Marketplace fornece imagens Linux pré-configuradas. Para obter mais informações, consulte:

• Endossou distribuições Linux em Azure
• Suporte para Linux e tecnologia open-source em Azure

Todas as outras distribuições a correr no Azure, incluindo distribuições apoiadas pela comunidade e não endossadas, têm alguns pré-requisitos.

Este artigo foca-se em orientações gerais para executar a sua distribuição Linux no Azure. Este artigo não pode ser abrangente, porque cada distribuição é diferente. Mesmo que cumpra todos os critérios que este artigo descreve, pode ser necessário ajustar significativamente o seu sistema Linux para que funcione corretamente.

Notas gerais de instalação do Linux

• Azure não suporta o formato Hyper-V disco rígido virtual (VHDX). O Azure suporta apenas VHD fixo. Pode converter o disco para formato VHD usando Hyper-V Manager ou o cmdlet Convert-VHD. Se estiveres a usar o VirtualBox, seleciona Tamanho Fixo em vez do padrão (Alocado Dinamicamente) ao criar o disco.

• O Azure suporta máquinas virtuais Gen1 (arranque BIOS) e Gen2 (arranque UEFI).

• O módulo do kernel da tabela virtual de alocação de ficheiros (VFAT) deve estar ativado no kernel.

• O tamanho máximo permitido para o VHD é de 1.023 GB.

• Ao instalar o sistema Linux, recomendamos que use partições padrão em vez do Logical Volume Manager (LVM). O LVM é o padrão para muitas instalações.

  Usar partições padrão evitará conflitos de nomes LVM com VMs clonadas, especialmente se um disco do sistema operativo for ligado a outra VM idêntica para resolução de problemas. Pode usar LVM ou RAID em discos de dados.

• É necessário o suporte do kernel para montar sistemas de ficheiros de função definida pelo utilizador (UDF). No primeiro arranque no Azure, a configuração de provisionamento é passada para a VM Linux através de media formatada em UDF que está ligada ao convidado. O agente Azure Linux deve montar o sistema de ficheiros UDF para ler a sua configuração e provisionar a VM.

• As versões do kernel Linux anteriores à 2.6.37 não suportam Acesso à Memória Não Uniforme (NUMA) em Hyper-V com VMs de maior dimensão. Este problema afeta principalmente distribuições mais antigas que utilizam o kernel upstream Red Hat 2.6.32. Foi corrigido no Red Hat Enterprise Linux (RHEL) 6.6 (kernel-2.6.32-504).

  Sistemas a executar kernels personalizados anteriores à 2.6.37, ou kernels baseados em RHEL anteriores à 2.6.32-504, devem definir o parâmetro numa=off de arranque na linha de comandos do kernel em grub.conf. Para obter mais informações, consulte Red Hat KB 436883.

• Não configures uma partição swap no disco do sistema operativo. Pode configurar o agente Linux para criar um ficheiro de swap no disco de recurso temporário, conforme descrito mais adiante neste artigo.

• Todos os VHDs no Azure devem ter um tamanho virtual alinhado a 1 MB (1024 x 1024 bytes). Quando estiver a converter de um disco bruto para VHD, certifique-se de que o tamanho bruto do disco é múltiplo de 1 MB antes da conversão, conforme descrito mais adiante neste artigo.

• Use a versão da distribuição, os pacotes e o software mais atualizados.

• Remover utilizadores e contas do sistema, chaves públicas, dados sensíveis, software e aplicações desnecessários.

Instale módulos do kernel sem Hyper-V

Azure corre no hipervisor Hyper-V, por isso o Linux exige que certos módulos do kernel corram em Azure. Se tiveres uma VM criada fora do Hyper-V, os instaladores Linux podem não incluir os drivers para Hyper-V no disco RAM inicial (initrd ou initramfs), a menos que a VM detete que está a correr num ambiente Hyper-V.

Quando estás a usar um sistema de virtualização diferente (como o VirtualBox ou o KVM) para preparar a tua imagem Linux, poderás ter de reconstruir o initrd para que, pelo menos, os módulos do kernel hv_vmbus e hv_storvsc estejam disponíveis no disco RAM inicial. Este problema conhecido aplica-se a sistemas baseados na distribuição upstream do Red Hat, e possivelmente a outros.

O mecanismo para reconstruir a imagem initrd ou initramfs pode variar, dependendo da distribuição. Consulte a documentação correspondente ou o suporte técnico da sua distribuição para obter o procedimento adequado. Aqui está um exemplo para reconstruir o Initrd usando a mkinitrd utilidade:

1. Faça backup da imagem original existente:

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

2. Reconstrua o initrd utilizando os módulos do kernel hv_vmbus e hv_storvsc:

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

Redimensionar VHDs

As imagens VHD no Azure devem ter um tamanho virtual alinhado a 1 MB. Normalmente, os VHDs criados através de Hyper-V estão alinhados corretamente. Se o VHD não estiver alinhado corretamente, pode receber uma mensagem de erro semelhante ao exemplo seguinte quando tentar criar uma imagem a partir do seu 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).

Neste caso, redimensione a VM usando a consola Hyper-V Manager ou o cmdlet PowerShell Redimension-VHD. Se não estiver a correr num ambiente Windows, recomendamos usar qemu-img para converter (se necessário) e redimensionar o VHD.

1. Redimensionar diretamente o VHD utilizando ferramentas como qemu-img ou vbox-manage pode resultar num VHD não arrancável. Recomendamos primeiro converter o VHD para uma imagem de disco raw usando o seguinte código.

   Se a imagem da VM foi criada como imagem de disco bruto, podes saltar este passo. Criar a imagem da VM como imagem de disco bruto é o padrão em alguns hipervisores, como o KVM.

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

2. Calcule o tamanho necessário da imagem de disco para que o tamanho virtual fique alinhado a 1 MB. O seguinte script shell Bash usa qemu-img info para determinar o tamanho virtual da imagem de disco, e depois calcula o tamanho para o próximo 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. Redimensione o disco bruto usando $rounded_size:

   sudo qemu-img resize MyLinuxVM.raw $rounded_size
   

4. Converter o disco bruto de volta para um VHD de tamanho fixo:

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

   Ou, com versões do QEMU anteriores à 2.6, remover a force_size opção:

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

Requisitos do kernel Linux

Os controladores dos Serviços de Integração Linux (LIS) para Hyper-V e Azure são integrados diretamente no kernel principal do Linux. Muitas distribuições que incluem uma versão recente do kernel Linux (como a 3.x) já têm estes drivers disponíveis, ou de outra forma fornecem versões retroportadas desses drivers com os seus kernels.

Os drivers LIS estão constantemente a ser atualizados no kernel principal com correções e novas funcionalidades. Sempre que possível, recomendamos executar uma distribuição endossada que inclua estas correções e atualizações.

Se estiver a usar uma variante do RHEL, nas versões 6.0 a 6.3, tem de instalar os drivers LIS mais recentes para Hyper-V. A partir do RHEL 6.4+ (e derivados), os drivers LIS já estão incluídos no kernel, por isso não precisas de pacotes de instalação adicionais.

Se for necessário um kernel personalizado, recomendamos uma versão recente do kernel (como a 3.8+). Para distribuições ou fornecedores que mantêm o seu próprio kernel, é necessário retroportar regularmente os controladores LIS do kernel principal para o seu kernel personalizado.

Mesmo que já esteja a usar uma versão do kernel relativamente recente, recomendamos vivamente que acompanhe eventuais correções introduzidas a montante nos controladores LIS e as retroporte conforme necessário. As localizações dos ficheiros fonte do driver LIS são especificadas no ficheiro MAINTAINERS na árvore de código-fonte do 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/

O kernel ativo da VM deve incluir os seguintes patches. Esta lista não pode estar completa para todas as distribuições.

• ata_piix: transfere os discos para os drivers de Hyper-V por defeito
• storvsc: Contabilizar os pacotes em trânsito no caminho RESET
• STORVSC: Evite o uso de WRITE_SAME
• storvsc: Desative o WRITE SAME para RAID e drivers do adaptador de host virtual
• storvsc: correcção de desreferência do ponteiro NULL
• STORVSC: Falhas do anel buffer podem resultar em congelamento de I/O
• scsi_sysfs: proteger contra a dupla execução de __scsi_remove_device

Agente Linux do Azure

O Azure Linux Agent (waagent) prevê uma máquina virtual Linux em Azure. Pode obter a versão mais recente, reportar problemas ou submeter pull requests no Linux Agent GitHub repositório.

Aqui estão algumas considerações para usar o Azure Linux Agent:

• O agente Linux é lançado sob a licença Apache 2.0. Muitas distribuições já fornecem pacotes .rpm ou .deb para o agente. Pode instalar e atualizar facilmente estes pacotes.
• O Azure Linux Agent requer Python v2.6+.
• O agente também necessita do python-pyasn1 módulo. A maioria das distribuições fornece este módulo como um pacote separado para ser instalado.
• Em alguns casos, o Azure Linux Agent pode não ser compatível com o NetworkManager. Muitos dos pacotes (.rpm ou .deb) fornecidos pelas distribuições configuram o NetworkManager como um conflito com o waagent pacote. Nestes casos, o agente desinstala o NetworkManager quando instala o pacote do agente Linux.
• O Azure Linux Agent deve estar igual ou acima da versão mínima suportada.

Requisitos gerais do sistema Linux

1. Modifique a linha de inicialização do kernel no GRUB ou GRUB2 para incluir os seguintes parâmetros, para que todas as mensagens do console sejam enviadas para a primeira porta serial. Estas mensagens podem ajudar o suporte do Azure a depurar quaisquer problemas.

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

   Recomendamos também a remoção dos seguintes parâmetros, caso existam:

   rhgb quiet crashkernel=auto
   

   O arranque gráfico e silencioso não são úteis num ambiente na cloud, onde queres que todos os registos sejam enviados para a porta serial. Pode deixar a crashkernel opção configurada se necessário, mas este parâmetro reduz a quantidade de memória disponível na VM em pelo menos 128 MB. Reduzir a memória disponível pode ser problemático para VMs de tamanhos mais pequenos.

2. Depois de terminares de editar /etc/default/grub, reconstrói a configuração do GRUB. Executa apenas o comando apropriado para a tua distribuição.

   Para distribuições baseadas em Debian ou Ubuntu, execute:

   sudo update-grub
   

   Para distribuições que fornecem grub2-mkconfig, como RHEL, Oracle Linux e SUSE, execute:

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

   Nas distribuições que fornecem grub-mkconfig em vez disso, executa:

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

   O caminho de configuração do GRUB pode ser diferente para instalações UEFI. Se a sua distribuição usar outro caminho, use o caminho documentado para essa distribuição.

3. Adicione os módulos Hyper-V ao disco RAM inicial. Execute apenas o procedimento que corresponda às ferramentas usadas pela sua distribuição.

   1. Para uma distribuição baseada em dracut, execute:

   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. Para uma distribuição que utiliza mkinitramfs, execute este procedimento em vez do procedimento de 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. Só se estiveres a criar uma imagem para um controlador remoto de disco NVMe, configura e verifica o suporte ao arranque NVMe. Caso contrário, ignore esta etapa. Os comandos exatos podem variar consoante a distribuição.

   1. Reconstrua o initramfs com os controladores NVMe, utilizando o método da sua distribuição.

      Para uma distribuição baseada em dracut, faça os drivers NVMe persistentes em futuras imagens initramfs e reconstrua os initramfs atuais:

      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
      

      Para uma distribuição baseada no initramfs-tools, torne os controladores NVMe persistentes e reconstrua o initramfs:

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

   2. Adicione nvme_core.io_timeout=240 à linha de comandos existente do kernel em /etc/default/grub, e depois reconstrua a configuração GRUB usando o comando apropriado para a sua distribuição.

   3. Verifique se ambos os módulos de driver NVMe estão disponíveis no sistema. Execute ambos os comandos:

      modinfo nvme
      modinfo nvme_core
      

      Cada comando deve devolver informações sobre o seu módulo. Se nenhum dos módulos for encontrado, instale-o ou ative-o seguindo a documentação da sua distribuição antes de continuar.

   4. Verifique se ambos os drivers NVMe estão incluídos no initramfs. Executa apenas o comando da tua distribuição.

      Para uma distribuição baseada em dracut, execute:

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

      Para uma distribuição baseada em ferramentas initramfs, execute:

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

      A saída deve mostrar tanto o driver nvme como o nvme_core. Se não acontecer, consulte a documentação da sua distribuição e reconstrói o disco RAM inicial antes de continuar.

5. Certifique-se de que o servidor SSH está instalado e configurado para iniciar no momento da inicialização. Esta configuração é geralmente a padrão.

6. Instala o Azure Linux Agent.

   O Azure Linux Agent é necessário para provisionar uma imagem Linux no Azure. Muitas distribuições fornecem o agente como um pacote .rpm ou .deb. O pacote é normalmente chamado WALinuxAgent ou walinuxagent. Também pode instalar o agente manualmente seguindo os passos do guia Azure Linux Agent.

   Note

   Certifica-te de que os udf módulos e vfat estão ativados. Removê-los ou desativá-los pode causar uma falha de provisionamento ou de arranque. A versão 21.2 ou posterior do cloud-init remove o requisito UDF.

   Instale o Azure Linux Agent, o cloud-init e outras utilidades necessárias. Executa apenas o comando do gestor de pacotes disponível no teu sistema.

   Para dnf, executa:

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

   Se o seu sistema fornecer yum em vez de dnf, substituir dnf por yum no comando anterior.

   Para apt, executa:

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

   Para zypper, executa:

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

   Depois ativa o agente e o cloud-init em todas as distribuições:

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

7. Não cries espaço de troca no disco do sistema operativo.

   Podes usar o Azure Linux Agent ou o cloud-init para configurar swap space através do disco de recurso local. O Azure associa este disco de recurso à VM após o provisionamento. O disco de recurso local é temporário e pode ser esvaziado quando a VM é desprovisionada.

   Importante

   Estas instruções aplicam-se quer o controlador remoto de disco seja SCSI ou NVMe. Exigem um tamanho de VM que inclua um disco de recurso temporário local. O tipo de controlador remoto de disco não determina se um disco de recurso está disponível.

   1. Escolha e configure um método para gerir o espaço de troca.

      Para usar o Azure Linux Agent, modifique os seguintes parâmetros em /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.
      

      Para usar cloud-init em vez disso, configure o cloud-init para gerir o provisionamento e impedir que o Azure Linux Agent formate o disco de recurso ou crie espaço de troca:

      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 escolheste cloud-init, escolhe como fornecer a configuração de swap.

      Pode fornecer uma configuração de cloud-init através de customdata sempre que criar uma VM. Use este método.

      Alternativamente, adicione uma diretiva cloud-init à imagem para que o espaço de swap seja configurado sempre que uma VM é criada. Para usar este método, crie um ficheiro .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. Configure o cloud-init para gerir o provisionamento:

   1. Configurar waagent para 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 estiveres a migrar uma máquina virtual específica e não quiseres criar uma imagem generalizada, define Provisioning.Agent=disabled a configuração /etc/waagent.conf .

   2. Configurar pontos de montagem:

      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. Configure a fonte de dados do 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. Remova o ficheiro de swap existente se tiver configurado um:

      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. Configure o registo do 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. Valida a configuração de montagem do disco antes de desprovisionares a máquina virtual. Esta validação aplica-se tanto a imagens SCSI como remotas NVMe.

   1. Reveja /etc/fstab. Não use nomes de dispositivos como /dev/sd* ou /dev/nvme*, porque os nomes dos dispositivos podem mudar durante reinicios ou quando o controlador de disco muda. Use UUIDs do sistema de ficheiros ou outros identificadores persistentes em vez disso.

      Liste os dispositivos de bloco e os seus identificadores persistentes para que possa compará-los com as entradas em /etc/fstab:

      sudo blkid
      

   2. Verifique /etc/fstab para ver se existem erros de sintaxe, opções de montagem inválidas e referências que não podem ser resolvidas:

      sudo findmnt --verify --verbose
      

   3. Só se estiveres a criar uma imagem para um controlador de disco NVMe remoto, verifica o timeout de I/O configurado. Se a VM de origem usar atualmente NVMe, execute:

      cat /sys/module/nvme_core/parameters/io_timeout
      

      O valor deve ser 240. Uma VM de origem SCSI pode não expor este parâmetro de runtime; nesse caso, verifique se nvme_core.io_timeout=240 está presente na configuração GRUB e se a configuração reconstruída o contém.

10. Execute os seguintes comandos para desprovisionar a máquina virtual.

    Atenção

    Se estás a migrar uma máquina virtual específica e não quiseres criar uma imagem generalizada, salta a etapa de desprovisionamento. Executar o comando waagent -force -deprovision+user torna a máquina de origem inutilizável. Esta etapa destina-se apenas a criar uma imagem generalizada.

    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
    

    No VirtualBox, pode aparecer uma mensagem de erro após a execução waagent -force -deprovision que diz [Errno 5] Input/output error. Esta mensagem de erro não é crítica e pode ignorá-la.

11. Desliga a máquina virtual e carrega o VHD para o Azure.

Passos seguintes

Crie uma VM Linux a partir de um disco personalizado usando o CLI do Azure

Para uma VM Azure existente que precisa de passar de SCSI para NVMe, use Convert VMs Linux e Windows de SCSI para NVMe. Para informações sobre arquitetura e suporte, consulte a visão geral do NVMe.