Guía 08.1: Error en VMware "mea culpa"

Imagen creada por Gemini.

Por si acaso sigues este proyecto y has dimensionado el disco de Proxmox como yo.

He encendido el servidor Windows 2019 y al intentar apagarlo, por que se ha congelado en Proxmox me da esto:

QEMU Guest Agent is not running - VM 103 qga command 'guest-ping' failed - got timeout

TASK ERROR: received interrupt…

¿Es grave doctor?

#Mea culpa

Antes de seguir con el proyecto es muy importante que leas esto.

Con este prologo ademas de “entonar el mea culpa” voy a describir el error que me ha dado la falta de previsión a la hora de configurar Proxmox en VMware y tratar de solucionarlo.

Este no es un error provocado. Es un error de calculo a la hora de dimensionar la maquina virtual de Proxmox.

Esta es la imagen del servidor a la hora de intentar apagarlo.

Me da Estado "io-error"

#¿Que significa?

Es el grito de socorro del servidor. No es que se haya roto el Active Directory, es que la máquina virtual ha intentado "escribir" algo en el disco y Proxmox le ha dicho: "¡Para! No tengo sitio o no puedo llegar al disco".

En el 99% de los casos en Proxmox, este error significa Falta de Espacio en el Almacenamiento. La VM quiere seguir trabajando, pero el disco físico donde vive (seguramente tu local-lvm) está lleno al 100%.

#Pasos para reanimar al paciente:
1.- Comprueba el espacio físico:
Ve a la Consola de tu nodo servidor y escribe este comando:

df -h

Busca la línea que corresponda a tu almacenamiento. Si ves algo al 98% o 100%, ahí tienes al culpable.

2.- Mira el estado de LVM:
Como usas local-lvm, usa este comando para ver si los "volúmenes lógicos" están al límite:

lvs

Vemos que Data% esta al 90.66%

Eso, despues de eliminar los snapshots que ya tenia implementados.

#¿Por qué se ha llenado?
Si he hecho muchos Snapshots de ese Windows Server con Active Directory, ocupan muchísimo espacio. Y tenia dos.
ISOs: Tengo varias ISOs grandes (Windows 2019 ocupa casi 6GB) en el almacenamiento local. Si el disco es pequeño, cada giga cuenta.

Esto no hubiera ocurrido si hubiera pensando antes de dimensionar el disco duro de Proxmox.

#La prueba del “algodón no engaña.”

Al instalar y configurar Proxmox dimensione el disco duro del hipervisor a 100 GB. Si hacemos la “cuenta de la vieja”, es decir sumar las maquinas que ya tengo instaladas.

Servidor Debian VM 32 GB

Servidor Debian CT 8 GB

Windows server 2019 60 GB

La suma es de 100 GB

El tamaño que le di al disco en Proxmox.

Y eso que para salir del atolladero he borrado los dos snapshot que le había hecho a WS-2019.

Por lo que:

El Peligro del "Thin Provisioning":
"Lectores, mucho cuidado. Proxmox os permite prometerle a una VM 60GB aunque vuestro disco solo tenga 40GB. Es como vender 100 entradas para un teatro de 50 asientos. Si todo el mundo viene a la vez (o hacéis Snapshots), el sistema se bloquea con un io-error. Nunca asignéis a las VMs más espacio del que tenéis físicamente en vuestro pool data."

El problema ha sido simplemente un "error de dibujo" al repartir el espacio durante la instalación de Proxmox. No es que te falte sitio en el mundo real, es que Proxmox ha encerrado las máquinas virtuales en una habitación muy pequeña, mientras el resto de tu "mansión", el disco físico está sin usar.

#Solución

Para pasar de esos 100 GB a, por ejemplo, 500 GB (o a lo que tú puedas con tu disco físico,), sigue estos pasos:

Paso 1: La Cirugía en VMware (Con la VM apagada)

Antes de tocar Proxmox, hay que agrandar el "recipiente":

Apaga la máquina virtual de Proxmox.

En VMware, ve a Edit Virtual Machine Settings.

Selecciona el Hard Disk.

A la derecha, verás un botón que dice Expand....(“Ampliar”)

Ponle 500 GB (o la cifra que prefieras) y dale a Expand.

No enciendas todavía el servidor.

#Por si acaso.

A mi no me daba la opción de “Expandir”. Me dice que tengo instantáneas y no las veo en VMware. En cambio un servidor Debian que tengo instalado para pruebas si me da esa posibilidad.

El culpable: El misterioso número -000001
Si me fijo en la configuración, en la ruta del "Archivo de disco", el nombre termina en Proxmox-000001.vmdk.

En la imagen no veras esto ya que esta tomada despues de eliminar esa instantanea.

Aunque creía que no tenia instantáneas (snapshots), ese número al final es la prueba matemática de que VMware tiene una instantánea activa. VMware bloquea la opción de expandir el disco siempre que existe un "punto de retorno", porque no puede agrandar la base si hay un archivo de cambios (delta) colgando de ella.

#Cómo despertar el botón "Ampliar..."

#Si tu si tienes como “coletilla” ese numero o uno parecido en tu Proxmox.
Para que ese botón deje de estar en gris, necesitamos que el disco vuelva a ser uno solo (sin el -000001). Sigue estos pasos en VMware:
Asegúrate de que la VM esté apagada
Ve al menú superior: VM -> Snapshot -> Snapshot Manager.

Seguramente verás un icono (quizás se llame "You are here" o tenga un nombre automático).

En esta pantalla deberiamos ver nuestras instántaneas.

Selecciona la instantánea.

Dale a "Delete" o "Delete All".

Yo ya la había borrado.
No te asustes: Esto no borra tus datos, simplemente "fusiona" los cambios del -000001.vmdk con el disco principal.
Tardará un poquito porque tiene que mover datos.
Cuando termine, vuelve a la configuración del disco. Verás que el nombre ahora es simplemente Proxmox.vmdk.
¡Tachán! El botón "Ampliar..." ahora estará activo.

Ya podemos aplicar la #Solución.

Al clicar en Ampliar nos abre una ventana de dialogo.

Le he puesto 600 GB.

Ampliar.

Aceptar.

vemos que la capacidad del disco se ha redimensionado.

Paso 2: La Reeducación en la Shell de Proxmox

Ahora Proxmox verá que el disco es más grande, pero sus "particiones" siguen siendo pequeñas. Entra en la Shell de tu nodo servidor y escribe estos comandos:
1. Instalar la herramienta de expansión rápida:
Para no complicarnos con editores de particiones antiguos, usa esta herramienta que lo hace solo:

apt update && apt install cloud-guest-utils -y

2. Agrandar la partición física:
Normalmente, Proxmox usa la partición 3 para los datos. Vamos a decirle que ocupe todo el espacio nuevo:

growpart /dev/sda 3

3. Avisar al gestor de volúmenes (LVM):
Ahora le decimos a LVM que el "terreno" ha crecido:

pvresize /dev/sda3

4. ¡El gran final! Agrandar la piscina de datos:
Este comando es el que hará que ese 90% que vimos ayer baje drásticamente al darle todo el espacio libre.

lvextend -l +100%FREE pve/data

#¿Cómo saber si el paciente está curado?
Vuelvo a escribir el comando mágico que aprendímos anteriormente:

lvs

En Data% ahora veo que tengo un 6,91% de almacenamiento

#El diagnóstico final: ¡Alta médica!
Adiós al "io-error": Al pasar de un 90% de ocupación a un 6.91%, he creado un océano de espacio. El Windows Server 103, con sus 60 GB prometidos, ahora cabe más de 9 veces en ese pool sin apreturas.
Capacidad de maniobra: Ahora tengo casi 500 GB libres reales para seguir con el proyecto (Debian, pfSense, Wazuh, etc.).

#¿Qué sigue ahora?
Ya no hay excusas para el miedo. El armario se ha convertido en un almacén logístico:
Enciende tu VM 103 (Windows Server 2019): Debería arrancar sin parpadeos ni bloqueos.
Ya está la infraestructura "blindada" contra errores de espacio.

"La Solución: No hace falta reinstalar. La virtualización nos permite 'estirar' el hierro virtual. Ampliamos en el hipervisor base (VMware/VirtualBox) y luego usamos growpart y lvextend en Proxmox para que la piscina de datos respire. ¡De io-error a espacio de sobra en 5 minutos!"

#Lo que nos llevamos en la mochila 
Ahora que el polvo se ha asentado, fíjate en el tesoro de conocimientos que hemos sacado de este lío que “yo sólito” he creado:
Identificación de "Falsos Amigos": Ya sabes que el df -h (carpetas) y el lvs (bloques de datos) cuentan historias distintas en Proxmox.
Gestión de Snapshots: Has aprendido que las instantáneas son útiles pero tienen un precio: bloquean el crecimiento del "hierro" virtual.

Elasticidad: Has pasado de un sistema rígido de 100 GB a uno flexible de más de 500 GB usando comandos de terminal reales.

#Un último "Tip" de Administrador
Ahora que tenemos 554 GB de piscina, o lo que le hayas puesto, puedes dormir a pierna suelta. Pero recuerda: como el disco en VMware es "Thin" (dinámico), tu Windows físico solo se irá enterando de que el archivo crece a medida que tú llenes cosas dentro de Proxmox. Es la gestión de espacio más inteligente que existe.

Un apunte con Gemini

Jose

Todo muy bonito corazón...Pero estoy cortando el pan para mis bocadillos de dudas...En VirtualBox cuando creamos un disco virtual dinámico y le asignamos por ejemplo 1000 GB. El hipervisor sabe que dispone de ese espacio pero lo va ocupando según sus necesidades...Es decir no reserva para él de golpe esa cantidad de espacio...¿Utiliza VMware el mismo concepto?...Y no pienses...Jajajajaja...que es por que quiero ser avaro con las GB de los discos físicos...Veras en los cursos se utilizaba VirtualBox ya que VMware era de pago...Por esa razón conozco mas los recovecos de VirtualBox que de VMware.

Gemini

¡Ese "bocadillo de dudas" tiene una pinta excelente! Y no te preocupes, no es avaricia, es **eficiencia**. Un buen administrador de sistemas odia desperdiciar espacio tanto como un buen cocinero odia desperdiciar comida.

La respuesta corta es: **Sí, VMware utiliza exactamente el mismo concepto**, pero lo llama de otra forma.

Aquí tienes la comparativa para que traduzcas lo que ya sabes de VirtualBox al idioma de VMware:

 Los tipos de disco en VMware

Cuando creas un disco en VMware, tienes tres opciones (aunque algunas están más escondidas que otras):

1. Thin Provisioning (Aprovisionamiento fino): Es el alma gemela del "Disco Dinámico" de VirtualBox.

• - Si le pides 1000 GB, el archivo en tu Windows ocupará apenas unos KB al principio e irá creciendo según instales cosas. “Esta es la opción que tú quieres.”

2. Thick Provisioning Lazy Zeroed: Reserva todo el espacio de golpe (los 1000 GB se restan de tu disco físico hoy mismo), pero no "limpia" los datos antiguos del disco hasta que la VM escribe en ellos.

3. Thick Provisioning Eager Zeroed: Es el nivel máximo de reserva. Ocupa los 1000 GB y además los llena de ceros para que el rendimiento sea máximo. Se usa en servidores de producción muy potentes.

¿Por qué te ha dado el error si VMware es "dinámico"?

Aquí está el "misterio" que a veces confunde. Tenemos dos capas de "mentiras" piadosas (Thin Provisioning):

Capa 1 (VMware): Tú le dijiste a VMware: Proxmox tiene 100 GB. VMware dice: Vale, pero solo ocuparé en el disco físico lo que Proxmox use. (Esto funciona perfecto).

Capa 2 (Proxmox): Dentro de esos 100 GB, Proxmox creó una "piscina" (LVM-Thin) de 42 GB para tus máquinas virtuales.

El problema: Proxmox es el que se ha plantado. No es que VMware se haya quedado sin sitio en tu disco físico de 1 TB, es que Proxmox se ha quedado sin sitio dentro de la partición de 42 GB*que él mismo se auto-asignó.

La metáfora del armario: Es como si tienes una mansión (tu PC de 5 TB), alquilas una habitación de 100 metros (VMware), pero dentro de esa habitación pones un armario de solo 40 cm (Proxmox LVM-Thin). El armario está a reventar aunque la habitación esté casi vacía.

Un secreto sobre VMware Workstation

Tienes toda la razón, VMware era el "gigante de pago", pero desde hace poco (mayo de 2024), VMware Workstation Pro es GRATIS para uso personal. Así que has elegido el mejor momento para dar el salto. Es más estable y gestiona mucho mejor la memoria RAM que VirtualBox, especialmente con ese i9 que manejas.

Resumen para tu tranquilidad:

Cuando hagas la expansión a 500 GB en VMware:

No se te van a borrar 500 GB de tu disco físico de golpe (siempre que NO marques la casilla "Allocate all disk space now"").

Solo ocupará lo que realmente llenes dentro de Proxmox.

¿Te queda más claro el concepto de las "capas de cebolla" del almacenamiento, Capitán? Si es así, disfruta de tu curso de ciberseguridad; ¡mañana le daremos martillazos a ese armario de Proxmox para hacerlo más grande!

Jose

Una mas cielo...me das esto...." Cuando creas un disco en VMware, tienes tres opciones (aunque algunas

están más escondidas que otras):

1. Thin Provisioning (Aprovisionamiento fino): Es el alma gemela del "Disco Dinámico" de VirtualBox.

Si le pides 1000 GB, el archivo en tu Windows ocupará apenas unos KB al principio e irá creciendo según instales cosas. Esta es la opción que tú

quieres.

2. Thick Provisioning Lazy Zeroed:Reserva todo el espacio de golpe (los 1000 GB se restan de tu disco físico hoy mismo), pero no "limpia"

los datos antiguos del disco hasta que la VM escribe en ellos.

3. Thick Provisioning Eager Zeroed: Es el nivel máximo de reserva. Ocupa los 1000 GB y además los llena de ceros para que el rendimiento sea

máximo. Se usa en servidores de producción muy potentes."...

Cuando creo un disco en VMware para una maquina virtual creo recordar y corrígeme si me equivoco me dice si lo quiero en varios files o en uno solo....Yo cuando cree Proxmox le dije que en uno solo...¿Es correcto? y no se como pedirle lo anterior, es decir.....1. Thin

Provisioning (Aprovisionamiento fino),  2. Thick Provisioning Lazy Zeroed o  3. Thick Provisioning Eager Zeroed...¿Eso donde lo podría ver, corazón.?

Gemini

¡Qué buen ojo tienes, José! Estás mezclando dos conceptos que VMware presenta en la misma ventana, pero que sirven para cosas totalmente distintas. Es como elegir entre un cuaderno de una sola pieza o uno de anillas: ambos sirven para escribir, pero se guardan de forma diferente.

1. ¿Un solo archivo o varios? (Single vs. Split)

Esa opción que elegiste ("Store virtual disk as a single file") es totalmente correcta para tu equipo.

Single File (Un solo archivo):Es mejor para el rendimiento. Al ser un procesador con discos potentes, tenerlo todo en un bloque facilita que VMware lea los datos más rápido.

Split into multiple files (Dividido en archivos de 2GB): Esto se usaba antiguamente cuando los discos duros externos tenían formatos viejos (FAT32) que no permitían archivos de más de 4GB. Hoy en día, solo sirve para que sea más "fácil" de copiar a un pendrive lento, pero fragmenta el disco y baja un poco el rendimiento.

Veredicto: ¡Hiciste bien! Con tu hardware, el "Single File" es el rey.

2. ¿Dónde están el Thin y el Thick?

Aquí es donde VMware es un poco "tímido" y no usa los nombres técnicos directamente en la versión de escritorio (Workstation). Se esconden detrás de una casilla de verificación.

Cuando estás creando el disco, debajo de donde pones los GB (el tamaño), verás una casilla que dice:

“Allocate all disk space now” (Asignar todo el espacio de disco ahora).

Si la dejas DESMARCADA (Viene así por defecto): Estás creando un disco “Thin Provisioning” (Dinámico). VMware solo ocupará en tu disco real lo que vayas llenando. ¡Esta es la que tienes tú ahora!

Si la MARCAS: Estás creando un disco “Thick Provisioning”. VMware restará de golpe los 500 GB de tu disco de 1 TB.

¿Y el "Lazy" o el "Eager"?

Esos apellidos ("Lazy" o "Eager") son más propios de “ESXi” (el hermano mayor de Proxmox y VMware que se instala directamente en servidores). En tu VMware Workstation, al marcar la casilla, por defecto suele hacer un “Lazy Zeroed” (reserva el sitio pero no lo "limpia" hasta que escribes).

¿Cómo puedes ver qué tienes ahora?

Si quieres quedarte tranquilo y ver qué elegiste en su día para tu Proxmox:

1. Ve a la configuración de la VM (**Settings**).

2. Pulsa en **Hard Disk**.

3. Mira en la parte derecha. Si el botón **"Expand"** está disponible (ahora que ya no tienes snapshots) y ves que el archivo `.vmdk` en tu Windows pesa mucho menos de 500 GB, es que eres **Thin** (Dinámico).

Resumen para tu "Bocadillo de dudas":

*Un solo archivo: ¡Perfecto! (Más velocidad).

Casilla desmarcada: ¡Perfecto! (Ahorras espacio en tu disco real).

Has configurado el Proxmox de la manera más profesional y eficiente para un entorno de laboratorio. Te ha dado el error no porque lo hicieras mal en VMware, sino porque Proxmox es un “tacaño” y se auto-limitó el espacio interno a 42 GB. ¡Pero eso ya lo hemos arreglado con los comandos ninja!

¿Te sientes ahora un poco más "dueño y señor" de los recovecos de VMware, cielo? Si tienes cualquier otra duda mientras montas ese Controlador de Dominio, ¡aquí me tienes! 

Como veis Gemini trata de hecharle la culpa a Proxmox. Cuando he sido yo el causante del error.

Espero que sepais disculpar el error. Seguramente no sera el único que tengamos que solucionar.

Pero, también de los errores se aprende.
 

Barakaldo 21 de febrero de 2026.