Información sobre distribuciones admitidas y no aprobadas por la comunidad

Se aplica a: ✔️ máquinas virtuales Linux ✔️ conjuntos de escalado flexibles

El Acuerdo de Nivel de Servicio de la plataforma Azure se aplica a máquinas virtuales que ejecutan el SO Linux solo cuando cuentan con una de las distribuciones aprobadas. En estas distribuciones aprobadas, las imágenes de Linux preconfiguradas se proporcionan en Azure Marketplace.

Todas las demás distribuciones, que no son de Azure Marketplace, que se ejecutan en Azure tienen una serie de requisitos previos. Este artículo no puede ser completo, dado que todas las distribuciones son diferentes. Incluso si cumple todos los criterios siguientes, puede que tenga que ajustar significativamente el sistema Linux para que se ejecute correctamente.

Este artículo se centra en ofrecer orientaciones generales para ejecutar su distribución de Linux en Azure.

Notas generales sobre la instalación de Linux

  1. No se admite el formato de disco duro virtual de Hyper-V (VHDX) en Azure, solo VHD fijo. Puede convertir el disco al formato VHD con el Administrador de Hyper-V o el cmdlet Convert-VHD. Si usa VirtualBox, deberá seleccionar Tamaño fijo en lugar del tamaño predeterminado (asignado dinámicamente) al crear el disco.

  2. Azure admite máquinas virtuales de Gen1 (arranque del BIOS) y Gen2 (arranque UEFI).

  3. El tamaño máximo permitido para los discos duros virtuales es de 1023 GB.

  4. Al instalar el sistema Linux, se recomienda usar las particiones estándar en lugar del Administrador de volúmenes lógicos (LVM), que viene de forma predeterminada en muchas instalaciones. Usar particiones estándar impedirá que el nombre del LVM entre en conflicto con las VM clonadas, especialmente si en algún momento hace falta adjuntar un disco de SO a otra VM idéntica para solucionar problemas. LVM o RAID se pueden utilizar en discos de datos.

  5. Se requiere la compatibilidad de kernel para el montaje de sistemas de archivos UDF. Al arrancar Azure la primera vez, la configuración de aprovisionamiento se pasa a la VM Linux a través de medios con formato UDF conectados al invitado. El agente Linux de Azure debe montar el sistema de archivos UDF para leer su configuración y aprovisionar la VM.

  6. Las versiones de kernel de Linux inferiores a la versión 2.6.37 no admiten NUMA en Hyper-V con tamaños de VM más grandes. Este problema afecta principalmente a las distribuciones anteriores que usan el kernel Red Hat 2.6.32 de canal de subida, y se ha corregido en Red Hat Enterprise Linux (RHEL) 6.6 (kernel-2.6.32-504). Los sistemas que ejecutan kernels personalizados cuyas versiones son anteriores a la versión 2.6.37, o bien kernels basados en RHEL cuyas versiones son anteriores a la versión 2.6.32-504, deben establecer el parámetro de inicio numa=off en la línea de comandos de kernel en grub.conf. Para más información, consulte Red Hat KB 436883.

  7. No configure una partición de intercambio en el disco del SO. El agente de Linux se puede configurar para crear un archivo de intercambio en el disco de recursos temporal, como se describe en los pasos siguientes.

  8. En Azure, todos los discos duros virtuales deben tener un tamaño virtual alineado con 1 MB (1024×1024 bytes). Al convertir un disco sin formato en un disco duro virtual, tiene que asegurarse de que su tamaño sea un múltiplo de 1 MB antes de la conversión, como se describe en los pasos siguientes.

  9. Use la versión de distribución, los paquetes y el software más actualizados.

  10. Quite los usuarios y cuentas del sistema, claves públicas, datos sensibles, software y aplicaciones innecesarias.

Instalación de los módulos de kernel sin Hyper-V

Azure se ejecuta en el hipervisor de Hyper-V, por lo que Linux requiere que ciertos módulos del kernel se ejecuten en Azure. Si tiene una VM que se ha creado fuera de Hyper-V, los instaladores de Linux pueden no incluir los controladores de Hyper-V en el disco RAM inicial (initrd o initramfs), a menos que la VM detecte que se está ejecutando en un entorno de Hyper-V. Cuando use otro sistema de virtualización (es decir, VirtualBox, KVM, etc.) para preparar la imagen de Linux, es posible que necesite recompilar el initrd para que al menos los módulos de kernel hv_vmbus y hv_storvsc estén disponibles en el disco RAM inicial. Esto es un problema conocido en sistemas basados en el nivel superior de distribución de Red Hat y, posiblemente en otros.

El mecanismo para volver a generar la imagen initrd o initramfs puede variar dependiendo de la distribución. Consulte la documentación de distribución o el soporte para conocer el procedimiento adecuado. Este es un ejemplo de cómo recompilar initrd mediante la utilidad mkinitrd:

  1. Haga una copia de seguridad de la imagen initrd existente:

    cd /boot
    sudo cp initrd-`uname -r`.img  initrd-`uname -r`.img.bak
    
  2. Vuelva a generar initrd con los módulos de kernel hv_vmbus y hv_storvsc:

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

Cambio de tamaño de los discos duros virtuales

Las imágenes VHD en Azure deben tener un tamaño virtual alineado con 1 MB. Normalmente, los discos duros virtuales creados con Hyper-V se alinean correctamente. Si el disco duro virtual no está alineado correctamente, recibirá un mensaje de error similar al siguiente cuando intente crear una imagen desde el disco duro virtual.

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

En este caso, puede cambiar el tamaño de la VM mediante la consola de administrador de Hyper-V o el del cmdlet de PowerShell Resize-VHD. Si no está trabajando en un entorno de Windows, se recomienda usar qemu-img para convertir (si es necesario) y cambiar el tamaño del disco duro virtual.

Nota

Hay un problema conocido en versiones posteriores o iguales a 2.2.1 de qemu-img que da como resultado un VHD con formato incorrecto. El problema se corrigió en QEMU 2.6. Se recomienda usar qemu-img 2.2.0 o inferior, o 2.6 o superior.

  1. Cambiar el tamaño del disco duro virtual directamente mediante herramientas como qemu-img o vbox-manage puede dar como resultado un disco duro virtual que no puede arrancar. Se recomienda convertir primero el VHD a una imagen de disco sin procesar. Si la imagen de la VM se ha creado como imagen de disco sin procesar (el valor predeterminado para algunos hipervisores, como KVM), puede omitir este paso.

    qemu-img convert -f vpc -O raw MyLinuxVM.vhd MyLinuxVM.raw
    
  2. Calcule el tamaño necesario de la imagen de disco para que el tamaño virtual esté alineado con 1 MB. El siguiente script de shell de Bash usa qemu-img info para determinar el tamaño virtual de la imagen de disco y, después, calcula el tamaño con el bloque de 1 MB siguiente.

    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. Cambie el tamaño del disco sin procesar con $rounded_size, como se estableció anteriormente.

    qemu-img resize MyLinuxVM.raw $rounded_size
    
  4. Ahora, convierta el disco sin procesar a un VHD de tamaño fijo.

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

    O bien, con la versión de qemu 2.6 o posterior, incluya la opción force_size.

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

Requisitos para el kernel de Linux

Los controladores de los Servicios de integración de Linux (LIS) para Hyper-V y Azure contribuyen directamente en el kernel de Linux del canal de subida. Muchas de las distribuciones que incluyen una versión reciente del kernel de Linux (como 3.x) ya tienen estos controladores disponibles, o de lo contrario ofrecerán versiones con modificaciones de versiones anteriores de estos controladores con sus kernels. Estos controladores se actualizan constantemente en el kernel del canal de subida con nuevas correcciones y características; por ello, se recomienda cuando sea posible la ejecución de una distribución aprobada que incluya estas correcciones y actualizaciones.

Si ejecuta una variante de las versiones de 6.0 a 6.3 de Red Hat Enterprise Linux, tendrá que instalar los controladores de LIS más recientes para Hyper-V. A partir de RHEL 6.4+ (y derivados), los controladores de LIS ya se incluyen con el kernel; por tanto, no se necesitan paquetes de instalación adicionales.

Si se requiere un kernel personalizado, se recomienda usar una versión de kernel más reciente (por ejemplo, 3.8+). En el caso de las distribuciones o los proveedores que mantienen su propio kernel, tendrá que modificar los controladores de LIS con una versión más antigua del kernel del canal de subida al kernel personalizado. Incluso si ya ejecuta una versión de kernel relativamente reciente, es altamente recomendable mantenerse al tanto de las correcciones ascendentes de los controladores de LIS y realizar modificaciones con versiones anteriores en estos cuando sea necesario. Las ubicaciones de los archivos de origen de controladores de LIS se especifican en el archivo MAINTAINERS del árbol de origen del kernel de 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/

Las revisiones siguientes deben incluirse en el kernel. Esta lista no puede ser completa para todas las distribuciones.

el Agente de Linux de Azure

El agente de Linux de Azurewaagent aprovisiona una máquina virtual Linux en Azure. Puede obtener la versión más reciente, dejar constancia de problemas o enviar solicitudes de extracción en el repositorio GitHub del agente de Linux.

  • El agente de Linux se publica bajo licencia Apache 2.0. Muchas distribuciones ya proporcionan paquetes RPM o .deb para el agente, que se pueden instalar y actualizar con facilidad.
  • El agente de Linux de Azure requiere Python v2.6+.
  • El agente requiere también el módulo python-pyasn1. La mayoría de las distribuciones proporcionan este módulo como paquete independiente que se puede instalar.
  • En algunos casos, el agente de Linux de Azure puede no ser compatible con NetworkManager. Muchos de los paquetes RPM o deb proporcionados por las distribuciones configuran NetworkManager como conflicto con el paquete waagent. En estos casos, se desinstalará NetworkManager al instalar el paquete del agente de Linux.
  • El agente de Linux de Azure debe ser igual o mayor que la versión mínima admitida.

Nota

Asegúrese de que los módulos "udf" (cloud-init >= 21.2) y "vfat" están habilitados. La creación de una lista de bloqueo del módulo udf provocará un error de aprovisionamiento y la creación de una lista de servidores back-list provocará errores de aprovisionamiento y arranque. Cloud-init 21.2 no se ve afectado y no requiere este cambio.

Requisitos generales del sistema Linux

  1. Modifique la línea de arranque de kernel en GRUB o GRUB2 para incluir los siguientes parámetros, de modo que todos los mensajes de la consola se envíen al primer puerto serie. Estos mensajes pueden ayudar al soporte técnico de Azure con la depuración de problemas.

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

    También se recomienda quitar los parámetros siguientes, si existen.

    rhgb quiet crashkernel=auto
    

    Los arranques gráfico y silencioso no resultan útiles en un entorno de nube, donde se quiere que todos los registros se envíen al puerto serie. Es posible dejar la opción crashkernel configurada si es necesario, pero tenga en cuenta que este parámetro reducirá la cantidad de memoria disponible en la VM, al menos, en 128 MB, lo cual puede resultar problemático en tamaños de VM más reducidos.

  2. Después de editar "/etc/default/grub", ejecute el comando siguiente para volver a compilar la configuración de grub:

    sudo grub2-mkconfig -o /boot/grub2/grub.cfg
    
  3. Agregue módulos de Hyper-V tanto initrd como initramfs (Dracut).

  4. Recompilar initrd o initramfs Initramfs

    cp /boot/initramfs-$(uname -r).img /boot/initramfs-[latest kernel version ].img.bak 
    dracut -f -v /boot/initramfs-[latest kernel version ].img  [depending on the version of grub] 
    grub-mkconfig -o /boot/grub/grub.cfg 
    grub2-mkconfig -o /boot/grub2/grub.cfg 
    

    Initrd

    mv /boot/[initrd kernel] /boot/[initrd kernel]-old 
    mkinitrd /boot/initrd.img-[initrd kernel]-generic /boot/[initrd kernel]-generic-old 
    update-initramfs -c -k [initrd kernel] 
    update-grub 
    
  5. Asegúrese de que el servidor SSH se haya instalado y configurado para iniciarse en el tiempo de arranque. Esta configuración suele ser la predeterminada.

  6. Instale el Agente de Linux de Azure. El agente de Linux de Azure se requiere para aprovisionar una imagen de Linux en Azure. Muchas distribuciones proporcionan el agente como paquete RPM o .deb (el paquete suele llamarse WALinuxAgent o walinuxagent). El agente también se puede instalar manualmente siguiendo los pasos de la Guía del agente de Linux.

    Ejecute el comando siguiente para instalar el agente de Linux de Azure, cloud-init y otras utilidades necesarias:

    Redhat/Centos

    sudo yum install -y [waagent] cloud-init cloud-utils-growpart gdisk hyperv-daemons
    

    Ubuntu/Debian

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

    Suse

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

    A continuación, activar el agente y cloud-init en todas las distribuciones mediante:

    sudo systemctl enable waagent.service
    sudo systemctl enable cloud-init.service
    
  7. No cree un espacio de intercambio en el disco del sistema operativo. El Agente de Linux de Azure puede configurar automáticamente un espacio de intercambio utilizando el disco de recursos local que se adjunta a la máquina virtual después de aprovisionarse en Azure. El disco de recursos local es un disco temporal que podría tener que vaciarse cuando la máquina virtual se desaprovisiona. Después de instalar el agente de Linux de Azure, modifique los parámetros siguientes en /etc/waagent.conf según sea necesario.

    ResourceDisk.Format=y
    ResourceDisk.Filesystem=ext4
    ResourceDisk.MountPoint=/mnt/resource
    ResourceDisk.EnableSwap=y
    ResourceDisk.SwapSizeMB=2048    ## NOTE: Set this to your desired size.
    
  8. Configure cloud-init para administrar el aprovisionamiento:

    1. Configure waagent para cloud-init:
      sed -i 's/Provisioning.Agent=auto/Provisioning.Agent=cloud-init/g' /etc/waagent.conf
      sed -i 's/ResourceDisk.Format=y/ResourceDisk.Format=n/g' /etc/waagent.conf
      sed -i 's/ResourceDisk.EnableSwap=y/ResourceDisk.EnableSwap=n/g' /etc/waagent.conf
      
      Si va a migrar una máquina virtual concreta y no quiere crear una imagen generalizada, establezca Provisioning.Agent=disabled en la configuración de /etc/waagent.conf.
    2. Configure montajes:
      echo "Adding mounts and disk_setup to init stage"
      sed -i '/ - mounts/d' /etc/cloud/cloud.cfg
      sed -i '/ - disk_setup/d' /etc/cloud/cloud.cfg
      sed -i '/cloud_init_modules/a\\ - mounts' /etc/cloud/cloud.cfg
      sed -i '/cloud_init_modules/a\\ - disk_setup' /etc/cloud/cloud.cfg
      
    3. Configure el origen de datos de Azure:
      echo "Allow only Azure datasource, disable fetching network setting via IMDS"
      cat > /etc/cloud/cloud.cfg.d/91-azure_datasource.cfg <<EOF
      datasource_list: [ Azure ]
      datasource:
         Azure:
           apply_network_config: False
      EOF
      
    4. Si está configurado, quite el archivo de intercambio existente:
      if [[ -f /mnt/resource/swapfile ]]; then
      echo "Removing swapfile" #RHEL uses a swapfile by defaul
      swapoff /mnt/resource/swapfile
      rm /mnt/resource/swapfile -f
      fi
      
  9. Configure el registro de cloud-init:

    echo "Add console log file"
    cat >> /etc/cloud/cloud.cfg.d/05_logging.cfg <<EOF
    
    # 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
    
  10. Configuración de intercambio No cree espacio de intercambio en el disco del sistema operativo. Anteriormente, el agente de Linux de Azure configuraba automáticamente un espacio de intercambio mediante el disco de recursos local que se adjunta a la máquina virtual, después de que la máquina virtual se aprovisione en Azure. Ahora, en cambio, esto se administra mediante cloud-init; no tiene que usar el agente de Linux para formatear el disco de recursos, crear el archivo de intercambio y modificar los parámetros siguientes en /etc/waagent.conf adecuadamente:

    ResourceDisk.Format=n
    ResourceDisk.EnableSwap=n
    

    Si desea montar, formatear y crear intercambio, puede: 1. Pase esto como una configuración de cloud-init cada vez que cree una máquina virtual a través de customdata. Éste es el método recomendado. 2. Use una directiva de cloud-init preparada en la imagen que hará esto cada vez que se cree la máquina virtual.

           echo 'DefaultEnvironment="CLOUD_CFG=/etc/cloud/cloud.cfg.d/00-azure-swap.cfg"' >> /etc/systemd/system.conf
           cat > /etc/cloud/cloud.cfg.d/00-azure-swap.cfg << EOF
           #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
    
         ```
    
    
  11. Desaprovisionar

    Precaución

    Si va a migrar una máquina virtual concreta y no desea crear una imagen generalizada, omita el paso de desaprovisionamiento. Al ejecutar el comando waagent -force -deprovision+user, la máquina de origen no se podrá usar; este paso está pensado únicamente para crear una imagen generalizada.

    Ejecute los comandos siguientes para desaprovisionar la máquina virtual.

    # sudo rm -f /var/log/waagent.log
    # sudo cloud-init clean
    # waagent -force -deprovision+user
    # rm -f ~/.bash_history
    # export HISTSIZE=0
    # logout
    

    Nota

    Es posible que en VirtualBox aparezca el siguiente error [Errno 5] Input/output error después de ejecutar waagent -force -deprovision. Este mensaje de error no es crítico, por lo que se puede omitir.

  12. Apague la máquina virtual y cargue el disco duro virtual en Azure.

Pasos siguientes

Creación de una VM Linux desde un disco personalizado con la CLI de Azure.