VMCX vs VMRS en Hyper‑V: diferencias, uso seguro y buenas prácticas

Última actualización: 16/10/2025
Autor: Isaac
  • Distingue roles: .vmcx guarda configuración y .vmrs el estado de ejecución; no deben borrarse manualmente.
  • Los checkpoints sirven para revertir rápido; no sustituyen a las copias de seguridad independientes.
  • Actualizar la versión de configuración habilita funciones clave (vTPM, VBS, GPU‑P) según el host.

Diferencias entre Hyper-V, VirtualBox y VMware

En Hyper‑V hay dos ficheros que siempre dan que hablar: .vmcx y .vmrs. Si alguna vez te has encontrado con el disco a tope y has pensado en borrarlos a mano con PowerShell, frena un segundo. Entender qué guarda cada uno y cuándo se generan es clave para no liarla y perder máquinas o dejar el host hecho un cristo.

Además del tema del espacio, en torno a estos archivos orbitan conceptos como puntos de control (instantáneas), copias de seguridad y la versión de configuración de las VMs. Y sí, también hay diferencias importantes entre snapshots y backups, cómo consolidar discos .avhdx, o cuándo conviene subir la versión de configuración para desbloquear nuevas funciones de Hyper‑V.

¿Qué son .vmcx y .vmrs en Hyper‑V?

En los hosts modernos de Microsoft, el archivo .vmcx almacena la configuración binaria de la máquina virtual: hardware virtual, redes, rutas de discos, etc. Sustituye al antiguo XML de versiones previas. Sin este fichero, la VM literalmente no sabe quién es ni cómo arrancar.

El archivo .vmrs guarda el estado de ejecución de la VM (runtime state). En versiones actuales convive con .vmgs (guest state) a partir de VMs con versión 8.2 y superiores. El .vmrs se utiliza para estados guardados y ciertos metadatos de la ejecución; no es un disco de datos, así que borrarlo a pelo puede corromper la VM o impedir su reanudación.

Ubicaciones por defecto en hosts Windows actuales: C:\ProgramData\Microsoft\Windows\Hyper‑V\Virtual Machines para .vmcx, .vmrs y .vmgs, y C:\ProgramData\Microsoft\Windows\Hyper‑V\Virtual Hard Disks para los discos .vhd/.vhdx. Los puntos de control (checkpoints) generan sus propios .vmcx y .vmrs en C:\ProgramData\Microsoft\Windows\Snapshots, además de los discos de diferenciación .avhdx.

¿Puedo borrar .vmcx o .vmrs para ahorrar espacio?

La respuesta corta es: no lo hagas. El .vmcx es la identidad y configuración de la VM; si lo eliminas, la máquina queda inservible hasta que reconstruyas esa configuración exacta. El .vmrs guarda el estado de ejecución/guardado; si lo borras, perderás ese estado y puedes provocar inconsistencias.

Si el problema es el espacio, ataca las causas habituales de crecimiento: puntos de control olvidados que generan cadenas de .avhdx, estados guardados innecesarios y VMs con mucha RAM que reservan más estado. El camino seguro para recuperar espacio es eliminar checkpoints desde el administrador de Hyper‑V y permitir la consolidación automática de los .avhdx con el .vhdx padre.

Para evitar que Hyper‑V guarde estado al apagar el host (y con ello archivos .vmrs voluminosos), revisa por VM la acción de detención automática: establece Apagar o Apagar invitado en lugar de Guardar el estado. Así Hyper‑V no tendrá que persistir el runtime state cuando apagues el host y evitarás archivos .vmrs grandes cuando no son necesarios.

Instantáneas (puntos de control) vs copias de seguridad: no son lo mismo

Las instantáneas de VM y los backups sirven para recuperar, sí, pero cumplen cometidos distintos. Un snapshot captura el estado puntual (discos, memoria, dispositivos) y luego desvía los cambios a discos delta para ese punto de control. Una copia de seguridad es una copia independiente (idealmente externa) pensada para retención prolongada y recuperación ante desastres.

  Añadir bordes a capturas de pantalla con la app Recortes de Windows 11

El snapshot es rápido y muy útil para pruebas o cambios arriesgados de corta duración. Los backups (mejor basados en imagen) protegen sistemas completos y se pueden llevar a almacenamiento externo o nube, con deduplicación, compresión y políticas de retención. Usar snapshots como si fueran backups es un error: las instantáneas dependen del disco base, consumen almacenamiento con el tiempo y afectan al rendimiento si se encadenan o se retienen días.

Instantánea Backup
Propósito Revertir rápido al estado puntual de la VM Protección integral y restauración completa o granular
Dependencia Depende de datos de origen (discos base) Copia independiente en otra ubicación
Retención Corta (horas/días); penaliza rendimiento si se alarga Larga; se optimiza con dedupe/compresión
Recuperación Rápida sobre la VM original Flexible; permite nuevas VMs en otro host

Cómo funcionan las instantáneas y qué ficheros crean

En términos de almacenamiento, las instantáneas pueden basarse en copy‑on‑write (CoW), donde los cambios se escriben en un delta cuando se modifica el bloque original, o en redirect‑on‑write (RoW), redirigiendo las escrituras a una nueva ubicación dejando intacto el original. En ambos casos, las cadenas dependen del padre; si el disco base desaparece, no hay vuelta atrás.

En VMware vSphere, una instantánea genera varios archivos: .vmdk (descriptor y -flat con datos), -delta.vmdk (diferenciales SPARSE), .vmsd (metadatos de snapshots) y .vmsn (estado de memoria si se captura). Todos residen junto a los discos principales y crecen a medida que la VM escribe más datos con la instantánea abierta.

En Hyper‑V, los puntos de control crean: .vmcx y .vmrs específicos del checkpoint, el .avhdx (disco de diferencias), y archivos de seguimiento como .rct (Resilient Change Tracking, crucial para backups incrementales) y .mrt (resiliencia ante fallos de host). En VMs 8.2+ también aparece .vmgs para estado del invitado.

Buenas prácticas con snapshots en producción

Utiliza puntos de control como airbag temporal antes de actualizaciones, cambios de configuración o pruebas. Evita cadenas largas: 2‑3 instantáneas como máximo y, por VM, no prolonges más de 72 horas para minimizar el impacto en I/O.

Después de validar que todo va bien, elimina las instantáneas para consolidar los .avhdx con el disco principal. Si ves crecimiento de almacenamiento o caídas de rendimiento, revisa la carpeta de la VM por .avhdx encadenados y gestiona la consolidación desde Hyper‑V Manager; las operaciones a mano sobre discos delta sin planificación pueden causar pérdidas de datos.

Copias de seguridad de VM: imagen vs archivo y cómo se integran los snapshots

Las copias basadas en imagen capturan toda la VM (SO, configuración, discos) y permiten restauraciones completas o arranque instantáneo desde backup. Las basadas en archivos instalan un agente en el invitado y protegen datos a nivel de sistema de ficheros, pero no restauran el entorno virtualizado.

Las soluciones modernas orquestan snapshots de la plataforma (VMware/Hyper‑V) o del almacenamiento para congelar el estado, copiar solo bloques cambiados (apoyadas en CBT/RCT), y borrar la instantánea en cuanto el backup queda consistente. Así reducen el impacto en producción y aceleran la ventana de copia.

Hay herramientas comerciales que explotan estas técnicas para ESXi y Hyper‑V con funciones como incrementales, deduplicación, archivado a S3, restauración rápida, gestión centralizada de múltiples hosts o retención automática. La clave es que el backup resultante sea independiente de los discos de origen y se guarde en ubicaciones separadas (NAS, nube, cinta) para eliminar el punto único de fallo.

  ¿Cómo hago juegos para mis Historias de Instagram? Tableros de juego y derivados

Versiones de configuración de VM en Hyper‑V: qué son y cuándo actualizar

La versión de configuración define el formato de archivos (incluidos .vmcx/.vmrs) y las capacidades de la VM en relación con el host. Al mover/importar una VM a hosts más nuevos (Windows 10/11, Windows Server 2016/2019/2022/2025) la versión no sube sola, de forma que puedes seguir moviéndola a hosts antiguos pero no aprovechas nuevas funciones hasta actualizar.

Pasos típicos para revisar y subir versión: abre PowerShell como administrador y ejecuta Get‑VM para ver versiones; apaga la VM; en Hyper‑V Manager, Acción > Actualizar versión de configuración, o usa Update-VMVersion <NombreVM>. Antes, asegúrate de que no tendrás que volver a un host con versión inferior.

Para ver qué admite tu host, usa Get-VMHostSupportedVersion. Si necesitas crear una VM compatible hacia atrás, puedes fijar la versión al crearla: New-VM -Name "WindowsCV5" -Version 5.0. El valor predeterminado depende del sistema: Windows Server 2025 y Windows 11 24H2 aceptan versiones de configuración hasta 12.0 (y compatibles hacia atrás en distintos grados), mientras que ediciones anteriores se quedan en 10.x, 9.x, etc.

Funciones que requieren una versión mínima de configuración

Algunas características de Hyper‑V piden un nivel mínimo. Si no llegas, no aparecerán o no funcionarán. Entre las más destacadas: Partición de GPU (12.0), soporte ARM64 en invitado (11.0), modo de compatibilidad dinámica de procesador (10.0), virtualización anidada en AMD (9.3), mejoras vNUMA/AMD (9.2/9.1), VBS e invitado con hibernación (9.0), aumentar dispositivos virtuales por tipo a 64 (8.3), y vTPM o añadir/quitar memoria en caliente (7.0/6.2). Actualizar la versión de configuración desbloquea estas capacidades.

Tipos de archivos de una VM y dónde se guardan

Tipo Descripción y extensión Ruta por defecto
Configuración .vmcx, binario con la configuración de la VM C:\ProgramData\Microsoft\Windows\Hyper‑V\Virtual Machines
Estado en tiempo de ejecución .vmrs y .vmgs, estado de ejecución e invitado C:\ProgramData\Microsoft\Windows\Hyper‑V\Virtual Machines
Discos virtuales .vhd/.vhdx, datos de la VM C:\ProgramData\Microsoft\Windows\Hyper‑V\Virtual Hard Disks
Discos de diferenciación .avhdx, se crean con checkpoints C:\ProgramData\Microsoft\Windows\Hyper‑V\Virtual Hard Disks
Checkpoint .vmcx/.vmrs propios del punto de control C:\ProgramData\Microsoft\Windows\Snapshots

Contexto y mejoras clave desde Windows Server 2016

La llegada de 2016 cambió muchas piezas bajo el capó de Hyper‑V: los formatos .vmcx/.vmrs sustituyeron a los antiguos, mejorando fiabilidad y rendimiento de lectura/escritura de configuración, y reduciendo riesgos ante fallos de almacenamiento.

En almacenamiento apareció la QoS centralizada con Scale‑Out File Server, capaz de aplicar mínimos/máximos IOPS a VMs o grupos y monitorizar tráfico en tiempo real. También debutó Storage Spaces Direct (S2D) para nodos hiperconvergentes con SAS/SATA/SSD/NVMe (SATA tras HBA SAS), espejo 2/3 vías y despliegue agregado o desagregado.

La pila de red adoptó VXLAN para SDN, incorporó Network Controller, SLB, NFV y puerta de enlace RAS; RDMA se simplificó con Switch Embedded Teaming (SET) para compartir NIC en tráfico de almacenamiento y Live Migration. Todo ello con un ojo puesto en la convergencia con Azure.

El proceso de actualización de clústeres introdujo el nivel funcional que permite modo mixto mientras migras hosts, y luego un Update‑ClusterFunctionalLevel para desbloquear novedades. Durante el modo mixto se mantienen formatos antiguos; al finalizar, puedes actualizar la VM (requiere apagado) para pasar a los nuevos .vmcx/.vmrs.

En copia y consistencia de datos, Hyper‑V pasó de depender de VSS externo a exponer Resilient Change Tracking (RCT), facilitando incrementales eficientes. Los checkpoints de producción usan VSS dentro de la VM para garantizar que el invitado es consciente y arranque limpio, mitigando riesgos en servicios distribuidos como AD o Exchange.

  How one can Conceal Photographs on Android Telephone or Pill

La resiliencia ante incidentes mejoró: ante pérdidas breves de red, el host entra en modo aislamiento antes de provocar failover; ante pérdida de almacenamiento, las VMs se congelan y reanudan si vuelve el backend. Además, llegó el balanceo automático de VMs entre hosts sin depender de VMM.

En seguridad, las VM blindadas (shielded VMs) combinan UEFI Secure Boot, vTPM, BitLocker/dm‑crypt y el Host Guardian Service con atestación (AD o TPM 2.0) para impedir que administradores de host accedan a discos o memoria de VMs protegidas; el tráfico de Live Migration se cifra y se restringe la telemetría sensible.

Se incorporaron contenedores (Windows y Hyper‑V) con gestión Docker y virtualización anidada, y ReFS se convirtió en el sistema recomendado para VMs gracias a su rapidez al crear discos fijos y migrar checkpoints. Otros caramelos: añadir/quitar NIC en caliente, cambiar memoria estática en ejecución, hacer backup de VHDX compartidos y redimensionarlos en vivo, y un Hyper‑V Manager capaz de gestionar hosts 2012/2012 R2 con credenciales alternativas.

Impacto de snapshots y backups en el rendimiento y el almacenamiento

Una instantánea retenida días genera crecimiento de discos delta y capas de lectura/escritura que penalizan IOPS. Cuanto más escriba la VM, más crecerá el -delta (VMware) o el .avhdx (Hyper‑V). Los backups, en cambio, se diseñan para optimizar almacenamiento con compresión y deduplicación, replicarse a varios destinos y validar integridad.

La regla de oro: snapshot para volver atrás rápido tras una operación arriesgada; backup para protección real a medio y largo plazo. En producción, lo sensato es combinar ambos: checkpoint corto + copia de seguridad programada basada en imagen.

Cómo comprobar versiones y planificar actualizaciones de VMs

Comprueba versiones con: Get-VM * | Format-Table Name, Version. Si decides subir, apaga la VM y ejecuta Update-VMVersion <NombreVM>. Si en GUI no aparece la opción, ya estás en la versión más alta del host.

Para hosts con mantenimiento a largo plazo (Server 2016, 2019, 2022, 2025; Windows 10/11 LTSC) y de canal semianual, las versiones soportadas difieren. Windows Server 2025 y Windows 11 24H2 aceptan 12.0 como tope, 22H2/23H2 se quedan en 11.0, Server 2022 en 10.0, y así sucesivamente. Ajusta la versión al mínimo común si vas a mover VMs entre hosts heterogéneos.

Seguridad y continuidad: más allá del hiperconvergente

La protección de datos sigue siendo prioridad. Los backups y la recuperación ante desastres son esenciales frente a ciberamenazas (ransomware, por ejemplo). Conviene mantenerse al día con guías y alertas del CERT; puedes consultar, como referencia, este informe público del CCN‑CERT: documento sobre ransomware.

Si llegaste hasta aquí, ya tienes claro que .vmcx es configuración y .vmrs es estado, que no se borran a capón, y que los checkpoints no sustituyen a los backups. Con una política de instantáneas prudente, copias basadas en imagen con RCT/CBT, versiones de configuración al día y las mejoras de Hyper‑V (QoS, S2D, SDN, producción checkpoints, shielded VMs), puedes mantener tus VMs seguras, ágiles y con el almacenamiento bajo control sin sustos.