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

Artículo
03/25/2023
14 minutos para leer

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

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.
Azure admite máquinas virtuales de Gen1 (arranque del BIOS) y Gen2 (arranque UEFI).
El módulo de kernel 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), 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.
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.
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.
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.
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.
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 >= 21.2 elimina el requisito de udf). Sin embargo, sin el módulo udf habilitado, el cdrom no se montará durante el aprovisionamiento, lo que impedirá que se apliquen datos personalizados. Una solución para esto sería aplicar los datos personalizados mediante los datos del usuario, sin embargo, a diferencia de los datos personalizados, los datos del usuario no están encriptados. https://cloudinit.readthedocs.io/en/latest/topics/format.html

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:

Haga una copia de seguridad de la imagen initrd existente:

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

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.

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
```
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"
```
Cambie el tamaño del disco sin procesar con $rounded_size, como se estableció anteriormente.
```
qemu-img resize MyLinuxVM.raw $rounded_size
```

Ahora, convierta el disco sin procesar a un VHD de tamaño fijo.

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

O bien, con versiones de qemu anteriores a la 2.6, quite la opción force_size.

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. 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" 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 >= 21.2 puede aprovisionar máquinas virtuales sin necesidad de UDF si: 1) la máquina virtual se creó mediante claves públicas SSH y no la contraseña y 2) no se proporcionaron datos personalizados.

Requisitos generales del sistema Linux

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.
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
```
Agregue módulos de Hyper-V tanto initrd como initramfs (Dracut).

Vuelva a compilar 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

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

Nota

Asegúrese de que los módulos "udf" y "vfat" están habilitados. La lista de bloqueados o la eliminación del módulo udf provocarán un error de aprovisionamiento. La lista de bloqueados o la eliminación del módulo vfat provocarán errores de aprovisionamiento y de arranque. (_Cloud-init >= 21.2 quita el requisito de udf. Lea la parte superior del documento para obtener más detalles).

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
```
Intercambio: no cree espacio de intercambio en el disco del sistema operativo.

El agente Linux de Azure o Cloud-init se pueden usar para configurar el espacio de intercambio mediante el 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.

Agente de Linux de Azure: modifique los parámetros siguientes 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.
```
Cloud-init: configure cloud-init para administrar el aprovisionamiento:
```
sed -i 's/Provisioning.Agent=auto/Provisioning.Agent=cloud-auto/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
```
Configure Cloud-init para crear el intercambio.

Para dar formato y crear un intercambio, tiene dos opciones:
1. Páselo 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. Usar una directiva de cloud-init preparada en la imagen que hará esto cada vez que se cree la máquina virtual.
Cree un archivo cfg para configurar el intercambio mediante Cloud-init:
```
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
```

Configure cloud-init para administrar el aprovisionamiento:

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.

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

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

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

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

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