Synology VDSM: Migrando o Docker com IA e redimensionando um disco virtual (2026)

Um NAS virtual é um daqueles recursos que as pessoas instalam uma vez, mexem um pouco nele por uma tarde e depois esquecem que o têm. É uma pena, porque o Synology VDSM — Virtual DSM, executado dentro do Virtual Machine Manager — resolve silenciosamente dois dos problemas mais irritantes em auto-hospedagem de pequena escala. O primeiro é que mover um conjunto de Docker entre máquinas normalmente custa uma noite inteira de trabalho minucioso. O segundo é que, quando um disco virtual fica sem espaço, a maioria das pessoas presume que precisa reconstruir tudo. Nenhum dos dois é verdade no VDSM. Este guia descreve uma migração real que realizamos em cerca de trinta e cinco minutos: um rastreador de problemas Redmine interno com cinco plugins, removido de uma máquina virtual VDSM e instalado em outra, com um assistente de IA controlando o shell. Durante o processo, o destino ficou sem espaço em disco, então aumentamos o tamanho do disco virtual de 10 GB para 20 GB e continuamos. Tudo o que está descrito abaixo é o que realmente aconteceu, incluindo a única armadilha que teria destruído silenciosamente o aplicativo.

Ponto SynoPower Club:Já vi muita gente desistir da virtualização em um NAS por presumir que ela serve apenas para laboratórios e não para trabalho real. A migração descrita neste artigo foi um trabalho real — um sistema de tickets que três colegas usam diariamente — e o que me surpreendeu não foi a IA, mas sim a simplicidade do VDSM. Sem necessidade de licença de hipervisor, servidor de gerenciamento separado ou complicações com formatos incompatíveis. O sistema operacional convidado ficou sem espaço em disco no meio da execução e eu resolvi o problema digitando um número maior em um campo de texto enquanto o processo ainda estava em andamento. Todo o processo levou trinta e cinco minutos e a única interrupção notada foi de noventa segundos em um site não relacionado. Se você já possui um Synology com memória disponível, basta instalar um pacote para alcançar esse resultado.

O que é o VDSM Synology?

O VDSM é o Virtual DSM do Synology: uma cópia completa do DiskStation Manager executada como um sistema operacional convidado dentro do Virtual Machine Manager em um NAS físico. Ele se comporta como um NAS separado. Possui seu próprio endereço IP, seu próprio login do DSM, seus próprios pacotes e seu próprio Gerenciador de Contêineres. Do ponto de vista da rede, é simplesmente outro Synology na LAN. Do ponto de vista do hardware, é apenas mais um processo em um equipamento que você já comprou.

A vantagem prática é o isolamento. Executar todos os serviços diretamente no host pode fazer com que um contêiner com comportamento inadequado sobrecarregue o servidor de arquivos do qual todo o escritório depende. Dividir as cargas de trabalho entre máquinas virtuais VDSM garante que cada uma tenha um limite de memória, uma alocação de CPU e um disco dedicado, permitindo reiniciar uma sem afetar as outras.

Cada NAS compatível com Virtual Machine Manager inclui uma licença VDSM gratuita. A execução de uma segunda máquina virtual (seja ela inicial ou subsequente) requer uma licença adicional. Licença Virtual DSM paga cada. Essa única instância gratuita é suficiente para acompanhar tudo o que está neste artigo, e é por isso que tantas pessoas já possuem a funcionalidade e nunca a ativaram. Se você precisar adicionar, associar ou desassociar uma licença posteriormente, temos um passo a passo em Gerenciamento de licenças VDSM.

VDSM e Virtual DSM são dois nomes para a mesma coisa. A própria documentação do Synology usa a forma completa, enquanto a maioria dos usuários usa a abreviada. A abreviação também é compartilhada com um componente não relacionado do projeto de virtualização oVirt, portanto, em um NAS Synology, ela sempre significa Virtual DSM.

Uma licença paga funciona de forma diferente do que a maioria das pessoas espera. Cada licença adiciona uma máquina virtual convidada e inclui três anos de atualizações de software para o Virtual DSM. A máquina virtual nunca expira. Após os três anos, ela continua funcionando sem novas atualizações. A ativação de uma nova chave inicia mais três anos de atualizações. Uma chave fica ativa em apenas um NAS Synology por vez, e o NAS precisa estar online quando você a adiciona.

Os requisitos para um convidado VDSM são modestos, e o Synology os lista em seu manual. Especificações Virtual Machine Manager:

• O disco virtual deve estar em um volume Btrfs. O Virtual Machine Manager não armazena máquinas virtuais em ext4.
• O próprio NAS precisa de mais de 2 GB de memória para poder executar qualquer máquina virtual.
• Cada máquina virtual precisa de pelo menos 1 GB de memória para si, e cargas de trabalho reais exigem mais.
• A quantidade de máquinas virtuais que um modelo pode atender confortavelmente depende de sua CPU e da memória instalada.

Um sistema operacional convidado não é idêntico ao DSM instalado diretamente no hardware. Três elementos estão ausentes, todos relacionados ao hardware físico:

• A função USB passthrough não está disponível, portanto, um dispositivo conectado a uma porta USB do NAS não pode ser transferido para a máquina virtual.
• As páginas Dispositivos Externos e Hardware e Energia do Painel de Controle não estão presentes.
• Adaptadores sem fio, configurações de MTU e agregação de links (LACP) não são suportados na máquina virtual. O host gerencia a rede física.

Nada disso afeta os motivos usuais para usar um NAS. Serviços de arquivos, Docker, um servidor de e-mail ou uma cópia de teste de um sistema de produção funcionam exatamente como funcionariam em um NAS separado.

Synology VDSM ou um segundo NAS físico: qual você precisa?

A comparação honesta não é que o virtual seja melhor. É uma troca de resiliência por flexibilidade. Um segundo servidor físico sobrevive à falha do primeiro; uma máquina virtual VDSM não. O que uma máquina virtual oferece, em contrapartida, é a capacidade de criar, redimensionar, criar snapshots e mover um servidor inteiro em minutos, em vez de dias.

	Convidado VDSM	Segundo NAS físico
Custo para adicionar um	Gratuito para o primeiro convidado, licença para os demais.	Um NAS completo com vários discos rígidos.
Tempo para provisionamento	Minutos	Dias, após a contabilização do frete.
Redimensionar CPU, RAM ou disco	Edite um campo, reinicie o convidado	Compre hardware novo
Sobrevive a falhas de hardware do host	Não	Sim
Instantâneo e clone	Integrado ao Virtual Machine Manager	Não aplicável
Mude para outro NAS.	Migrar ou replicar o convidado	Realoque-o fisicamente.
Ideal para	Isolamento de serviços, preparação de testes, consolidação de pequenos servidores	Alvos de backup e redundância real

Para esta tarefa, a escolha foi óbvia. Estávamos consolidando um sistema de rastreamento de problemas pouco utilizado, que havia recebido uma máquina virtual VDSM dedicada, em uma máquina virtual que já executava um site e tinha capacidade ociosa. Nada disso exige hardware novo. Precisa apenas de dez minutos e um pouco de cuidado.

O que você precisa antes de começar

Antes de mais nada, dê ao assistente seu próprio login em vez de fornecer o seu. No DSM, abra o Painel de Controle, vá para Usuários e Grupos e clique em Criar. Dê um nome inconfundível — nós usamos Claude com a descrição Controle de IA — e deixe o DSM gerar uma senha aleatória forte.

Na próxima tela, marque a caixa. administradores. Isso não é opcional: o DSM permite que apenas membros do grupo de administradores façam login via SSH, portanto, uma conta fora desse grupo não poderá acessar o shell. Faça o mesmo em ambas as máquinas virtuais VDSM e, em seguida, certifique-se de que o SSH esteja ativado em Painel de Controle, Terminal e SNMP.

Quando o trabalho estiver concluído, desative a conta. Essa é a principal vantagem de criar uma conta separada. Edite o usuário no Painel de Controle e desative-o ou exclua-o completamente; o acesso é revogado com um clique, sem precisar mexer nas suas credenciais, e tudo o que o assistente fez permanece atribuído a um login criado exatamente para essa finalidade. Deixar uma conta de administrador permanentemente ativada só porque foi conveniente uma vez é como pequenas propriedades acumulam acessos que ninguém se lembra de ter concedido.

Duas máquinas virtuais VDSM, com SSH habilitado em ambas e o Container Manager instalado no destino. Você também precisa saber de um detalhe que pega quase todo mundo desprevenido na primeira vez: o binário do Docker não está no PATH padrão do DSM. Os binários dos pacotes ficam no diretório do pacote, então cada comando precisa do caminho completo ou de um alias do shell.

Verifique se há espaço disponível no destino antes de iniciar a conexão, em vez de esperar até o meio dela. Os comandos abaixo descrevem toda a verificação pré-voo e são idênticos em qualquer dispositivo convidado do VDSM.

Antes de mais nada, só mais uma coisa: Tire uma foto dos dois convidados em Virtual Machine Manager.. Os snapshots estão disponíveis na edição gratuita do Virtual Machine Manager, não apenas na Pro, e permitem armazenar até 32 snapshots por máquina virtual. Um snapshot do VDSM captura a máquina inteira, portanto, se uma importação der errado ou um comando executar uma ação inesperada, você pode reverter a máquina virtual em vez de recriá-la. Leva apenas alguns segundos e é a garantia mais barata em todo o processo. Faça um snapshot tanto na origem quanto no destino, pois a origem serve como backup.

# O Docker não está no PATH do DSM - use o caminho completo D=/volume1/@appstore/ContainerManager/usr/bin/docker # O que está em execução e a partir do que foi construído? sudo $D ps -a sudo $D images # Quanto espaço resta no volume de destino? df -h /volume1 # Quanta memória o convidado de destino realmente tem livre? free -m

Migração do VDSM para Docker em 4 etapas

Esses são os quatro passos que executamos e funcionam para qualquer conjunto de contêineres que você precise migrar entre máquinas virtuais VDSM. A ordem é importante: o contêiner da aplicação é interrompido primeiro para que nada grave no banco de dados durante o processo de despejo, e o contêiner do banco de dados permanece ativo para que o despejo seja realizado corretamente.

Por que o arquivo Compose não é o contêiner inteiro?

Eis a armadilha, e por si só já vale o preço do ingresso. O arquivo compose do nosso stack Redmine declarava duas montagens de diretórios: uma para os arquivos enviados e outra para o banco de dados. Lendo esse arquivo, você concluiria, razoavelmente, que recriar o stack na nova máquina virtual significava copiar dois diretórios e executar `docker compose up`.

Não funcionou. Cinco plugins, as gems Ruby que esses plugins utilizavam, a configuração de e-mail e vários arquivos de inicialização editados haviam sido instalados diretamente no contêiner em execução ao longo dos anos. Nada disso estava em um volume. Um único comando nos mostrou a gravidade da situação.

# Quantos arquivos diferem entre o contêiner e a imagem da qual ele veio? sudo $D diff Redmine | wc -l 6764 # Plugins residentes dentro do contêiner, sem nenhum volume associado sudo $D exec Redmine ls /usr/src/redmine/plugins

Baixar uma nova imagem oficial teria gerado um contêiner sem nenhum desses plugins, apontando para um banco de dados que ainda continha as 144 tabelas criadas pelas migrações. O aplicativo não teria apresentado uma falha grave. Ele teria iniciado, parecendo quase correto, e então apresentado problemas difíceis de diagnosticar. Ao gravar o contêiner em execução em uma imagem, o problema é completamente resolvido, ao custo de uma transferência maior. Em uma rede local entre duas máquinas virtuais VDSM, esse custo é de cerca de um minuto, então vale a pena sempre.

Como uma pequena equipe usa o VDSM para consolidar servidores

O padrão que essa migração segue é algo que a maioria das pequenas equipes eventualmente precisa. Ao longo de alguns anos, você acumula convidados com funções específicas: um para a wiki, um para o sistema de tickets e um para um painel de monitoramento (o formato descrito em nosso [link para o modelo]). Visita guiada ao centro de dados domésticoCada um deles foi dimensionado generosamente no dia em que foi construído e agora cada um opera ocioso com uma fração da capacidade original, enquanto o servidor principal está sobrecarregado e tudo parece um pouco lento.

Consolidar com VDSM significa incorporar as cargas de trabalho ociosas em uma máquina virtual já ativa. Nosso sistema de controle de chamados tinha uma máquina virtual inteira com sua própria alocação de CPU e 1 GB de memória dedicada, para um serviço acessado por três pessoas algumas vezes ao dia. Ao movê-la para perto de uma infraestrutura web existente, essa alocação foi liberada completamente, custando ao destino cerca de 480 MB de memória residente em dois contêineres.

A disciplina que torna isso seguro é a desativação adequada da origem, em vez de deixá-la em execução. Configuramos os contêineres antigos com uma política de reinicialização "não", os interrompemos, deixamos um arquivo de texto no diretório explicando onde o serviço reside agora e desligamos a máquina virtual com a inicialização automática desativada. Ela permanece como um ponto de reversão completo e não pode voltar silenciosamente à vida após uma reinicialização do host e começar a aceitar gravações que a nova instância nunca verá. Duplicatas divergentes são a maneira clássica pela qual uma migração organizada se transforma em um incidente de perda de dados um mês depois.

Redimensionando um disco virtual que ficou sem espaço

Na metade do processo, o destino ficou sem espaço. Seu volume era de 9,6 GB, com 1,5 GB livres, e estávamos prestes a adicionar uma imagem de 816 MB mais 123 MB de dados de aplicativos. Em um NAS físico, a história termina aqui até a chegada de novos discos. No VDSM, é apenas um campo de texto.

Abra as configurações do convidado no Virtual Machine Manager, acesse a guia Armazenamento, digite o novo tamanho e clique em OK. O convidado não precisa ser desligado para isso. O disco cresce enquanto a máquina continua funcionando, e é por isso que a experiência é fundamentalmente diferente de adicionar capacidade a um hardware físico. A única regra importante é que um disco virtual só pode crescer, nunca diminuir, então não há como desfazer e não há motivo para ter receio do tamanho.

O que torna tudo realmente fácil é o que acontece dentro da máquina virtual. O DSM expande a partição e o sistema de arquivos para preencher o novo espaço automaticamente. Não há assistente do Gerenciador de Armazenamento para executar, nenhuma tabela de partições para editar, nenhum volume para reconstruir e nenhum dado para migrar. Nosso volume passou de 9,6 GB com 1,5 GB livres para 20 GB com 13 GB livres, e os contêineres continuaram funcionando. Este é o argumento mais forte para colocar um serviço em um VDSM em vez de em hardware dedicado: errar o dimensionamento é barato de corrigir depois.

O que o assistente de IA realmente fez

Vale a pena ser preciso aqui, porque a afirmação "IA moveu meu servidor" inspira credulidade em excesso e em falta ao mesmo tempo. O assistente não teve nenhuma percepção mágica. Ele tinha acesso às duas máquinas virtuais do VDSM e agiu de forma sistemática, algo que um humano cansado ao final de um dia de trabalho normalmente não consegue fazer.

A coisa mais valiosa que o programa fez foi executar o comando `docker diff` antes de mexer em qualquer coisa, detectar 6.764 arquivos alterados e rejeitar o plano óbvio. Alguém seguindo o arquivo `.compose` não teria motivo para executar esse comando. A segunda coisa mais valiosa foi a verificação: após a importação, ele contou tabelas, problemas, projetos, entradas de diário e anexos em ambos os lados, verificou se todos os arquivos anexos existiam no disco, listou as versões de plugins que o aplicativo havia registrado e confirmou que não havia migrações de banco de dados pendentes. Essa é uma lista de verificação tediosa, e listas de verificação tediosas são exatamente o tipo de coisa que se ignora às cinco da tarde.

O que ainda faltava de um humano era discernimento sobre as consequências. Reiniciar uma máquina virtual do VDSM para adicionar memória significava tirar um site do ar, e essa é uma decisão que deve ser questionada, e não presumida. O mesmo vale para excluir qualquer coisa. Trate o assistente como um par de mãos muito rápidas e literais que nunca se cansam de verificar, e reserve as decisões irreversíveis para você.

Onde encontrar mais recursos oficiais

O pacote Virtual Machine Manager, que hospeda todas as máquinas virtuais do VDSM, está presente no DSM há anos e possui ampla documentação. Estes três tutoriais abordam a instalação do pacote, a criação de uma máquina virtual e o formato geral da interface que você utilizará.

Limitações a conhecer antes de confiar a produção ao VDSM

Primeiramente, a memória é o fator limitante com muito mais frequência do que a CPU. Nosso sistema convidado de destino tinha 2 GB e já estava utilizando o swap antes mesmo de adicionarmos qualquer coisa. Um segundo aplicativo, juntamente com um segundo banco de dados, precisava de aproximadamente mais 480 MB, então aumentamos a memória para 4 GB. Verifique a memória livre no destino antes de planejar a migração, não depois.

Em segundo lugar, um disco virtual VDSM cresce, mas nunca diminui. Se você provisionar espaço em excesso, não poderá recuperar o espaço editando o campo para um valor menor; a única maneira de obter um disco menor é criar uma nova máquina virtual e migrar para ela. Escolha um valor com o qual você ainda esteja satisfeito daqui a dois anos.

Terceiro, licenciamento. Um convidado está incluído no NAS; cada convidado adicional precisa de sua própria licença. Licença Virtual DSM. O agrupamento em várias unidades NAS, a migração em tempo real e a retenção de snapshots em maior escala são... VMM Pro Priorize funcionalidades em vez de itens padrão. Se o seu plano de consolidação envolver dividir um hóspede ocupado em quatro hóspedes organizados, calcule o preço disso antes de elaborar o projeto.

Avaliar o tamanho correto de um hóspede é uma tarefa à parte: Como dimensionar corretamente uma VM de produção com VMM Pro.

Em quarto lugar, os cenários a evitar. Não coloque o disco virtual de uma máquina virtual no mesmo volume físico para o qual você faz backup e considere isso como um backup. Não execute um banco de dados com gravações intensas e contínuas em uma máquina virtual que compartilha discos rígidos com um servidor de arquivos ocupado. Não trate o VDSM como um substituto para uma segunda máquina, pois se o host falhar, todas as máquinas virtuais nela falharão simultaneamente. E não migre um contêiner que você nunca inspecionou, pelos motivos descritos na seção sobre o arquivo de composição acima.

Quinto, credenciais. Uma migração afeta senhas de banco de dados, variáveis de ambiente e arquivos de configuração. A nossa moveu um arquivo .compose contendo credenciais de banco de dados em texto simples, então ele foi colocado propositalmente fora da raiz de documentos do servidor web. Um arquivo .compose deixado dentro da raiz de documentos pode ser baixado por qualquer pessoa que adivinhe o nome do arquivo, e essa é uma forma lamentavelmente comum de vazamento de credenciais. Se você permitir que um assistente crie um script de migração, verifique onde ele está gravando os arquivos. E quando o trabalho estiver concluído, desative a conta que você criou para o assistente, em vez de deixar um login de administrador ativo.

Sexto, faça um snapshot antes de mexer em qualquer coisa. Um snapshot do VDSM no Virtual Machine Manager leva segundos, está disponível sem a licença Pro e transforma quase todos os erros deste artigo em um rollback de dois minutos. É o único passo que vale a pena adicionar a qualquer runbook de migração, seja digitado por uma pessoa ou por um assistente.

Por fim, verifique em vez de presumir. Todas as afirmações deste artigo foram verificadas no sistema em execução: contagem de tabelas em ambos os lados, arquivos anexos presentes no disco, versões de plugins registradas pelo aplicativo, ausência de migrações pendentes e reinicialização completa do sistema para comprovar que ele retorna automaticamente. Uma migração não termina quando o serviço responde. Ela termina quando você comprova que ela sobrevive a uma reinicialização do sistema convidado VDSM e quando a cópia antiga não consegue mais aceitar gravações.

Uma observação sobre onde obter essas licenças, já que é o que fazemos: a SynoPower Club vende licenças Synology com entrega instantânea de chaves 24 horas por dia, 7 dias por semana. As duas licenças importantes aqui são a Licença Virtual DSM, que você precisa para cada convidado além do gratuito, e o Licença VMM Pro Se você deseja clustering, migração ao vivo ou 255 snapshots por convidado em vez de 32. catálogo completo de licenças Abrange também os modelos Surveillance Station e MailPlus.

Referências

• SynoPower Club, nossos guias para o NAS Synology e análises de câmeras
• Synology — Virtual Machine Manager, a visão geral oficial do pacote que executa o VDSM
• Centro de Conhecimento Synology — Ajuda Virtual Machine Manager, Criação e configurações de convidados
• Docker — commit de contêiner docker, o comando por trás do passo um
• Docker — salvar imagem do Docker, usado para transmitir a imagem entre os convidados

Perguntas frequentes