En Azure, una VM una vez ha sido creada no puede cambiarse de región. Así que para “mover” una VM la auténtica función es clonarla y recrearla en la región deseada para luego eliminar la original. Esto es mover, exactamente de la misma manera que un chiste sobre teletransportes de SMBC. Si bien estos pasos se pueden hacer “a mano” desde el propio Azure recomiendan utilizar Azure Resource Mover, que como su nombre indica es un asistente para mover recursos de Azure. Mover, no duplicar-y-borrar-el-original, eso dice la descripción. También dice “mueve tus recursos sin problemas”. Doble punto para los de ventas.

Aunque el proceso utilizando AZCLI lo tenía bastante claro, y de hecho me fue recomendado frente al de ARM por algunos compañeros, en la última ocasión quise probar el ARM por el hecho de que es la opción recomendada y la promesa de “facilidades” que ofrecía. Así que me lancé a ello. Al fin y al cabo el escenario era lo más básico que se puede esperar. Ojo, esto no es una guía detallada del uso de Azure Resource Mover, es un análisis de mi experiencia con la herramienta, de la alternativa que terminé utilizando y de mis conclusiones.

El Escenario

Dos VM en una región (East US, por ejemplo) en un Resource Group con otras seis VM en otra región (Central US). Hay que mover las dos en East US hasta Central. Ambas están unidas a un dominio y cuentan sólo con el disco de OS. Nada muy fancy.

Usando Azure Resource Mover

Lo primero que me sorprendió es que Resource Mover tiene algunos prerrequisitos que me parecían un poco overkill. Es necesario tener privilegios de owner en la subscription. Al parecer crea un System-Assigned Managed Identity a nivel subscription. Una vez validados los prerrequisitos decidí probar primero con sólo una de las dos VM para no complicar las cosas.

El primer paso con Azure Resource Mover es “validar las dependencias”. Es decir, ver cuántos recursos tienen dependencias con la VM que queremos mover (mover siendo -recordemos- clonar y eliminar la original luego). Tiene una interfaz que detecta las dependencias como errores e informa de ellas y nos permite ir resolviéndolas y re-evaluar sin cancelar la operación. Algunas de las curiosas dependencias que encontré:

  • Tuve que seleccionar sólo la VM, si seleccionaba además su NIC, el Resource Mover recomendaba mover el resto de recursos asociados a la nueva región, incluyendo la subnet. Porque se convertían en dependencia de la NIC.
  • No puede moverse de región al mismo Resource Group, ya que como lo que hace es una copia, no va a permitir dos VMs con el mismo nombre en el mismo RG. Como primer workaround me decanté por crear un nuevo Resource Group y una nueva VNET en la región de Central US, y hacer un peering global entre ambas VNET. Mover las VM al Resource Group original podría hacerlo en un segundo paso.
  • Ya que el disco estaba encriptado con keys managed by Azure, debía resolver la dependencia de tener acceso al Key Vault donde estaban las keys. Tuve que dar acceso a los Key Vault de origen a la subscription de la VM, y aún así, seguía dándo problemas y acabé copiando manualmente los backups de la key y el secret hasta otro Key Vault de destino.

Una vez resueltas las dependencias, o esquivadas, el cambio queda listo para ser “commited”, que quiere decir que está validado pero aún no se ha realizado. Una vez realizado veremos aparecer la copia de la VM y el resto de cosas en el destino, con la región correcta. En mi caso, dado que la clona y no apaga la original (yo tampoco la apagué, todo sea cierto) no pudo unir la nueva al dominio porque el equipo original aún existía. Así que otro paso manual iba a ser borrar el objeto computer del AD y entonces unir manualmente esta nueva VM al dominio.

Después de varios pasos manuales, algunos de los cuales nunca había tenido que hacer usando la manera “manual” de mover VMs, me encontré con una VM clonada sin unir al dominio, y la original aún existiendo ya que no había concluido el último paso, que es borrar los recursos originales. Es un paso que hay que dar en Azure Resource Mover y confirmarlo. La ilusión de que se está “moviendo” algo queda disipada en este momento, si aún existía de alguna mínima manera.

Decidí no concluir el movimiento con Resource Mover, volver sobre mis pasos y utilizar el método “no automatizado” que sorprendentemente tiene menos pasos manuales.

Usando AZCLI

Me gustan los SOP (Standard Operating Procedures), hago un esfuerzo constante en convertir cualquier operación que se repite y aún se hace a mano en un SOP con automatización y de esta manera mato dos pájaros de un tiro: Voy reduciendo el toil y además la operación deja de ser algo a criterio de cada operador/ingeniero para ser un consenso de la organización que debe cumplirse y aplicarse. Ya no revisamos cómo planea hacerlo el operador/ingeniero, sino si su operación es conforme a nuestro SOP.

Cuento esto porque pude apoyarme en automations que creé como parte de un SOP para decommisionar VMs de Azure. En ese proceso, los discos de las VM se convierten en imágenes .VHD y son enviadas a un blob en una Storage Account. Esto va a ser relevante luego, lo prometo.

Usar AZCLI para mover una VM es… bastante más inmediato. Sigue siendo el mismo proceso, recordemos que no se pueden mover VMs en Azure. Se “teletransportan” en el sentido del comic de arriba: Se clonan en el destino y se destruye la original. Esto es exactamente lo que hicimos con AZCLI. Para clonar una VM el camino más fácil, o uno de los más fáciles, es clonarla a partir de una snapshot de su disco duro de sistema. Sin embargo encontré problemas para cambiar la región de la snapshot. En la documentación encuentro referencias para mover una incremental pero no una completa. Hay que usar otro truco: Copiar la snapshot como .VHD y enviarla a un blob de Storage Account en la región a la que queramos moverla. ¿Se ve ya como ayuda el automation del backup que mencioné antes?

Así que todo fue:

  1. Crear snapshots de los OS disks de las dos VM.
  2. Copiar dichos snapshots como .VHDs a un blob de un Storage Account en la región de Central US.
  3. Usando una automation de AZCLI, sin dependencies ni ningún otro problema.
  4. Clonar la VM usando como base el .VHD, en la región de destino.
  5. Aquí ayuda bastante hacer deallocation de la VM original, por si acaso hay problemas de colisión de hostname.
  6. Borrar las VM originales.

Una vez clonada es cierto que hubo que borrar el objeto Computer de la original y unir la nueva al Dominio, pero es un paso del que tampoco pude librarme con Azure Resource Mover y que es relativamente sencillo de automatizar con un Powershell que luego podemos ejecutar en la VM usando la extensión Invoke-Command del Agente de Azure de la VM, por ejemplo. Aunque yo logueé y lo hice local.

Una vez comprobadas y validadas funcionalmente las nuevas VM, las VM originales fueron borradas. Y listo, ya estaban teletransportadas desde East US a Central US. Con algunos pasos manuales, cierto, pero la mayoría fácilmente automatizables cuando esta manera de proceder se convierta en SOP. No tuve que resolver ninguna dependencia, por cierto. Ni tuve que copiar manualmente encryption keys a otro Key Vault…

Conclusión: Azure Resource Mover no me puso más fácil mover unas VMs

Como no he investigado la herramienta en profundidad y en otros use cases, no voy a poner en duda su utilizad para otras operaciones de movimiento de recursos, pero después de mi experiencia creo que Azure Resource Mover no facilita la operación para mover VMs entre regiones. De hecho, creo que la complica. Tenemos que resolver innumerables “dependencias” y tenemos un alto riesgo de side effects (mover toda una VNET al mover una VM??) para obtener un resultado final que es el mismo que si clonamos la VM en base a un .VHD o snapshot.

En las pruebas -y eran VMs de Producción- no encontramos la menor diferencia funcional entre las creadas usando el método manual y las originales. Así que, en este caso concreto, creo que es más sencillo aprovechar algunas automatizaciones con AZCLI y crearnos nuestro propio y auténtico “VM mover” que utilizar Azure Resource Mover.