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

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 el VHD es de 1.023 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 más antiguas que utilizan el kernel original de Red Hat 2.6.32. 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 un disco sin formato a VHD, asegúrese de que el tamaño del disco sin formato sea un múltiplo de 1 MB antes de convertirlo, 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.

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 reconstruir initrd utilizando 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`
   

Redimensionar VHD

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 máquina virtual mediante la consola del Administrador de Hyper-V o el 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.

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. Recomendamos convertir primero el VHD en una imagen de disco en formato raw con 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 se integran directamente en el kernel principal de Linux. Muchas distribuciones que incluyen una versión reciente del kernel de Linux (como la 3.x) ya disponen de estos controladores o, en su defecto, proporcionan versiones retroportadas de estos controladores con sus kernels.

Los controladores LIS se actualizan constantemente en el kernel principal con nuevas correcciones y funciones. 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 usa una versión del kernel relativamente reciente, le recomendamos encarecidamente que se mantenga al tanto de las correcciones introducidas en upstream en los controladores LIS y que las retroporte 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: dejar los discos en manos de los controladores de Hyper-V de forma 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 fallos del búfer circular pueden provocar el bloqueo de la 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.

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 a depurar cualquier problema.

   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, recompile la configuración de GRUB. Ejecute solo el comando adecuado para la distribución.

   Para distribuciones basadas en Debian o Ubuntu, ejecute:

   sudo update-grub
   

   Para las distribuciones que proporcionan grub2-mkconfig, como RHEL, Oracle Linux y SUSE, ejecute:

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

   En las distribuciones que proporcionan grub-mkconfig en su lugar, ejecute:

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

   La ruta de configuración de GRUB puede diferir para las instalaciones UEFI. Si la distribución usa otra ruta de acceso, use la ruta de acceso documentada para esa distribución.

3. Agregue los módulos Hyper-V al disco ram inicial. Ejecute solo el procedimiento que corresponda a las herramientas que utilice su distribución.

   1. Para una distribución basada en dracut, ejecute:

   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 una distribución que usa mkinitramfs, ejecute este procedimiento en lugar del procedimiento 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. Solo si va a crear una imagen para un controlador de disco NVMe remoto, configure y compruebe la compatibilidad con el arranque nvMe. De lo contrario, omita este paso. Los comandos exactos pueden variar según la distribución.

   1. Reconstruya la initramfs con los controladores NVMe utilizando el método correspondiente a su distribución.

      Para una distribución basada en dracut, configure los controladores NVMe para que permanezcan en futuras imágenes de initramfs y reconstruya el initramfs actual:

      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 una distribución basada en initramfs-tools, haga que los controladores NVMe sean persistentes y recompilen initramfs:

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

   2. Agregue nvme_core.io_timeout=240 a la línea de comandos del kernel existente en /etc/default/gruby vuelva a generar la configuración de GRUB mediante el comando adecuado para la distribución.

   3. Compruebe que ambos módulos del controlador NVMe están disponibles en el sistema. Ejecute ambos comandos:

      modinfo nvme
      modinfo nvme_core
      

      Cada comando debe devolver información sobre su módulo. Si no se encuentra alguno de los módulos, instálelo o habilitelo siguiendo la documentación de la distribución antes de continuar.

   4. Compruebe que ambos controladores NVMe se incluyen en initramfs. Ejecute solo el comando correspondiente a su distribución.

      Para una distribución basada en dracut, ejecute:

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

      Para una distribución basada en initramfs-tools, ejecute:

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

      La salida debe mostrar tanto los controladores nvme como los controladores nvme_core. Si no es así, consulte la documentación de la distribución y recompile el disco RAM inicial antes de continuar.

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 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. La versión 21.2 de Cloud-init o posteriores elimina el requisito de UDF.

   Instale el agente de Linux de Azure, cloud-init y otras utilidades necesarias. Ejecute solo el comando para el administrador de paquetes disponible en el sistema.

   Para dnf, ejecute:

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

   Si el sistema proporciona yum en lugar de dnf, reemplace por dnfyum en el comando anterior.

   Para apt, ejecute:

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

   Para zypper, ejecute:

   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
   

7. 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. Azure asocia este disco de recursos a la máquina virtual después del aprovisionamiento. El disco de recursos local es temporal y puede vaciarse cuando se desaprovisiona la máquina virtual.

   Importante

   Estas instrucciones se aplican si el controlador de disco remoto es SCSI o NVMe. Requieren un tamaño de máquina virtual que incluya un disco de recursos temporal local. El tipo de controlador de disco remoto no determina si hay un disco de recursos disponible.

   1. Elija y configure un método para administrar el espacio de intercambio.

      Para usar el 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.
      

      Para usar cloud-init en su lugar, configure cloud-init para controlar el aprovisionamiento y evitar que el agente de Linux de Azure aplique formato al disco de recursos o cree espacio de intercambio:

      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. Si eligió cloud-init, elija cómo proporcionar la configuración de intercambio.

      Puede pasar una configuración de cloud-init a través de customdata cada vez que cree una máquina virtual. Use este método.

      Como alternativa, agregue una directiva cloud-init a la imagen para que el espacio de intercambio esté configurado cada vez que se cree una máquina virtual. Para usar este método, cree un archivo .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 cloud-init para administrar el aprovisionamiento:

   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
      

      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. Configurar puntos de montaje:

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

9. Valide la configuración de montaje del disco antes de desaprovisionar la máquina virtual. Esta validación se aplica tanto a imágenes SCSI como a NVMe remotas.

   1. Revise /etc/fstab. No use nombres de dispositivo como /dev/sd* o /dev/nvme*, ya que los nombres de dispositivo pueden cambiar entre reinicios o cuando cambia el controlador de disco. En su lugar, use UUID del sistema de archivos u otros identificadores persistentes.

      Enumere los dispositivos de bloqueo y sus identificadores persistentes para poder compararlos con las entradas de /etc/fstab:

      sudo blkid
      

   2. Compruebe /etc/fstab si hay errores de sintaxis, opciones de montaje no válidas y referencias que no se pueden resolver:

      sudo findmnt --verify --verbose
      

   3. Solo si va a crear una imagen para un controlador de disco NVMe remoto, compruebe el tiempo de espera de E/S configurado. Si la máquina virtual de origen actualmente usa NVMe, ejecute:

      cat /sys/module/nvme_core/parameters/io_timeout
      

      El valor tiene que ser 240. Es posible que una máquina virtual de origen SCSI no exponga este parámetro en tiempo de ejecución; en ese caso, compruebe que nvme_core.io_timeout=240 está presente en la configuración de GRUB y que la configuración recompilada la contiene.

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

11. Apague la máquina virtual y cargue el VHD a Azure.

Pasos siguientes

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

Para una máquina virtual de Azure existente que necesita migrar de SCSI a NVMe, use Convertir máquinas virtuales Linux y Windows de SCSI a NVMe. Para obtener información sobre arquitectura y soporte técnico, consulte Introducción a NVMe.