Synology VDSM: Migración de Docker con IA y redimensionamiento de un disco virtual (2026)

Un NAS virtual es una de esas funciones que la gente instala una vez, trastea un rato y luego se olvida de que la tiene. Es una lástima, porque Synology VDSM —Virtual DSM, ejecutándose dentro de Virtual Machine Manager— resuelve discretamente dos de los problemas más molestos del autoalojamiento a pequeña escala. El primero es que mover una pila Docker entre máquinas normalmente cuesta una tarde de trabajo minucioso. El segundo es que cuando un disco virtual se queda sin espacio, la mayoría de la gente asume que tiene que reconstruirlo todo. Ninguna de las dos cosas es cierta en VDSM. Esta guía describe una migración real que realizamos en unos treinta y cinco minutos: un sistema interno de seguimiento de incidencias Redmine con cinco complementos, extraído de una máquina virtual VDSM e instalado en otra, con un asistente de IA controlando la consola. En el proceso, la máquina de destino se quedó sin espacio en disco, así que ampliamos su disco virtual de 10 GB a 20 GB y continuamos. Todo lo que se describe a continuación es lo que realmente sucedió, incluyendo el error que habría destruido la aplicación silenciosamente.

Punto SynoPower Club:He visto a mucha gente descartar la virtualización en un NAS porque asumen que es para laboratorios y no para trabajo real. La migración descrita en este artículo fue un trabajo real —un sistema de gestión de incidencias que tres compañeros usan a diario— y lo que me sorprendió no fue la IA, sino la sencillez de VDSM. No requiere licencia de hipervisor, ni servidor de gestión independiente, ni complicados procesos de exportación e importación entre formatos incompatibles. El sistema operativo invitado se quedó sin espacio en disco a mitad del proceso y lo solucioné introduciendo un número mayor en un campo de texto mientras seguía ejecutándose. Todo el proceso duró treinta y cinco minutos y la única interrupción que se notó fue de noventa segundos en una página web ajena. Si ya tienes un Synology con memoria libre, solo te falta instalar un paquete para lograrlo.

¿Qué es Synology VDSM?

VDSM es el equivalente a Virtual DSM de Synology: una copia completa de DiskStation Manager que se ejecuta como sistema operativo invitado dentro de Virtual Machine Manager en un NAS físico. Se comporta como un NAS independiente: tiene su propia dirección IP, su propio inicio de sesión de DSM, sus propios paquetes y su propio gestor de contenedores. Desde el punto de vista de la red, simplemente hay otro Synology en la LAN. Desde el punto de vista del hardware, es un proceso más en un dispositivo que ya has pagado.

La principal ventaja práctica reside en el aislamiento. Si se ejecutan todos los servicios directamente en el host, un contenedor con un comportamiento anómalo puede colapsar el servidor de archivos del que depende toda la oficina. Al dividir las cargas de trabajo entre las máquinas virtuales VDSM, cada una tiene un límite de memoria, una asignación de CPU y un disco propio, y permite reiniciar una sin afectar a las demás.

Cada NAS que admite Virtual Machine Manager incluye una licencia VDSM sin costo. Ejecutar un segundo invitado y los subsiguientes requiere una Licencia Virtual DSM de pago cada uno. Esa única instancia gratuita es suficiente para seguir todo lo que se explica en este artículo, y es por eso que muchas personas ya poseen la capacidad y nunca la han activado. Si necesita agregar, asignar o desasignar una licencia más adelante, tenemos un tutorial sobre gestión de licencias VDSM.

VDSM y Virtual DSM son dos nombres para lo mismo. La documentación de Synology utiliza la forma completa, mientras que la mayoría de los usuarios utilizan la abreviada. Esta abreviatura también se comparte con un componente independiente del proyecto de virtualización oVirt, por lo que en un NAS Synology siempre se refiere a Virtual DSM.

Una licencia de pago funciona de forma diferente a lo que la mayoría espera. Cada una añade una máquina virtual más e incluye tres años de actualizaciones de software para Virtual DSM. La máquina virtual nunca caduca. Tras los tres años, sigue funcionando sin nuevas actualizaciones. Al activar una nueva clave, se inician otros tres años de actualizaciones. Una clave solo puede estar activa en un NAS Synology a la vez, y el NAS debe estar en línea al añadirla.

Los requisitos para un invitado VDSM son modestos, y Synology los enumera en su Especificaciones Virtual Machine Manager:

• El disco virtual debe estar en un volumen Btrfs. Virtual Machine Manager no almacena invitados en ext4.
• El propio NAS necesita más de 2 GB de memoria antes de poder ejecutar cualquier máquina virtual.
• Cada máquina virtual necesita al menos 1 GB de memoria, y las cargas de trabajo reales requieren más.
• La cantidad de invitados que un modelo puede ejecutar cómodamente depende de su CPU y de la memoria instalada.

Un sistema invitado no es idéntico a DSM en hardware físico. Faltan tres cosas, todas ellas vinculadas al hardware físico:

• La función de paso directo a través de USB no está disponible, por lo que un dispositivo conectado a un puerto USB del NAS no se puede entregar al sistema invitado.
• Las páginas Dispositivos externos y Hardware y alimentación del Panel de control no están disponibles.
• Los adaptadores inalámbricos, la configuración de MTU y la agregación de enlaces (LACP) no son compatibles dentro del sistema invitado. El sistema anfitrión gestiona la red física.

Nada de eso afecta a las razones habituales para usar uno. Los servicios de archivos, Docker, un servidor de correo o una copia de prueba de un sistema de producción se comportan igual que en un NAS independiente.

Synology VDSM frente a un segundo NAS físico: ¿Cuál necesitas?

La comparación honesta no es que lo virtual sea mejor. Se trata de sacrificar la resiliencia por la flexibilidad. Un segundo servidor físico sobrevive al fallo del primero; una máquina virtual VDSM no. Lo que una máquina virtual ofrece, en cambio, es la capacidad de crear, redimensionar, crear instantáneas y mover un servidor completo en minutos en lugar de días.

	Invitado de VDSM	Segundo NAS físico
Costo de agregar uno	Gratis para el primer invitado, después se requiere licencia.	Un NAS completo más discos duros
Tiempo para abastecerse	Minutos	Días, una vez contado el envío
Cambiar el tamaño de la CPU, la RAM o el disco	Edita un campo, reinicia el invitado	Compre hardware nuevo
Sobrevive a fallos de hardware del host	No	Sí
Instantánea y clon	Integrado en Virtual Machine Manager	No aplicable
Trasladarse a otro NAS	Migrar o replicar el invitado	Reubicarlo físicamente
Lo mejor para	Aislamiento de servicios, preparación, consolidación de servidores pequeños	Objetivos de respaldo y redundancia real

Para este trabajo, la elección fue obvia. Estábamos consolidando un sistema de seguimiento de incidencias poco utilizado, que contaba con una máquina virtual VDSM propia, en una máquina virtual que ya ejecutaba un sitio web con capacidad disponible. No se necesita hardware nuevo. Solo diez minutos y un poco de atención.

Lo que necesitas antes de empezar

Antes que nada, dale al asistente su propio nombre de usuario en lugar de darle el tuyo. En DSM, abre el Panel de control, ve a Usuarios y grupos y haz clic en Crear. Asígnale un nombre inconfundible; nosotros usamos Claude con la descripción Control de IA — y deja que DSM genere una contraseña aleatoria segura.

En la siguiente pantalla, marque administradores. Esto no es opcional: DSM solo permite que los miembros del grupo de administradores inicien sesión mediante SSH, por lo que una cuenta ajena a dicho grupo no podrá acceder a la consola. Repita el mismo procedimiento en ambas máquinas virtuales VDSM y, a continuación, asegúrese de que SSH esté activado en el Panel de control, Terminal y SNMP.

Cuando el trabajo esté terminado, desactive la cuenta. Esa es precisamente la razón de crear una cuenta independiente. Edita el usuario en el Panel de control y desactívalo, o elimínalo por completo; el acceso se revoca con un solo clic sin modificar tus credenciales, y todo lo que hizo el asistente se asocia a una cuenta creada específicamente para ese fin. Dejar una cuenta de administrador permanentemente habilitada solo porque resultó conveniente en su momento es la forma en que las pequeñas propiedades acumulan accesos que nadie recuerda haber otorgado.

Dos máquinas virtuales VDSM, con SSH habilitado en ambas y Container Manager instalado en el destino. También es importante saber algo que suele confundir a la mayoría: el binario de Docker no se encuentra en la ruta predeterminada dentro de DSM. Los binarios de los paquetes se ubican en el directorio del paquete, por lo que cada comando requiere la ruta completa o un alias de shell.

Compruebe que haya disponibilidad en el destino antes de comenzar el traslado, en lugar de hacerlo a mitad del proceso. Los comandos que aparecen a continuación corresponden a la comprobación previa al vuelo y son idénticos para cualquier usuario de VDSM.

Una cosa más antes de nada: Toma una instantánea de ambos huéspedes en Virtual Machine Manager.. Las instantáneas están disponibles en la edición gratuita de Virtual Machine Manager, no solo en la Pro, y permiten guardar hasta 32 por máquina virtual. Una instantánea de VDSM captura la máquina completa, de modo que si una importación falla o un comando realiza una acción no deseada, se restaura la máquina virtual en lugar de reconstruirla. Solo toma unos segundos y es la medida de seguridad más económica de todo el proceso. Crea una instantánea tanto en el origen como en el destino, ya que el origen es tu respaldo.

# Docker no está en PATH en DSM; use la ruta completa D=/volume1/@appstore/ContainerManager/usr/bin/docker # ¿Qué se está ejecutando y de qué está construido? sudo $D ps -a sudo $D images # ¿Cuánto espacio queda en el volumen de destino? df -h /volume1 # ¿Cuánta memoria libre tiene realmente el invitado de destino? free -m

Migración de VDSM a Docker en 4 pasos

Estos son los cuatro pasos que ejecutamos, y funcionan para cualquier pila de contenedores que necesite transferir entre máquinas virtuales VDSM. El orden es importante: primero se detiene el contenedor de la aplicación para evitar que se escriba nada en la base de datos durante el volcado, y el contenedor de la base de datos permanece activo para que el volcado se realice correctamente.

Por qué el archivo Compose no es el contenedor completo

Aquí está la trampa, y vale la pena mencionarla por sí sola. El archivo de configuración de nuestro stack de Redmine declaraba dos montajes de enlace: uno para los archivos subidos y otro para la base de datos. Si lees ese archivo, podrías concluir, lógicamente, que recrear el stack en la nueva máquina virtual implicaba copiar dos directorios y ejecutar `docker compose up`.

No fue así. Cinco complementos, las gemas Ruby que estos complementos utilizaban, la configuración de correo y varios archivos de inicialización modificados se habían instalado directamente en el contenedor en ejecución a lo largo de los años. Nada de esto estaba en un volumen. Un solo comando nos indicó la gravedad de la situación.

# ¿Cuántos archivos difieren entre el contenedor y la imagen de la que proviene? sudo $D diff Redmine | wc -l 6764 # Plugins que residen dentro del contenedor, sin respaldo de ningún volumen sudo $D exec Redmine ls /usr/src/redmine/plugins

Descargar una imagen oficial nueva habría generado un contenedor sin ninguno de esos complementos, conectado a una base de datos que aún conservaba las 144 tablas creadas por sus migraciones. La aplicación no habría fallado de forma evidente. Habría comenzado, funcionado casi correctamente y luego fallado de maneras muy difíciles de diagnosticar. Confirmar el contenedor en ejecución en una imagen evita el problema por completo, aunque a costa de una transferencia mayor. En una LAN entre dos máquinas virtuales VDSM, ese tiempo es de aproximadamente un minuto, así que conviene optar por esta opción siempre.

Cómo un equipo pequeño utiliza VDSM para consolidar servidores

El patrón que sigue esta migración es uno que la mayoría de los equipos pequeños eventualmente necesitan. A lo largo de unos años, se acumulan invitados con un solo propósito: uno para la wiki, uno para el rastreador de tickets, uno para un panel de monitoreo (la forma descrita en nuestro Recorrido por el centro de datos domésticoCada uno fue dimensionado generosamente el día de su construcción y ahora cada uno funciona a una fracción de lo que se le asignó, mientras que el servidor está sobrecargado y todo se siente un poco lento.

Consolidar con VDSM implica integrar las cargas de trabajo menos activas en una máquina virtual que ya está en funcionamiento. Nuestro sistema de seguimiento de incidencias tenía una máquina virtual completa con su propia asignación de CPU y 1 GB de memoria, para un servicio que solo tres personas utilizan unas pocas veces al día. Al trasladarlo junto a una pila web existente, se liberó esa asignación y el destino perdió aproximadamente 480 MB de memoria residente en dos contenedores.

La disciplina que garantiza la seguridad consiste en retirar correctamente el origen en lugar de dejarlo en ejecución. Configuramos los contenedores antiguos con una política de reinicio de "no", los detuvimos, dejamos un archivo de texto en el directorio explicando dónde reside ahora el servicio y apagamos la máquina virtual con el inicio automático desactivado. Esto crea un punto de reversión completo y evita que se reactive silenciosamente tras un reinicio del host y comience a aceptar escrituras que la nueva instancia nunca verá. Los duplicados divergentes son la forma clásica en que una migración ordenada se convierte en un incidente de pérdida de datos un mes después.

Redimensionar un disco virtual que se quedó sin espacio.

A mitad del proceso, el destino se quedó sin espacio. Su volumen era de 9,6 GB con 1,5 GB libres y estábamos a punto de añadir una imagen de 816 MB más 123 MB de datos de la aplicación. En un NAS físico, aquí termina el proceso hasta que lleguen nuevos discos. En VDSM, se trata de un campo de texto.

Abra la configuración del invitado en Virtual Machine Manager, vaya a la pestaña Almacenamiento, escriba el nuevo tamaño y haga clic en Aceptar. No es necesario desconectar al huésped para esto. El disco crece mientras la máquina sigue funcionando, por lo que esta experiencia es fundamentalmente diferente a la de añadir capacidad a un hardware físico. La única regla que conviene recordar es que un disco virtual solo puede crecer, nunca reducirse, así que no hay vuelta atrás y no hay motivo para ser tímido con el número de unidades.

Lo que realmente lo hace tan sencillo es lo que sucede dentro del sistema invitado. DSM expande la partición y el sistema de archivos para llenar el nuevo espacio automáticamente. No hay que ejecutar ningún asistente de Storage Manager, editar ninguna tabla de particiones, reconstruir ningún volumen ni migrar datos. Nuestro volumen pasó de 9,6 GB con 1,5 GB libres a 20 GB con 13 GB libres, y los contenedores siguieron funcionando. Este es el argumento más sólido para implementar un servicio en VDSM en lugar de en hardware físico: corregir un problema de dimensionamiento posteriormente es muy económico.

Lo que realmente hizo el asistente de IA

Conviene ser precisos, porque la afirmación de que "la IA movió mi servidor" genera demasiada y muy poca credulidad a la vez. El asistente no tenía ninguna capacidad de discernimiento milagroso. Simplemente tenía acceso a los usuarios de VDSM y actuaba de forma sistemática, algo que un humano cansado al final de su jornada laboral no suele hacer.

Lo más valioso que hizo fue ejecutar `docker diff` antes de modificar nada, detectar 6764 archivos modificados y descartar el plan obvio. Alguien que siguiera el archivo `compose` no habría tenido motivo para ejecutar ese comando. Lo segundo más valioso fue la verificación: después de la importación, contó tablas, incidencias, proyectos, entradas de diario y archivos adjuntos en ambos lados, comprobó que todos los archivos adjuntos existieran en el disco, listó las versiones de los complementos que la aplicación había registrado y confirmó que no había migraciones de base de datos pendientes. Es una lista de verificación tediosa, y las listas de verificación tediosas son precisamente lo que se suele omitir a las cinco de la tarde.

Lo que aún requería de un humano era criterio sobre las consecuencias. Reiniciar un invitado de VDSM para añadir memoria implicaba desconectar un sitio web en funcionamiento, y esa es una decisión que debe consultarse, no darse por sentada. Lo mismo ocurre con la eliminación de cualquier cosa. Trata al asistente como un par de manos muy rápidas y directas que nunca se cansan de comprobar, y guarda para ti las decisiones irreversibles.

Dónde encontrar más recursos oficiales

Virtual Machine Manager, el paquete que aloja a todos los invitados de VDSM, lleva años en DSM y está ampliamente documentado. Estos tres tutoriales explican cómo instalar el paquete, crear un invitado y la estructura general de la interfaz con la que trabajará.

Limitaciones que debes conocer antes de confiar la producción a VDSM.

En primer lugar, la memoria suele ser el factor limitante con mucha más frecuencia que la CPU. Nuestro sistema invitado de destino tenía 2 GB y ya estaba utilizando la memoria de intercambio antes de que añadiéramos nada. Una segunda aplicación y una segunda base de datos requerían aproximadamente otros 480 MB, así que aumentamos la memoria a 4 GB. Compruebe la memoria libre en el sistema de destino antes de planificar la migración, no después.

En segundo lugar, un disco virtual VDSM crece, pero nunca se reduce. Si se aprovisiona en exceso, no se puede recuperar el espacio modificando el campo; la única forma de obtener un disco más pequeño es crear una nueva máquina virtual y migrar a ella. Elija un número con el que siga estando satisfecho dentro de dos años.

En tercer lugar, las licencias. Se incluye un invitado con el NAS; cada invitado adicional necesita su propia licencia. Licencia Virtual DSM. La agrupación en varias unidades NAS, la migración en vivo y la retención de instantáneas más amplia son VMM Pro características en lugar de las estándar. Si su plan de consolidación implica dividir a un huésped ocupado en cuatro huéspedes ordenados, calcule el costo antes de diseñarlo.

Evaluar correctamente a un huésped es una tarea en sí misma: Cómo dimensionar correctamente una máquina virtual de producción con VMM Pro.

En cuarto lugar, los escenarios que se deben evitar. No coloque el disco virtual de un invitado en el mismo volumen físico donde realiza la copia de seguridad y lo llame copia de seguridad. No ejecute una base de datos con escrituras continuas intensivas en un invitado que comparte discos giratorios con un servidor de archivos con mucha actividad. No utilice VDSM como sustituto de una segunda máquina, ya que si el host falla, todos los invitados que se encuentren en él fallarán simultáneamente. Y no migre un contenedor que nunca haya inspeccionado, por las razones expuestas en la sección del archivo de composición anterior.

En quinto lugar, las credenciales. Una migración afecta a las contraseñas de la base de datos, las variables de entorno y los archivos de configuración. En nuestro caso, se movió un archivo compose que contenía credenciales de base de datos en texto plano, por lo que se colocó deliberadamente fuera del directorio raíz del servidor web. Un archivo compose que se deja dentro del directorio raíz puede ser descargado por cualquiera que adivine su nombre, y esta es una forma lamentablemente común de filtración de credenciales. Si permite que un asistente genere un script para la migración, revise dónde escribe los archivos. Y cuando termine el proceso, desactive la cuenta que creó para el asistente en lugar de dejar una sesión de administrador activa.

Sexto, crea una instantánea antes de modificar nada. Crear una instantánea de VDSM en Virtual Machine Manager solo lleva unos segundos, está disponible sin la licencia Pro y convierte prácticamente cualquier error de este artículo en una reversión de dos minutos. Es el único paso que vale la pena añadir a cualquier manual de migración, independientemente de si lo escribe una persona o un asistente.

Finalmente, verifique en lugar de asumir. Cada afirmación de este artículo se verificó con el sistema en funcionamiento: recuento de tablas en ambos lados, presencia de archivos adjuntos en el disco, versiones de complementos registradas por la aplicación, ausencia de migraciones pendientes y un reinicio completo de la pila para comprobar su correcto funcionamiento. Una migración no finaliza cuando el servicio responde, sino cuando se comprueba que sobrevive a un reinicio del invitado VDSM y cuando la copia anterior ya no puede aceptar escrituras.

Una nota sobre dónde obtener esas licencias, ya que es a lo que nos dedicamos: SynoPower Club vende licencias Synology con entrega instantánea de claves las 24 horas. Las dos que importan aquí son: Licencia Virtual DSM, que necesitas para cada huésped después del gratuito, y el Licencia VMM Pro Si desea agrupación en clústeres, migración en vivo o 255 instantáneas por invitado en lugar de 32. catálogo de licencias completas También cubre Surveillance Station y MailPlus.

Referencias

• SynoPower Club, Nuestras guías y reseñas de cámaras para el NAS Synology
• Synology — Virtual Machine Manager, la descripción general oficial del paquete que ejecuta VDSM
• Centro de conocimiento Synology — Ayuda Virtual Machine Manager, Creación de invitados y configuración
• Docker — confirmación de contenedor Docker, el comando detrás del paso uno
• Docker — guardar imagen de Docker, utilizado para transmitir la imagen entre invitados

Preguntas frecuentes