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:
- Distribuciones de Linux aprobadas en Azure
- Soporte técnico para Linux y la tecnología de código abierto en Azure
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
:
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 mediante los módulos de kernel
hv_vmbus
yhv_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.
Cambiar el tamaño del disco duro virtual directamente mediante herramientas como
qemu-img
ovbox-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
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"
Cambie el tamaño del disco sin formato mediante
$rounded_size
:sudo qemu-img resize MyLinuxVM.raw $rounded_size
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.
- ata_piix: Aplazar discos a los controladores de Hyper-V de manera predeterminada
- storvsc: cuenta para paquetes en tránsito en la ruta de RESET
- storvsc: Evitar el uso de WRITE_SAME
- storvsc: deshabilita WRITE SAME para RAID y controladores del adaptador de host virtual
- storvsc: corrección de desreferenciación del puntero nulo
- storvsc: Los errores de búfer de anillo pueden dar lugar a una inmovilización de E/S
- scsi_sysfs: Protección contra la ejecución doble de __scsi_remove_device
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
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.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
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
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 al agente como un paquete .rpm o .deb. Normalmente, el paquete se denomina
WALinuxAgent
owalinuxagent
. 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
yvfat
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
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
- Pase una configuración de cloud-init cada vez que cree una máquina virtual a través de
Configure cloud-init para administrar el aprovisionamiento:
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.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
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
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
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
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.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