Nutanix AHV para quien viene de vSphere: Prism, protección, LCM y un disco caídoNutanix AHV for vSphere people: Prism, protection, LCM and a failed disk

Qué vas a conseguir

Traducir lo que ya sabes de vSphere a Nutanix con AHV: dónde se administra cada cosa, cómo guarda los datos el clúster y cuánto aguanta, crear y proteger una VM con réplica a otra sede, actualizar sin ventana de corte y responder a una alerta de disco o a una VM lenta con las herramientas del propio clúster.

Antes de empezar

• Un clúster Nutanix con AOS y AHV (tres nodos o más), acceso de administrador a Prism Element y, si existe, a Prism Central.
• Acceso SSH a las CVM con el usuario nutanix: ahí viven ncli, acli y ncc.
• La guía de VMware vSphere y vCenter como punto de partida: esta tabla resume las equivalencias.

1. El clúster por dentro: CVM, contenedores y factor de replicación

Cada nodo ejecuta una Controller VM (CVM) que tiene los discos locales en passthrough y sirve el almacenamiento a todo el clúster. Las VM escriben en su CVM local, y la CVM copia cada dato a otro nodo (RF2) o a otros dos (RF3) antes de confirmar la escritura.

• RF2 aguanta la caída de un nodo o de un disco; RF3 aguanta dos, pero necesita cinco nodos o más y usa más espacio.
• Los contenedores de almacenamiento son los "datastores": cada uno con su compresión, deduplicación o erasure coding. Un contenedor por tipo de carga (servidores, VDI, copias) es suficiente.
• Deja libre al menos la capacidad de un nodo: si cae uno, sus datos se reconstruyen en los demás y necesitan sitio.

›cluster status | grep -E "CVM:|state"2026-10-28 09:12:41 INFO cluster:3195 The state of the cluster: start        CVM: 10.20.0.31 Up        CVM: 10.20.0.32 Up        CVM: 10.20.0.33 Up, ZeusLeader        CVM: 10.20.0.34 Up›ncli container ls | grep -E "Name  |Replication Factor"    Name                      : ctr-servidores    Replication Factor        : 2    Name                      : ctr-vdi    Replication Factor        : 2›ncli cluster get-domain-fault-tolerance-status type=node    Domain Type               : NODE    Component Type            : EXTENT_GROUPS    Current Fault Tolerance   : 1

Current Fault Tolerance: 1 quiere decir que el clúster puede perder un nodo ahora mismo sin perder datos. Si es 0, no se toca nada hasta que vuelva a 1.

2. Crear una VM en AHV

En Prism (Element o Central): VMs › Create VM, con disco desde una imagen o un ISO y la NIC en su subred. Lo mismo con acli, útil para repetirlo:

›acli vm.create srv-app01 num_vcpus=2 num_cores_per_vcpu=1 memory=8G›acli vm.disk_create srv-app01 clone_from_image=win2022-plantilla›acli vm.disk_create srv-app01 create_size=100G container=ctr-servidores›acli vm.nic_create srv-app01 network=vlan20-servidores›acli vm.on srv-app01›acli vm.snapshot_create srv-app01 snapshot_name_list=antes-parche-oct

• Instala Nutanix Guest Tools (NGT) y los controladores VirtIO: sin ellos el disco y la red van más lentos y los snapshots no son coherentes con la aplicación.
• Para traer VMs desde vSphere, Nutanix Move migra con sincronización incremental y un corte corto al final.
• Un snapshot no es una copia de seguridad: está en el mismo clúster. Bórralo cuando el cambio esté validado.

3. Protección y réplica a una segunda sede

En Prism Element existen los Protection Domains (grupo de VM, calendario y sitio remoto). En instalaciones nuevas se usan las políticas de protección de Prism Central, que se aplican por categoría: la VM que recibe la categoría queda protegida sin tocar la política.

• Completa con un plan de recuperación (Recovery Plan): orden de arranque, retardo entre grupos y la red de destino, con una red de pruebas aislada para ensayar.
• Haz una conmutación de prueba cada trimestre: es la única forma de saber que el RPO prometido se cumple y que las VM arrancan en la otra sede.
• La réplica no sustituye a la copia de seguridad: si se cifran las VM, se replica el cifrado.

4. Actualizar con LCM y poner un host en mantenimiento

Life Cycle Manager (en Prism: LCM) actualiza AOS, AHV, NCC, firmware y BIOS. Primero Perform Inventory, después elige versiones y deja que haga las comprobaciones previas. Va nodo a nodo: migra las VM, reinicia, espera a que el clúster recupere la resiliencia y pasa al siguiente.

• Orden habitual: NCC, después AOS, después AHV, y el firmware al final. Revisa la matriz de compatibilidad antes.
• Ejecuta ncc health_checks run_all antes de empezar y no lances LCM con fallos abiertos.

Para un trabajo de hardware en un nodo, el mantenimiento se hace en Prism (Hardware › Host › Enter Maintenance Mode) o desde una CVM:

acli host.enter_maintenance_mode 10.20.0.22 wait=true

Con eso el host AHV vacía sus VM por migración en vivo. Si hay que apagar el nodo, también se pone en mantenimiento su CVM (ncli host edit id=<id> enable-maintenance-mode=true). Al terminar, en orden inverso: ncli host edit id=<id> enable-maintenance-mode=false y acli host.exit_maintenance_mode 10.20.0.22.

Las VM fijadas a un host o con afinidad estricta no se migran: se apagan. Revísalas antes y comprueba que Data Resiliency está en OK antes de pasar al siguiente nodo.

5. El ticket: "el clúster muestra una alerta de almacenamiento / ha fallado un disco"

Martes, 08:40. Prism muestra Disk ... marked offline y el widget de Data Resiliency en amarillo.

1. No reiniciar nada. El clúster ya está reconstruyendo las copias que tenía ese disco en el resto de discos.
2. Ver el estado general con NCC:

›ncc health_checks run_all+-----------------------+| State         | Count |+-----------------------+| Pass          | 228   || Warning       | 3     || Fail          | 1     || Total Plugins | 232   |+-----------------------+Detailed information can be found in /home/nutanix/data/logs/ncc-output-latest.log›grep -A6 "FAIL:" /home/nutanix/data/logs/ncc-output-latest.logFAIL: Disk 0000003 (serial S6Z4NX0T812345) on host 10.20.0.23 is offline.›ncli disk get-remove-status    Disk Id                   : 0005f1a2-...::42    Remove Status             : DATA_MIGRATION_INITIATED

1. Esperar a que la tolerancia vuelva a 1 (ncli cluster get-domain-fault-tolerance-status type=node). Mientras sea 0, nada de mantenimientos ni actualizaciones.
2. Abrir el caso con el fabricante con el número de serie, el resumen de NCC y un paquete de logs (logbay collect), y sustituir el disco en caliente. Prism lo detecta y lo añade al pool (Hardware › Diagram, si no lo hace solo: Repartition and Add).

La variante: "una VM va lenta". En Prism, en la VM: latencia del controlador (lectura y escritura), IOPS y uso de CPU y memoria. Latencia alta en todo el clúster apunta a almacenamiento (nivel SSD lleno, un disco o un nodo degradado: NCC lo dirá). Latencia alta solo en esa VM apunta a la propia VM: sin VirtIO, disco único con mucha cola, o un snapshot antiguo que nadie ha borrado. CPU con tiempo de espera alto (CPU Ready) indica un host sobrecargado: deja que ADS reparta o revisa las reglas de afinidad. acli vm.get srv-app01 muestra la configuración real (vCPU, memoria, discos y en qué contenedor está cada uno).

6. Lo que revisas cada mes

• Resultado de ncc health_checks run_all y alertas sin resolver en Prism Central.
• Capacidad: uso del pool frente a la reserva de un nodo, y la previsión de Planning en Prism Central.
• Snapshots con más de una semana y réplicas que no cumplen su RPO.
• Versiones pendientes en LCM y el fin de soporte de la rama de AOS en uso.

Siguientes pasos

• La guía de Backup y DR/BCP para encajar las políticas de protección en el plan de continuidad y en las pruebas.
• Veeam Backup tiene integración con AHV para la copia fuera del clúster.
• Red Hat OpenShift y Kubernetes pueden ejecutarse sobre el clúster con el controlador CSI de Nutanix.
• Terraform con el proveedor de Nutanix para crear VMs y categorías como código.

¿Falta algo o en tu entorno es distinto? Escríbeme y lo corrijo.