¿Permite Azure montar SO no soportados en sus VM? Spoiler: SI!

Sitio dedicado a Microsoft Azure y otras tecnologías Cloud

Pantalla de inicio del Windows 3.11 for Worksgroups

He tenido el privilegio de impartir una semana de cursos de fundamentos en Azure con dos colegas MCT de Microsoft y, como siempre, he aprendido muchas cosas de ver el desempeño de otros profesionales de la instrucción técnica.

Sin embargo la afirmación de que «Azure no permite crear una VM con un Sistema Operativo no soportado» me rechinó en las profundidades de mis conocimientos, y me he puesto manos a la obra a ver si me estaba equivocando al considerar que esto, en la realidad, no es así.

Y de estos lodos ha salido más diversión y conocimiento del que me esperaba.

Buscando el límite

Lo primero es elegir el SO más incompatible que se me pudiera ocurrir, y que al mismo tiempo tuviera suficientes conocimientos como para poder comprobar si llegaba a montarse y funcionar de forma correcta en la máquina virtual en Azure.

¿Y quien podía ser el candidato perfecto? Un Microsoft Windows 3.11 de los años 90 del siglo pasado. (wow, suena viejísimo).

Luego me puse a analizar los pasos necesarios para crear la VM en Azure con ese sistema operativo, y tenía que definir los siguientes pasos:

  • Definir la familia y tamaño: viendo que es un 3.11, he seleccionado una A0 de la versión 1 (que están a un año de ser retiradas) por dos razones. Uno, por ser lo más pequeño que puedo seleccionar ya que para un Win 3.11 más de tres cuartos de Giga de memoria RAM es una autentica pasada. Y dos, para que le hardware físico sea el más viejo posible y evitar incompatibilidades infranqueables.
  • Crear un disco vhd con el Win 3.11, y subirlo a una cuenta de almacenamiento (no de tipo page, si no de tipo block).
  • Crear la VM diciéndole que el disco de SO es el que había almacenado en la cuenta de almacenamiento
  • Arrancar la máquina y cruzar los dedos.

Crear el VHD

Mi primera aproximación fue montar un hyper-v en mi máquina local, e instalar un Win 3.11, para luego exportar el disco duro en formato vhd. Pero una ligera búsqueda en Google me llevó a diversas páginas y canales de Youtube en donde encontrar vhd listos para hacerlos funcionar.

Una vez descargado el vhd, he lanzado el siguiente script de Powershell, que me coge el disco duro virtual, le hace «cosas», y me lo publica como un disco duro gestionado en mi suscripción de Azure

# Necesitas PowerShell en su versión 7, al menos
# Y el módulo completo de Az, en especial el Az.Compute

$path = "<el path local de tu vhd>"
$resourceGroup = "<nombre del grupo de recursos"  #tenlo creado antes de lanzar el script
$location = "northeurope" #yo uso  northeurope, pero puedes usar el que mejor te convenga

# Me conecto a Azure, y me pide las credenciales
Connect-AzAccount

# Como tengo muchas subscripciones, le indico cual quiero utilizar
Set-AzContext -Subscription "<cadena alfanumérica del identificador de la suscripción"

# La orden que hace la magia
Add-AzVhd -LocalFilePath $path -ResourceGroupName $resourceGroup -Location $location -DiskName $name

Arrancando el trabajo al mostrar un mensaje tal que así:

To be compatible with Azure, Add-AzVhd will automatically try to convert VHDX files to VHD, and resize VHD files to N * Mib using Hyper-V Platform, a Windows naitive virtualization product.
For more information visit https://aka.ms/usingAdd-AzVhd

Converting dynamically sized VHD to fixed size VHD.

Y durante unos minutos, se lio a hacer cosas hasta que, finalmente, termine con un disco duro nuevo en mi grupo de recursos.

Para más información sobre este script y sus capacidades: https://docs.microsoft.com/en-us/powershell/module/az.compute/add-azvhd?view=azps-7.3.2&viewFallbackFrom=azps-7.1.0#description

Pero… ¿funciona?

A partir de tener el disco duro gestionado, lo único que tengo que hacer es montar la máquina virtual, y arrancarla. Y aquí llega el primer problema serio de trabajar en Azure.

Las VM en Azure son contenedores del servicio de VM de Azure Service Fabric Controller, no son máquina virtuales. Por lo cual no puedo acceder a una conexión durante el arranque. Y, como el sistema operativo es tan viejo, no le puedo instalar el agente de Azure para poder utilizar la conexión serial. Es decir, no puedo acceder más que vía RDP… oh wait!!

No tengo el RDP habilitado en el Win 3.11.

¿Entonces qué puedo hacer para comprobar si me arranca el sistema operativo o no? Pues lo más que puedo hacer es mirar los pantallazos del log de inicio del propio servicio (lo siento no hice captura de pantalla).

Y veo que el MSDOS ha arrancado!!, pero que se ha quedado tonto esperando encontrar el CD-ROM. Y de aquí ya no consigo pasar, aunque la conclusión principal que he conseguido es:

«En una máquina virtual de Azure se puede instalar cualquier Sistema Operativo que arranque«, sin que Azure impida que se pueda instalar un producto no soportado.

Una comunidad viva

Por supuesto nada de esto sería tan divertido si no hubiera sido comentado en Twitter, y surgir un intercambio de comentarios e de ideas al rededor de cómo lograr el objetivo.

Carlos Milán, comparte una pasada de proyecto en dónde podremos correr los más variopintos sistemas operativos en nuestros navegadores a través de emulación construida en JavaScript.

Daniel Alvarez, nos enlaza un vídeo de Youtube en dónde nos muestran cómo hacer correr un Windows 3.11 dentro de una VM en Azure dentro de DosBox.

José Ángel Fernandez, me señala que «Todo lo que se ejecute sobre Hyper-V en on-premises se va a ejecutar en Azure. El problema es que sin los componentes de virtualización y sin el agente la experiencia será sorpresa»

Y compañeros como Daniel López o Sampy, participaron en la conversación. El último incluso se está «picando» para hacer lo mismo con un Solaris.

Sin duda, la comunidad de locos por «cacharrear» sigue muy viva!!

Conclusión

Me equivoque de Sistema Operativo, ya que no funciona en Hyper-V por varias razones fundamentales, por lo cual tampoco va a funcionar en una VM de Azure. Curiosamente un MSDOS sí que funcionaría.

El problema no es tanto que arranque, si no cómo poder acceder a la máquina. Por lo cual eso lo tengo que tener cuidadosamente preparado en el vdh que quiera publicar.

Creo que la forma más eficiente y sencilla es, como dice José Ángel, montarlo todo en una vm Hyper-V V1 en mi máquina local, y luego publicar en Azure con todo configurado y listo para funcionar.

Y existe el camino de un contenedor docker… para liarla más!!

 

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.