Experiencias: Cambio de VMware Workstation a Hyper-V 2016

Como todos los que siguen este blog conocen, todas las notas con los paso a paso que pueden ver, hasta ahora están hechas sobre máquinas virtuales con VMware Workstation

Básicamente esto era por la facilidad de uso de este producto en ambientes de prueba, mientras que Hyper-V desde un principio estaba orientado a ambientes productivos, con las restricciones de flexibilidad que eso implicaba

A partir de las últimas experiencias con VMware Workstation, y las nuevas posibilidades de Hyper-V 2016, estuve pensando bastante en si hacía el cambio o no

Comento en esta nota mis experiencias, qué evalué, qué encontré mejor y que no, cómo estoy armando mi nuevo ambientes de pruebas, y bueno, cualquier otra cosa que me ha llamado la atención

Ventajas importantes para mi ambiente de prueba que eran de VMware Workstation:

• Hyper-V dentro de una virtual con Windows Server («Nested Virtualization»)
• Menor uso de memoria cuando son varias máquinas virtuales simultáneas en uso
• Copiar y pegar, o arrastrar, para copiar archivos entre virtual y real
• Compatibilidad con sistemas operativos de versiones anteriores
• Redes virtuales con NAT a la red física
• En mi caso personal, familiaridad con el producto, venía usándola desde la v4, y no sé bien pero creo que alguna primera prueba de uso la he hecho sobre la v3

Con la disponibilidad de Windows Server 2016 que elimina muchas de las limitaciones que venía teniendo, debido a su orientación a ambientes productivos, he pensado bastante en ¿y si cambio VMware Workstation por Hyper-V?

VMware Workstation tiene problemas, no graves pero que suelen ser molestos, que se vienen arrastrando de versiones anteriores y que no le han dado solución. Como un ejemplo: a veces deja de funcionar el copiar y pegar y cuando lo hace, ya no funciona ni en la máquina real; y sucede lo mismo con arrastrar

Las últimas versiones no justificaban para nada un cambio en el número de versión, como sucedía hace tiempo. Por ejemplo los cambios de la v11 a la v12 fueron mínimos, que dé soporte oficial a W10 cuando en la v11 ya funcionaba realmente no me pareció bueno. Y además la v12.5, que salió retrasada y que tiene problemas con máquinas virtuales EFI/UEFI, y que aún ya pasado el tiempo no han solucionado, me hicieron pensar seriamente en el cambio

He leído los foros de soporte de VMware y no soy el único con esos problemas, pero más que algo así como “estamos estudiando el tema” no hay otra respuesta aún. Esperé unos días para ver si había alguna novedad, pero no la hay hasta el momento

Todo comenzó haciendo pruebas con Hyper-V 2016 dentro de una virtual VMware y encontré cosas que me gustaron, sólo algunos ejemplos:

• Poder anidar virtuales dentro de virtuales
• La asinagación dinámica de memoria soluciona el problema de consumo RAM
• Con los nuevos “Integration Services” ya podemos copiar fácilmente entre virtuales y física
• Si llegar a necesitar una versión de sistema operativo realmente “vieja” creo que no tendría problemas en crear una máquina virtual con VMware Workstation, aunque aún no lo probé
• Aunque hay que hacerlo sólo a través de PowerShell ya podemos crear redes con NAT en Hyper-V

Y también ventajas adicionales, para nombrar sólo una: la activación automática de máquinas virtuales creadas sobre la versión Windows Server 2016 Datacenter

Así que luego de unos dias de evaluar, pensar, probar, pensar, volver a probar, pensar, dudar, pensar, dejar reposar ideas, pensar, …

Bueno, ya está, hice una copia de seguridad (“Backup”) de tipo “Bare metal recovery” del disco C:\ y a probar

La instalación no fue realmente complicada, ya que además del disco que era el C:\ detectó perfectamente el RAID de tres discos donde están los datos; Windows Server 2012 R2 me había dado bastante trabajo con este tema

Por supuesto que hubieron componentes que no detectó de primera, hubo que poner algunos “Drivers” en forma manual, esto no cambió respecto a lo que tuve que hacer con Windows Server 2012 R2. Esto se produce muchas veces porque los archivos INF de los “Drivers” vienen configurados para uso sólo en sistemas operativos de escritorio, y no permiten instalarlos en sistemas operativos servidores, pero como en mi caso no me apego a las buenas prácticas de un servidor en ambiente operativo, pude hacer que reconozca todos los componentes correctamente

Inclusive, y ante la duda de si la migración iba a ser definitiva o no, creé un “mutliboot” con Hyper-V y Sin Hyper-V, ya que si está presente Hyper-V no permite el funcionamiento de VMware Workstation. Probé el funcionamiento de virtuales VMware y fue satisfactorio, así que comencé a “pelear” con Hyper-V, que no es que no lo hubiera usado o conocido, al contrario :)

Lo primero fue cambiar algunas configuraciones, por ejemplo que por omisión los discos de las máquinas virtuales no los guardara en C:\ sino en D:\

Y luego crear unas máquinas de prueba con diferentes versiones de sistema operativo para comprobar el funcionamiento básico, resultó todo correcto

El paso siguiente fue ver cómo podía reconstruir el ambiente de virtualización que tenía con VMware. Con las redes virtuales ningún problema, lo que tenía armado era básicamente, varias redes virtuales con conectividad únicamente entre las máquinas que estaban en dicha red, y una máquina virtual que además de hacer de Router entre ellas, hacía NAT con la red física.

Esta máquina virtual la pude crear y configurar con la misma funcionalidad sin ningún problema, y que de esta forma me permite tener las virtuales en un ambiente totalmente aislado, pero por otra parte si necesitan conectividad a Internet solamente hay que prender este “Router”

Aproveché y creé una red de tipo Interna, para tener conectividad de red, entre la física y algunas virtuales sin pasar por la red física y tener que prender el Router nombrado anteriormente donde además debería haber configurado “Port Forwarding”

Con lo anterio ya quedó hecho el cambio equivalente a las VMnet0, VMnet1 y VMnet8

Como pienso que voy a necesitar más de estas internas, creé alguna más, y configuré en la máquina real, el servicio DHCP, pero que atienda peticiones solamente sobre las redes internas, para que no interfiriera con el Router físico real de la red física

Para crear el ambiente de pruebas, una de las cosas importantes es cómo hacer el cambio de los “Linked clones” de VMware, ya que todas las máquinas usadas hasta ahora eran así, al nuevo ambiente con Hyper-V

Hyper-V no da la opción de “Linked clones”, pero se puede obtener el mismo resultado con otra técnica: los discos diferenciales

Entonces el tema, aunque es un poco más tedioso se puede resolver fácilmente:

1. Crear una máquina virtual con la instalación básica, y personalizarla a gusto, aunque muchas de esas configuraciones no se preservarán :(
2. Ejectuar SYSPREP con las opciones “Generalize” y “Shutdown”
3. Crear un disco virtual usando como “parent” al disco de la máquina ya creada
4. Crear una nueva máquina virtual, pero asignándole como disco, el disco diferencial creado en el paso anterior

Con los pasos hechos llegamos al mismo objetivo, un poco más complicado pero tampoco tan difícil :)

También estuve probando la migración de las máquinas virtuales VMware a Hyper-V, probé y funcionaron, pero siempre prefiero instalación limpia, sin rastros de nada anterior

Utilicé la versión de prueba de WinImage para transformar un “.VMDK” en “.VHD” y luego utilizar este último para crear una máquina virtual Hyper-V. Funcionó perfectamente, pero primero, permite a “.VHD”, no “.VHDX”, y segundo, se toma su tiempo …

Por lo tanto decidí “vamos a comenzar todo de nuevo, limpio”. Esto me llevará no sé cuanto tiempo, hay cerca de 70 virtuales en VMware, que usaba como máquinas base para crear los “Linked Clones”

Además los “Linked Clones” que tenía ya hechos contaban con muchos “Snapshots”. Siempre tengo la costumbre de crearlos cada vez que finalizo una nota, ya que me servirán tanto para revisar, como para hacer una nueva configuración a partir de la anterior. Para que se den una idea DC1 tenía cerca de 40 “Snapshots” :)

Todo este tema llevará tiempo, pero pienso también que ya era momento de hacer un poco de limpieza. Y de todas formas, mantendré durante un tiempo el “multiboot” para en caso de “emergencia” usar VMware con alguna de las virtuales. Estas últimas las conservaré mientras exista espacio en disco

Entonces, para comenzar a reconstruir el ambiente de prueba, hice una imagen “base” y con SYSPREP de varios sistemas operativos: W2016, W10, W8.1 y W7. Todas conectadas a una red privada, no interna

A partir de los anterior y con la técnica de los discos diferencias ya tengo creados: DC1, SRV1, SRV2, CL1, CL2, CL3 y Router

Creado el Dominio, ya hice algunas configuraciones a nivel de Dominio por GPO, como leerán en otra nota, aprovechando experiencias anteriores, que las actualizaciones sean sólo a pedido y no automáticamente, BGInfo mostrando información de la máquina en el escritorio, configuración de Cortafuegos para administrar remotamente, y habilitar Escritorio Remoto en todas las máquinas

Esto último lo considero importante, no sólo para poder ingresar por Escritorio Remoto, ya que los nuevos “Integration Services” hacen algo muy parecido, sino porque cuando se tienen muchas virtuales es muy útil una aplicación no tan conocida y gratuita que les recomiendo: “Remote Desktop Connection Manager”. Da un poco de trabajo hasta hacer la configuración inicial óptima pero vale la pena

Un comentario adicional, que seguramente no los afectará pero que a mí me obligó a cambiar una aplicación. Para escribir estas notas usaba anteriormente “Windows Essentials Live Writer” (malo pero conocido, y viejo) no hubo forma por más compatibilidad que usé para que funcionara :(

Como Microsoft ya hace años abandonó este proyecto, ha permitido su mantenimiento como “Open Source” y ahora está disponible como “Open Live Writer”. Utilizaré éste de aquí en adelante, ya que el editor de WordPress realmente no me gusta

 

Esta nota ha sido sólo para contar las novedades del blog, y seguramente le servirán a más de uno que quiera armar su ambiente de pruebas

Tampoco notarán falta de periodicidad en la publicación de las notas, ya que he dejado preparadas con anterioridad, varias en borrador. Lo que van a notar, es que las de W2016 comenzaron con el nombre de Dominio «corp.guillermod.com.ar» y subred 192.168.3.0/24″, mientras que las creadas en el nuevo ambiente, vuelven al esquema anterior «ad.guillermod.com.ar» y 192.168.1.0/24″

 

Anuncio publicitario