Partager via

Métodos para actualizar un cluster de Hyper-V a Hyper-V R2

  • Article

Hola

El otro día cuando publicamos los enlaces con la información acerca de migraciones a R2 se me olvidó mencionar este punto. Que hacer si se tiene un cluster de Hyper-V (Windows Server 2008) y lo queremos actualizar a Hyper-V R2 para tener CSVs y Live Migration (Windows Server 2008 R2).

En este artículo se plantean tres métodos para llevar a cabo la migración a gusto del consumidor.

Personalmente, en todos los clústeres que he migrado he utilizado el primer método. Se trata de asegurarse de que las VMs no tienen ni estados salvados ni snapshots, y que están paradas antes de iniciar la actualización de la partición padre. Cuando los nodos se han terminado de migrar, hay que actualizar los componentes de integración. Si necesitamos mantener snapshots y/o estados guardados, los pasos a seguir están detallados en el KB.

La migración de las VMs de sus LUNs individuales al CSV, si así lo deseamos, puede hacerse por un proceso manual de exportación importación, o mediante la funcionalidad “Quick Storage Migration” de Virtual Machine Manager R2. Generalmente lo más rápido es aprovisionar una nueva LUN grande en la SAN, convertirla en CSV y liberar el espacio de las LUNs individuales una vez realizada la migración de la VM, quitando el disco correspondiente del cluster, “despresentándolo” desde la cabina y eliminando la LUN.

Saludos

David Cervigón

Comments

  • Anonymous
    January 01, 2003
    Hola No seré yo quien contradiga un KB :-) En el unico sitio donde habla de un evict de los nodos es en el método 3. En mi caso, todos los que he actualizado han sido por el método 1, y sin haberme leido el KB. Asegurandome de que no había snapshots PARO todas las VMs del nodo a actualizar para evitar failovers entre nodos de diferente versión de Hyper-V o a medio actualizar. Tras la actualización, levanto esas VMs y paro las de otro nodo para repetir el proceso. Mas seguro aun sería parar todas las VMs del cluster y actualizar los nodos sucesivamente. Repito que lo que dice los KBs va a misa, y la elección de los métodos van al gusto de las necesidades de cada cual Saludos

  • Anonymous
    January 01, 2003
    Si, lo he visto en clusteres de blades de HP en un par de ocasiones. Si no recuerdo mal, regenerando los virtual switches y asegurandonos de que tienen el mismo nombre en ambos nodos el problema desapareció. Saludos

  • Anonymous
    October 29, 2009
    David, en el KB explica que para los clusters es necesario instalacion nueva del R2 en cada nodo sacándolo primero del cluster. ¿Con el primer método (solo actualizando) tambien funciona? Buena lectura, por cierto.

  • Anonymous
    November 04, 2009
    Precisamente he estado ayer y hoy haciendo esta actualización con el método 1. Ha funcionado todo bien excepto un "detallito". Cuando paso la maquina virtual al otro nodo no consigue conectar la tarjeta de red, aunque esta se llama igual, y aparece como "configuration error".  Ni con move, ni con quick, ni con live. Hasta que no cambias la configuración de la red y le asignas una red virtual del otro nodo, no permite arrancar. Al pasarlo al otro nodo, exactamente igual. ¿Sabes que reglas se siguen para asignar las tarjetas de red en los cambios de nodo? ¿Es sólo por el nombre de interfaz virtual? En el visor de eventos me dice que no puede encontrar el interfaz {xxxxxxxxxxxxxxxxxxxxxxxx}, con lo que dudo si solo mira el nombre. Mañana dejaré todo un poco más "limpio" y abriré un caso en soporte. Te lo comentaba a ti por si te has encontrado con el problema, ya que seguro que has visto bastantes escenarios de failover. Me temo que pueda ser un problema con el software de Teaming (hemos desecho el teaming inicial, pero aun esta el software de Broadcom) o con el MPIO del iSCSI ....