04 · en desarrollo
k0 VAMPS
Consola de operador que migra máquinas de VMware vSphere/ESXi a Proxmox VE, con parada mínima y sin depender del SDK propietario de Broadcom.
Proyecto independiente, sin afiliación con VMware/Broadcom ni Proxmox.
Sobre k0 VAMPS
k0 VAMPS (VMware Automatic Migration to Proxmox System) traslada máquinas virtuales de VMware vSphere/ESXi a Proxmox VE con parada mínima y sin depender del SDK propietario de Broadcom. Copia el disco con la VM aún encendida (siembra en caliente basada en CBT) y el corte solo mueve los bloques cambiados, así la parada depende del ritmo de cambio y no del tamaño del disco. Deja el guest realmente arrancable —drivers VirtIO, retirada segura de VMware Tools, arranque primero en SATA y cambio controlado a VirtIO SCSI, guest agent de QEMU— y conserva la red (la IP estática de Windows se recaptura en el origen y se reaplica por MAC en Proxmox). Contempla también el caso de un solo host: exporta cada VM a un bundle portátil, reinstala Proxmox en el mismo servidor y reimporta, con un candado de verificación que re-hashea cada disco antes de declarar el origen seguro para borrar. Todo se opera desde una consola web; nada del origen se modifica ni se borra hasta que tú lo dices.
Capturas
Características
Motor de migración
Migración en frío (parar, copiar, reconstruir) y en caliente (siembra incremental basada en CBT + corte de parada mínima, con re-sincronización según el ritmo de cambio). El corte copia los rangos cambiados con un pool de workers acotado, byte a byte y verificado. Nada del origen se modifica ni se borra.
Transporte de datos (3 movers, por VM)
httprange (por defecto): lee solo los rangos cambiados por la interfaz HTTP del datastore de ESXi, sin distribuir nada de Broadcom. vddk: vía rápida cuando el operador aporta las librerías. pve-import: delega en el importador de Proxmox VE 8.2+, la única vía que funciona con licencia ESXi gratuita.
Remediación del guest
Staging de drivers VirtIO (netkvm, vioscsi, viostor), retirada segura de VMware Tools, arranque en SATA y cambio controlado a VirtIO SCSI, instalación del guest agent de QEMU y traslado de firmware (BIOS/UEFI, Secure Boot, disco EFI). Evita el clásico INACCESSIBLE_BOOT_DEVICE.
Preservación de red
Linux mantiene su direccionamiento (NIC fijada por MAC, initramfs reconstruido con virtio). Windows recupera su IP estática (IPv4/gateway/DNS) reaplicada por MAC en Proxmox, con los adaptadores fantasma eliminados. No fatal por diseño: una máquina que queda en DHCP se reporta, no falla.
Reprovisión de un solo servidor
Sin destino al que migrar en vivo: exporta cada VM a un bundle autodescriptivo (qcow2/raw + manifiesto con firmware, MACs y red), reinstala Proxmox en el mismo host y reimporta. Candado de verificación previa al borrado: re-lee y re-hashea cada disco (pilla un root_squash de NFS con el origen aún vivo). Ayudas de montaje NFS/USB desde la interfaz, sin tocar fstab.
Consola de operador
Entornos con inventario en vivo, credenciales por VM con botón de comprobación (solo en memoria), registro persistente de máquinas ya migradas, lotes/programación/oleadas y notificaciones por Telegram y correo. Modos sencillo y avanzado, español e inglés, claro y oscuro.
Seguridad
- El VDDK es de licencia Broadcom y nunca se incluye: lo aporta el operador; no se redistribuye con el proyecto.
- Credenciales del guest de un solo uso, en memoria solo mientras un trabajo las necesita; nunca se escriben en disco.
- Login obligatorio: una cuenta de operador con la contraseña guardada solo como hash bcrypt (la API nunca la devuelve).
- Sesiones por cookie (HttpOnly, SameSite) en memoria; un reinicio cierra la sesión de todos.
- HTTPS con k0mig serve -tls (certificado autofirmado si no aportas el tuyo); trátala como herramienta de operador privilegiada tras tus controles de red.
- El origen nunca se modifica ni se borra sin un candado de verificación que re-hashea cada disco antes.
- Secretos fuera de la API y opción de pasarlos por entorno; el destino se autentica con un token de API de Proxmox acotable, no con root. sudo acotable a mount/umount/mkdir e instalación de paquete.
Instalación
Paquete .deb / .rpm — recomendado
Binario Go único con la consola embebida y servicio systemd. apt/dnf instalan las dependencias (qemu-img y cliente NFS), crean el usuario de servicio y arrancan la consola en el puerto 8080.
sudo apt install ./k0vamps_<version>_amd64.deb # Debian/Ubuntu sudo dnf install ./k0vamps-<version>-1.x86_64.rpm # RHEL/Fedora
Consola en http://IP_DEL_SERVIDOR:8080. Para HTTPS: k0mig serve -tls. ¿Perdiste la contraseña? k0mig passwd.
ISO autoinstalable (desatendida)
Instalación desatendida sobre disco: arranca desde la ISO (USB o una VM nueva), borra el disco de destino e instala Debian + k0 VAMPS sin preguntas, y reinicia en un appliance ya instalado cuya consola muestra la URL de acceso (https://<ip>:8080). Basada en Debian netinst (~800 MB). Ideal para bare metal o una VM dedicada.
Existe además una live ISO que arranca la consola sin instalar nada (útil para la fase de export de la reprovisión de un solo servidor), e imágenes appliance qcow2 (Proxmox) y OVA (VMware).
- estado
- en desarrollo
- stack
- Go 1.26 · govmomi · Proxmox API · CBT
- año
- 2026
- licencia
- Todos los derechos reservados
Licencia aún sin especificar: todos los derechos reservados por el autor hasta que se añada un fichero LICENSE. El VDDK de VMware, si se usa, sigue bajo la licencia propia de Broadcom y nunca se distribuye con este proyecto.