VMware vSphere y vCenter: crear una VM, snapshots con caducidad y un host en mantenimiento sin cortar nadaVMware vSphere and vCenter: creating a VM, snapshots with an expiry and a host in maintenance without cutting anything

Qué vas a conseguir

Operar un clúster de vSphere en el día a día sin pasar por el asistente cada vez: una VM nueva desde plantilla en dos minutos, snapshots que no se olvidan, y la rutina para sacar un host del clúster, parchearlo y devolverlo con las máquinas moviéndose solas. Y los tres sitios donde mirar cuando "todo va lento".

Antes de empezar

• Acceso a vCenter con un rol que pueda crear VMs, snapshots y poner hosts en mantenimiento (no Administrator@vsphere.local para el día a día: un rol propio con lo justo, asignado a tu grupo de AD).
• PowerCLI instalado en tu equipo: Install-Module VMware.PowerCLI -Scope CurrentUser.
• Una plantilla de Windows Server y otra de Linux ya preparadas, con una especificación de personalización (nombre, red, unión al dominio).
• Un clúster con DRS y HA activados y al menos dos hosts con almacenamiento compartido; sin eso, vMotion no tiene adónde ir.

1. Conectar con PowerCLI y mirar el clúster

›Connect-VIServer -Server vcenter.contoso.localName                           Port  User----                           ----  ----vcenter.contoso.local          443   CONTOSO\laura.prado›Get-Cluster | Select-Object Name, HAEnabled, DrsEnabled, DrsAutomationLevelName     HAEnabled DrsEnabled DrsAutomationLevel----     --------- ---------- ------------------CL-PROD  True      True       FullyAutomated›Get-VMHost | Select-Object Name, ConnectionState, @{n="CPU%";e={[int]($_.CpuUsageMhz/$_.CpuTotalMhz*100)}}, @{n="Mem%";e={[int]($_.MemoryUsageGB/$_.MemoryTotalGB*100)}}, Version, BuildName                      ConnectionState CPU% Mem% Version Build----                      --------------- ---- ---- ------- -----esx01.contoso.local       Connected         41   68 8.0.3   24022510esx02.contoso.local       Connected         38   71 8.0.3   24022510esx03.contoso.local       Connected         44   66 8.0.3   24022510›Get-Datastore | Select-Object Name, @{n="FreeGB";e={[int]$_.FreeSpaceGB}}, @{n="Free%";e={[int]($_.FreeSpaceGB/$_.CapacityGB*100)}}Name          FreeGB Free%----          ------ -----DS-SAN-01       1840    31DS-SAN-02        212     4

Tres comandos y ya sabes si hay sitio para una VM más (memoria al 70 % con tres hosts significa que si uno cae, los otros dos van al 100 %) y que DS-SAN-02 está a punto de dar problemas. Esa lectura es la que se hace antes de aceptar cualquier petición de "una VM pequeña".

2. Crear la VM desde plantilla

›New-VM -Name "srv-app-02" -Template (Get-Template "tpl-ws2025-core") -OSCustomizationSpec "spec-windows-domain" -ResourcePool (Get-Cluster CL-PROD) -Datastore DS-SAN-01 -Location (Get-Folder "Aplicaciones") | Out-Null›Set-VM -VM srv-app-02 -NumCpu 4 -MemoryGB 8 -Notes "Ticket CHG-20471 · Owner: IT Ops · App: Intranet" -Confirm:$false | Out-Null›Get-NetworkAdapter -VM srv-app-02 | Set-NetworkAdapter -NetworkName "VLAN20-Servers" -Type Vmxnet3 -Confirm:$false | Out-Null›New-TagAssignment -Entity (Get-VM srv-app-02) -Tag (Get-Tag -Category Backup -Name "Daily-30d") | Out-Null›Start-VM -VM srv-app-02 | Out-Null; Get-VM srv-app-02 | Select-Object Name, PowerState, NumCpu, MemoryGB, @{n="Host";e={$_.VMHost.Name}}, @{n="IP";e={$_.Guest.IPAddress[0]}}Name       PowerState NumCpu MemoryGB Host                 IP----       ---------- ------ -------- ----                 --srv-app-02 PoweredOn       4        8 esx02.contoso.local  10.20.20.47

Dos cosas que no son opcionales en una VM de producción: las notas con el ticket y el propietario (dentro de un año nadie recordará para qué era) y la etiqueta de backup, que es lo que Veeam (Nivel 2) usa para incluirla en el job sin que nadie la añada a mano. La especificación de personalización se encarga del nombre, la IP y la unión al dominio; a los cinco minutos la VM aparece en Active Directory.

3. Snapshots: cortos, con nombre y con fecha

›New-Snapshot -VM srv-app-02 -Name "CHG-20471 antes de parche · borrar 2026-10-25" -Description "laura.prado · parche de la aplicación" -Memory:$false -Quiesce:$true | Out-Null›Get-VM | Get-Snapshot | Where-Object Created -lt (Get-Date).AddDays(-3) | Select-Object VM, Name, Created, @{n="SizeGB";e={[math]::Round($_.SizeGB,1)}}VM          Name                                   Created             SizeGB--          ----                                   -------             ------srv-erp-01  antes de actualizar                    2026-09-02 21:14      184,3srv-file-02 prueba                                 2026-08-19 10:02       61,0# cuando el cambio esté validado:›Get-Snapshot -VM srv-app-02 | Remove-Snapshot -Confirm:$false

Un snapshot de 184 GB de hace siete semanas en el servidor del ERP es la causa número uno de "el ERP va lento" y de datastores llenos. La regla: nombre con el ticket y la fecha de borrado, nunca más de 72 horas, -Quiesce para que sea consistente con la aplicación, sin memoria salvo que necesites volver al estado exacto de ejecución. El comando de la segunda línea, en una tarea semanal que mande el resultado al canal del equipo, es la política de snapshots. Un snapshot no es una copia de seguridad: si el datastore se pierde, se pierde con él.

4. Un host en mantenimiento sin cortar nada

›Get-VMHost esx03.contoso.local | Get-VM | Select-Object Name, PowerState | Measure-Object | Select-Object CountCount-----   14›Set-VMHost -VMHost esx03.contoso.local -State Maintenance -Evacuate -Confirm:$false# DRS mueve las 14 VMs con vMotion a esx01 y esx02; tarda unos minutos›Get-VMHost esx03.contoso.local | Select-Object Name, ConnectionState, @{n="VMs";e={($_ | Get-VM).Count}}Name                 ConnectionState VMs----                 --------------- ---esx03.contoso.local  Maintenance       0# parchear con Lifecycle Manager (o desde la consola: Updates › Remediate) y reiniciar›Restart-VMHost -VMHost esx03.contoso.local -Confirm:$false | Out-Null›Set-VMHost -VMHost esx03.contoso.local -State Connected | Out-Null›Get-VMHost | Select-Object Name, ConnectionState, Version, Build

Esto es lo que hace que parchear un hipervisor no sea un cambio con corte: modo de mantenimiento con evacuación, DRS reparte las VMs, se parchea, se reinicia, se devuelve, y DRS vuelve a equilibrar. Compruébalo antes con la pregunta del paso 1: si los otros dos hosts no tienen memoria para absorber las 14 VMs, el Set-VMHost se queda esperando. En vCenter, Lifecycle Manager con una imagen por clúster hace la parte del parche y deja el informe de cumplimiento.

Consejo: haz esto en un host de test o con una VM de pruebas la primera vez, y mira en Monitor → Tasks and Events cómo se mueve cada VM. Lo que ves ahí es lo que explicas en el ticket de cambio.

5. Datastore lleno y "todo va lento"

›Get-Datastore DS-SAN-02 | Get-VM | Get-Snapshot | Measure-Object SizeGB -Sum | Select-Object @{n="SnapshotGB";e={[int]$_.Sum}}SnapshotGB----------       412›Get-Datastore DS-SAN-02 | Get-VM | Where-Object {$_.PowerState -eq "PoweredOff"} | Select-Object Name, @{n="ProvisionedGB";e={[int]$_.ProvisionedSpaceGB}}Name          ProvisionedGB----          -------------srv-old-crm          520›Get-VM srv-erp-01 | Get-Stat -Stat disk.maxTotalLatency.latest -Realtime -MaxSamples 10 | Select-Object Timestamp, ValueTimestamp           Value---------           -----22/10/2026 10:12:00    4822/10/2026 10:11:40    61

Los tres sitios donde mirar: snapshots en el datastore (412 GB aquí, el 90 % del problema), VMs apagadas que nadie borró (520 GB provisionados) y la latencia de disco de la VM que se queja (disk.maxTotalLatency por encima de 20-30 ms sostenidos es almacenamiento, no la VM). En la consola, Monitor → Performance → Advanced muestra lo mismo con gráfico; esxtop en el host, con d y u, es la vista fina. Con Grafana (guía anterior), vmware_exporter o el plugin de vCenter dan estas métricas en el panel del equipo.

6. Lo que revisas cada mes

• Snapshots con más de 3 días y VMs apagadas con más de 30 (Get-VM | Where PowerState -eq PoweredOff | Select Name, @{n="Days";e={((Get-Date)-($_ | Get-VIEvent -MaxSamples 1).CreatedTime).Days}}).
• Datastores por debajo del 15 % libre y el crecimiento mensual.
• Hosts con builds distintos en el mismo clúster (Get-VMHost | Group-Object Build): el que no se parcheó.
• Skyline Health / Monitor → Health del clúster y las alarmas de vCenter no reconocidas.
• Que vCenter tiene su propia copia (File-Based Backup en la VAMI, puerto 5480) y que se probó una restauración este trimestre.

Siguientes pasos

• VCF / NSX cuando el clúster crezca a varios y la red pase a definirse por software; la operación diaria es la misma, con más capas.
• vSphere Replication o SRM para el DR del Nivel 4: la VM replicada en el otro CPD y el plan de recuperación probado dos veces al año.
• Para quien venga de Hyper-V (guía anterior) o vaya a Nutanix (Nivel 4): snapshots cortos, host en mantenimiento, datastore con margen y notas en la VM son las mismas reglas con otros nombres.

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