Compartir vía


Preparación de Linux para la creación de imágenes en Azure

Precaución

En este artículo se hace referencia a CentOS, una distribución de Linux con un estado de finalización del servicio (EOL). Tenga en cuenta su uso y planifique en consecuencia. Para obtener más información, consulte la guía de fin de vida de CentOS.

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

El acuerdo de nivel de servicio (SLA) de la plataforma Azure se aplica a las máquinas virtuales (VM) que ejecutan el sistema operativo Linux solo cuando se usa una de las distribuciones aprobadas. En el caso de las distribuciones aprobadas, Azure Marketplace proporciona imágenes Linux configuradas previamente. Para más información, consulte:

Todas las demás distribuciones que se ejecutan en Azure, incluidas las distribuciones admitidas por la comunidad y no aprobadas, tienen algunos requisitos previos.

Este artículo se centra en ofrecer orientaciones generales para ejecutar su distribución de Linux en Azure. Este artículo no puede ser completo porque todas las distribuciones son diferentes. Incluso si cumple todos los criterios que describe este artículo, es posible que tenga que ajustar significativamente el sistema Linux para que se ejecute correctamente.

Notas generales sobre la instalación de Linux

  • Azure no admite el formato del disco duro virtual de Hyper-V. Azure solo admite VHD fijo. Puede convertir el disco al formato VHD mediante el Administrador de Hyper-V o el cmdlet Convert-VHD. Si usa VirtualBox, seleccione tamaño fijo en lugar del valor predeterminado (asignado dinámicamente) al crear el disco.

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

  • El módulo del kernel de la tabla de asignación de archivos virtuales (VFAT) debe estar habilitado en el kernel.

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

  • Al instalar el sistema Linux, se recomienda usar las particiones estándar en lugar del Administrador de volúmenes lógicos (LVM). LMV es el valor predeterminado para 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. Puede usar LVM o RAID en discos de datos.

  • Se requiere la compatibilidad de kernel para el montaje de sistemas de archivos de función definida por el usuario (UDF). Al arrancar Azure la primera vez, la configuración de aprovisionamiento se pasa a la máquina virtual 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.

  • Las versiones del kernel de Linux anteriores a la 2.6.37 no admiten el acceso a memoria no uniforme (NUMA) en Hyper-V con tamaños de máquina virtual más grandes. Este problema afecta principalmente a las distribuciones anteriores que usan el kernel de Red Hat 2.6.32 de canal de subida. Se corrigió 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.

  • No configure una partición de intercambio en el disco del SO. Es posible configurar el agente de Linux para crear un archivo de intercambio en el disco de recursos temporal, como se describe más adelante en este artículo.

  • En Azure, todos los discos duros virtuales deben tener un tamaño virtual alineado con 1 MB (1024 x 1024 bytes). Al convertir de un disco sin formato a VHD, asegúrese de que su tamaño sea un múltiplo de 1 MB antes de la conversión, como se describe más adelante en este artículo.

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

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

Nota:

Cloud-init versión 21.2 o posterior quita el requisito de UDF. Pero sin el módulo udf habilitado, el CD-ROM no se montará durante el aprovisionamiento, lo que impide que se apliquen los datos personalizados. Una solución alternativa consiste en aplicar datos de usuario. Sin embargo, a diferencia de los datos personalizados, los datos de usuario no se cifran. Para obtener más información, consulte Formatos de datos de usuario en la documentación de cloud-init.

Instalación de 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 máquina virtual que se ha creado fuera de Hyper-V, es posible que los instaladores de Linux no incluyan los controladores de Hyper-V en el disco RAM inicial (initrd o initramfs), a menos que la máquina virtual detecte que se ejecuta en un entorno de Hyper-V.

Al usar un sistema de virtualización diferente (como VirtualBox o KVM) para preparar la imagen de Linux, es posible que tenga que volver a generar 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 mediante 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`
    

Cambiar el 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 mediante Hyper-V se alinean correctamente. Si el disco duro virtual no está alineado correctamente, es posible que reciba un mensaje de error similar al siguiente al intentar crear una imagen a partir del 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 error conocido en qemu-img para QEMU versión 2.2.1 y algunas versiones posteriores que producen un VHD con formato incorrecto. El problema se ha corregido en QEMU 2.6. Se recomienda usar la versión 2.2.0 o anterior, o bien usar la versión 2.6 o posterior.

  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 disco duro virtual en una imagen de disco sin formato mediante el código siguiente.

    Si la imagen de máquina virtual se creó como una imagen de disco sin procesar, puede omitir este paso. La creación de la imagen de máquina virtual como una imagen de disco sin formato es la predeterminada en algunos hipervisores, como KVM.

    sudo 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 siguiente bloque de 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. Cambie el tamaño del disco sin formato mediante $rounded_size:

    sudo qemu-img resize MyLinuxVM.raw $rounded_size
    
  4. Vuelva a convertir el disco sin procesar en un VHD de tamaño fijo:

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

    O bien, con las versiones de QEMU anteriores a la 2.6, quite la opción force_size:

    sudo qemu-img convert -f raw -o subformat=fixed -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.

Los controladores LIS se actualizan constantemente en el kernel ascendente con nuevas correcciones y características. Cuando sea posible, se recomienda ejecutar una distribución aprobada que incluya estas correcciones y actualizaciones.

Si ejecuta una variante de las versiones 6.0 a 6.3 de RHEL, debe instalar los controladores de LIS más recientes de para Hyper-V. A partir de RHEL 6.4+ (y derivados), los controladores LIS ya se incluyen con el kernel, por lo que no necesita 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, tiene 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/

El kernel activo de la máquina virtual debe incluir las revisiones siguientes. Esta lista no puede ser completa para todas las distribuciones.

Agente Linux de Azure

El agente de Linux de Azure (waagent) aprovisiona una máquina virtual Linux en Azure. Puede obtener la versión más reciente, notificar problemas o enviar solicitudes de incorporación de cambios en el repositorio GitHub del agente Linux.

Estas son algunas consideraciones para usar el agente Linux de Azure:

  • El agente de Linux se publica bajo licencia Apache 2.0. Muchas distribuciones ya proporcionan paquetes .rpm o .deb para el agente. Puede instalar y actualizar fácilmente estos paquetes.
  • 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 un conflicto con el paquete waagent . En estos casos, el agente desinstalará NetworkManager al instalar el paquete del agente 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 y vfat estén habilitados. Al deshabilitar el módulo udf se producirá un error de aprovisionamiento. Al deshabilitar el módulo vfat se producirán errores de aprovisionamiento y de arranque. Cloud-init versión 21.2 o posterior puede aprovisionar máquinas virtuales sin necesidad de UDF si existen ambas condiciones:

  • Ha creado la máquina virtual mediante claves públicas SSH y no contraseñas.
  • No proporcionó ningún dato personalizado.

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 siguientes parámetros, si existen:

    rhgb quiet crashkernel=auto
    

    El arranque gráfico y silencioso no es útil en un entorno de nube, donde desea que todos los registros se envíen al puerto serie. Puede dejar la opción crashkernel configurada si es necesario, pero este parámetro reduce la cantidad de memoria disponible en la máquina virtual al menos 128 MB. Reducir la memoria disponible podría ser problemática para tamaños de máquina virtual más pequeños.

  2. Después de terminar de editar /etc/default/grub, ejecute el siguiente comando para recompilar la configuración de GRUB:

    sudo grub2-mkconfig -o /boot/grub2/grub.cfg
    
  3. Agregue el módulo de Hyper-V para initramfs mediante 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
    

    Agregue el módulo de Hyper-V para initrd mediante 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. 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.

  5. 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 al agente como un paquete .rpm o .deb. Normalmente, el paquete se denomina WALinuxAgent o walinuxagent. También puede instalar el agente manualmente siguiendo los pasos descritos en la guía del agente Linux de Azure .

    Nota:

    Asegúrese de que los módulos udf y vfat estén habilitados. Quitarlos o deshabilitarlos provocará un error de aprovisionamiento o arranque. Cloud-init versión 21.2 o posterior quita el requisito de UDF.

    Instale el agente de Linux de Azure, cloud-init y otras utilidades necesarias mediante la ejecución de uno de los siguientes comandos.

    Use este comando para Red Hat o CentOS:

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

    Use este comando para Ubuntu o Debian:

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

    Use este comando para SUSE:

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

    A continuación, habilite el agente y cloud-init en las siguientes distribuciones:

    sudo systemctl enable waagent.service
    sudo systemctl enable cloud-init.service
    
  6. No cree un espacio de intercambio en el disco del sistema operativo.

    Puede usar el agente Linux de Azure o cloud-init para configurar el espacio de intercambio a través del disco de recursos local. Este disco de recursos se conecta a la máquina virtual después del aprovisionamiento en Azure. El disco de recursos local es un disco temporal que podría tener que vaciarse cuando la máquina virtual se desaprovisiona. Los siguientes bloques muestran cómo configurar este intercambio.

    Si elige el agente Linux de Azure, modifique los siguientes parámetros en /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.
    

    Si elige cloud-init, configúrelo para controlar el aprovisionamiento:

    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
    

    Para configurar cloud-init para dar formato y crear espacio de intercambio, tiene dos opciones:

    • Pase una configuración de cloud-init cada vez que cree una máquina virtual a través de customdata. Se recomienda este método.
    • Use una directiva cloud-init en la imagen para configurar el espacio de intercambio cada vez que se crea la máquina virtual.

    Cree un archivo .cfg para configurar el espacio de intercambio mediante 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. Configure cloud-init para administrar el aprovisionamiento:

    1. Configure 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
      

      Si va a migrar una máquina virtual específica y no desea 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"
      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 el origen de datos de 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. Quite el archivo de intercambio existente si ha configurado 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. Configure el registro de 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. Ejecute los comandos siguientes para desaprovisionar la máquina virtual.

    Precaución

    Si va a migrar una máquina virtual específica y no desea crear una imagen generalizada, omita el paso de desaprovisionamiento. La ejecución del comando waagent -force -deprovision+user hará que la máquina de origen no se pueda usar. Este paso solo está pensado para crear una imagen 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
    

    En VirtualBox, es posible que vea un mensaje de error después de ejecutar waagent -force -deprovision que indica [Errno 5] Input/output error. Este mensaje de error no es crítico y puede omitirlo.

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