Con la VM apagada:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

modprobe nbd max_part=16
qemu-nbd --connect=/dev/nbd0 /var/lib/vz/images/100/vm-100-disk-0.qcow2   # añade -r para solo lectura
partprobe /dev/nbd0
lsblk /dev/nbd0                                  # nbd0p1, nbd0p2…
mount /dev/nbd0p2 /mnt/vm

# ... leer, copiar o reparar ...

umount /mnt/vm
qemu-nbd --disconnect /dev/nbd0

Sin el --disconnect la VM no vuelve a arrancar: QEMU se encuentra la imagen bloqueada.

Por qué nbd

Un .qcow2 no es un volcado del disco: tiene cabecera, tabla de clusters, snapshots internos y a veces un archivo base detrás. losetup no lo entiende. qemu-nbd sí, y lo publica como un dispositivo de bloques a través del cliente NBD del kernel; a partir de ahí es un disco más para lsblk, mount, fsck o dd.

max_part importa: sin él el kernel no crea los nodos nbd0p1, nbd0p2… partprobe los fuerza si tras el --connect no aparecen.

Si el disco de la VM lleva LVM

Lo normal en Ubuntu Server, RHEL y Fedora: dentro de la partición hay un VG. Actívalo, monta el LV y, al terminar, desactívalo antes de desconectar:

1
2
3
4
5
6
7
8

vgscan
vgchange -ay                                   # activa lo que encuentre en nbd0
lvs                                            # ubuntu-vg/ubuntu-lv, rhel/root…
mount /dev/ubuntu-vg/ubuntu-lv /mnt/vm

umount /mnt/vm
vgchange -an ubuntu-vg
qemu-nbd --disconnect /dev/nbd0

Trampa clásica: el host tiene un VG con el mismo nombre que el de la VM (ubuntu-vg contra ubuntu-vg, pve contra pve). LVM se niega a activar dos iguales. La herramienta para eso es vgimportclone, que renombra el VG del disco importado sin tocar el del host:

1
2

vgimportclone -n vm100-vg /dev/nbd0p3
vgchange -ay vm100-vg

Si prefieres no cambiar nada dentro de la VM, guestmount (abajo) resuelve el LVM por su cuenta y no toca el LVM del host.

Windows, NTFS y snapshots internos

• NTFS: mount -t ntfs3 /dev/nbd0p3 /mnt/vm (kernel 5.15+) o ntfs-3g. Si Windows quedó hibernado o con Fast Startup, NTFS solo se deja montar en lectura; apágalo bien desde dentro antes de escribir.
• Snapshot interno de qcow2 (qemu-img snapshot -l vm.qcow2): qemu-nbd -r -l antes-del-cambio --connect=/dev/nbd0 vm.qcow2 monta el estado de ese snapshot, solo lectura, sin tocar el disco actual.
• Otros formatos: qemu-nbd habla también vmdk, vhdx y vdi (-f vhdx si no lo detecta); qemu-img convert -O raw es la alternativa si vas a trabajar mucho tiempo con la imagen.

guestmount: lo mismo sin nbd ni root

libguestfs monta la imagen por FUSE, detecta particiones y LVM solo, y no interfiere con el host:

1
2
3
4

apt install libguestfs-tools          # dnf install guestfs-tools en Fedora/RHEL
virt-filesystems --long -h --all -a vm.qcow2      # qué hay dentro
guestmount -a vm.qcow2 -i --ro /mnt/vm            # -i: monta el sistema operativo que encuentre
guestunmount /mnt/vm

Más lento que nbd para copiar gigas, pero imposible de dejar mal cerrado.

Trampas

• Nunca con la VM encendida. En escritura corrompes el sistema de archivos con seguridad; en -r ves un estado inconsistente (lo que el guest tiene en caché no está en disco). Si necesitas mirar una VM viva, haz un snapshot y monta el snapshot.
• La imagen queda bloqueada mientras qemu-nbd esté conectado: qm start 100 falla con Failed to get "write" lock. qemu-nbd -d /dev/nbd0 lo suelta; ls /sys/block/nbd*/pid dice cuáles siguen en uso.
• --disconnect con “device busy”: queda algo montado o un VG activo (vgchange -an). lsof /dev/nbd0* lo encuentra.
• Proxmox con LVM-thin o ZFS no necesita nbd: el disco de la VM ya es un dispositivo de bloques (/dev/pve/vm-100-disk-0, /dev/zvol/rpool/data/vm-100-disk-0); kpartx -av sobre él saca las particiones. qemu-nbd es para qcow2 en storages de directorio y NFS.
• Archivos base: una imagen con backing file se monta igual; lo que escribas va a la capa superior. No muevas la base mientras esté conectada.

Ver también: convertir una máquina física a VHDX y el import de discos en Proxmox. Referencia: qemu-nbd en la documentación de QEMU.

System → Advanced → Networking → Disable hardware checksum offload ✔ → Save → reinicia la VM. La GUI no avisa, pero el cambio no aplica a las interfaces vtnet hasta el reinicio.

Para probar sin reiniciar (se pierde al arrancar):

1
2

ifconfig vtnet0 -rxcsum -txcsum -tso -lro
ifconfig vtnet1 -rxcsum -txcsum -tso -lro

En OPNsense: Interfaces → Settings → Hardware CRC → Disable hardware checksum offload, y el mismo reinicio.

Síntomas

La VM arranca, las interfaces están UP, el DHCP de la LAN reparte direcciones y aun así:

• Los equipos detrás del firewall no llegan a Internet, o la conexión se queda a medias (el ping pasa, TCP se cuelga).
• Desde el propio host de virtualización o desde otras VMs del mismo host no se llega a nada protegido por pfSense, ni a la GUI.
• Cambiar la NIC de la VM a e1000 lo arregla al momento, lo que confirma el diagnóstico.

Por qué pasa

El driver vtnet de FreeBSD, con el offload de checksums activado, entrega a la pila de red paquetes cuyo checksum nunca llegó a calcularse: entre VMs del mismo host, y entre el host y la VM, el tráfico no pasa por una NIC física que lo haga. FreeBSD ve checksums inválidos y descarta (bug 165059 de FreeBSD). Netgate lo documenta en VirtIO Driver Support.

pfSense intenta marcar la opción solo cuando detecta interfaces vtnet en la instalación. Si la NIC VirtIO se añadió después, si restauraste el config.xml de un firewall físico, o si migraste la VM desde otro hipervisor con otro tipo de NIC, la opción sigue apagada.

Procedimiento

1. System → Advanced → Networking, sección Network Interfaces:

   • Disable hardware checksum offload: marcar.
   • Disable hardware TCP segmentation offload y Disable hardware large receive offload: ya vienen marcadas por defecto; déjalas así.

2. Save.

3. Reboot desde Diagnostics → Reboot. Sin este paso, nada cambia en vtnet.

4. Comprueba:

   1	ifconfig vtnet0 | grep options

   No deben aparecer RXCSUM ni TXCSUM (ni TSO4, LRO).

Si sigue igual

• Todas las NICs de la VM tienen que ser del mismo estilo. Una vtnet con offload y otra e1000 se comportan distinto; revisa cada ifconfig.
• Offload en el host. Netgate señala que a veces también hay que apagar checksums y TSO en el hipervisor. En Proxmox/KVM, sobre la interfaz tap de la VM: ethtool -K tap100i0 tx off (el número es el VMID y i0 la NIC). Es raro necesitarlo; pruébalo el último.
• Plan B: modelo de NIC e1000 en la VM. Menos rendimiento que VirtIO sin offload, pero sin este bug.

Trampas

• El reinicio no es opcional y la GUI no lo pide. Es la causa número uno de “lo marqué y sigue sin funcionar”.
• No es un problema de reglas. Con el offload activo, los paquetes se descartan antes de llegar a pf; el log del firewall no muestra nada.
• e1000 también en OPNsense como plan B; el ajuste equivalente está en Interfaces → Settings.
• Multiqueue (queues=N en Proxmox) funciona bien con vtnet una vez desactivado el offload; no lo confundas con la causa.

1
2
3

rw
kvmd-edidconf --import-preset=v3.1080p-by-default --apply    # V3, y DIY V0–V2 con su preset (v0, v1, v2)
ro

Después, reinicia el host o desconecta y reconecta el HDMI: el EDID solo se lee cuando el host detecta el monitor. En V4 Mini y V4 Plus no hace falta nada de esto: capturan 1080p a 60 Hz de fábrica.

Por qué

El PiKVM se presenta ante el host como un monitor, y lo que ese monitor “sabe hacer” va en el EDID: resoluciones, frecuencias y cuál es la preferida. El host elige a partir de eso.

El V3 (y los DIY con el capturador CSI TC358743) tiene un límite de hardware: 1080p solo a 50 Hz. Como 50 Hz es una frecuencia poco habitual, el EDID por defecto marca 720p60 como modo preferido y muchos hosts se quedan ahí. Es correcto para la mayoría, pero algunos sistemas se ven mal en 720p: la consola de Proxmox, algunos BIOS, escritorios que escalan raro. El preset v3.1080p-by-default mantiene los mismos modos pero pone 1080p50 como preferido.

Comprobar

1

kvmd-edidconf                 # sin argumentos: fabricante, producto, serie, nombre y audio del EDID actual

En la interfaz web, el indicador de video muestra la resolución y los fps que está capturando; tras el reinicio del host debe decir 1920x1080 y 50. Si el host tiene una utilidad de pantalla (xrandr, Configuración de Windows), el “monitor” aparecerá con el nombre del EDID.

Otros ajustes del EDID

Windows guarda la configuración por monitor usando fabricante, producto y serie. Si el host sigue en un modo viejo después de cambiar el EDID, cámbiale la identidad para que lo trate como un monitor nuevo:

1
2
3

rw
kvmd-edidconf --set-monitor-name=PIKVM --set-mfc-id=PKV --set-product-id=34953 --set-serial=1234567890 --apply
ro

• --set-audio=1 anuncia audio por HDMI (para capturar sonido en los modelos que lo soportan).
• En V4 Plus, con un monitor real conectado a la salida OUT2, --import-display-ids copia su identidad al EDID del PiKVM.
• Volver al original: kvmd-edidconf --import-preset=v3 --apply (o v4mini, v4plus según el modelo).

Trampas

• rw antes, ro después. El sistema de archivos del PiKVM es de solo lectura; sin rw el cambio no se guarda y sin ro te lo recuerda en cada login.
• El host tiene que releer el EDID. --apply aplica en el PiKVM al instante, pero el host no se entera hasta un reinicio, un reconectar de cable, o en algunos BIOS solo en el POST.
• 50 Hz en V3 no es un fallo, es el límite del capturador. Para 60 Hz, V4.
• Pantalla negra tras un EDID a mano: vuelve a importar el preset del modelo y aplica.
• Proxmox y otras consolas de framebuffer fijan el modo al arrancar; después de cambiar el EDID hay que reiniciar el nodo, no solo la sesión.

Referencia: EDID en la documentación de PiKVM.

1
2

qm set 102 --cpu x86-64-v2-AES    # o x86-64-v3 si todos los hosts son Haswell / EPYC o más nuevos
qm stop 102 && qm start 102       # un reboot desde dentro de Windows NO aplica el cambio

Síntomas

Windows 10, 11 o Server con cpu: host: arranque lento, escritorio a tirones, congelamientos de segundos, todo lo que toque memoria va mal. La misma VM con x86-64-v2-AES responde normal. Una VM Linux con host en el mismo nodo no nota nada.

Por qué pasa

host le pasa a la VM todos los flags del CPU físico, incluidos dos que existen para las mitigaciones de vulnerabilidades de Intel:

Dentro de una VM esas operaciones salen carísimas. Las mediciones del hilo original en el foro de Proxmox: en un Xeon E5-2667 v2 la latencia de lectura de RAM pasa de ~100 ns a ~2000 ns; en un i9-13900K, de 30 a 90 ns. Windows, que toca memoria del kernel todo el tiempo, se arrastra.

Los tipos genéricos (x86-64-v2-AES, x86-64-v3, IvyBridge-IBRS, …) no exponen esos dos flags, así que Windows ni ve la vulnerabilidad ni enciende la mitigación.

Qué tipo elegir

Elige el más alto que soporten todos los nodos del clúster:

1

grep -o -w -E 'avx2|avx512f' /proc/cpuinfo | sort -u   # avx2 → v3 ok; avx512f → v4 ok

Es la recomendación del staff de Proxmox en ese mismo hilo: usar el x86-64-v* que corresponda al hardware en vez de apagar flags de seguridad a ciegas.

Si insistes en host

Hay casos en los que host hace falta: virtualización anidada (Hyper-V, WSL2 dentro de la VM, un lab de ESXi), porque los tipos x86-64-v* no exponen vmx/svm. Puedes quitar md_clear con la opción flags:

1

qm set 102 --cpu host,flags=-md-clear

Pero flush_l1d no está en la lista de flags que Proxmox deja tocar, así que te quedas con la mitad del problema. Y ocultarle mitigaciones al guest es una decisión de seguridad: razonable en un nodo de un solo dueño, no en uno con inquilinos que no controlas.

Comprobar desde dentro de Windows

El módulo oficial de Microsoft muestra qué mitigaciones tiene activas el guest:

1
2

Install-Module SpeculationControl -Scope CurrentUser
Get-SpeculationControlSettings

Con host, MDSWindowsSupportEnabled y L1TFWindowsSupportEnabled salen True; con x86-64-v2-AES, False. Es la forma rápida de confirmar que el cambio aplicó.

Trampas

• El cambio pide stop/start. El tipo de CPU se fija al lanzar el proceso QEMU; un reinicio desde dentro del guest no lo toca.
• Es un tema de Intel. md_clear y flush_l1d no existen en AMD; con host en EPYC/Ryzen no verás esta caída (aunque host sigue impidiendo migrar entre CPUs distintos).
• Aplica a VMs nuevas también. Las plantillas creadas con host heredan el problema; cámbialo en la plantilla.
• Con ambos tipos Windows sigue seguro contra lo que importa dentro de una VM: las mitigaciones que cuentan (Spectre v2, etc.) siguen activas; lo que desaparece es la doble mitigación de vulnerabilidades que ya mitiga el host.

Referencias: hilo del foro de Proxmox y la sección CPU de la guía de administración.