Estou com o seguinte problema: Temos um servidor de hardware dedicado (bare metal) (Debian 10) ao qual não temos acesso físico direto. Agora quero transferir todos os dados e aplicativos que estão neste servidor para uma VM e executá-los em um host KVM.
Por que não instalo o aplicativo diretamente na VM? A instalação deste aplicativo (material Perl com servidor web Apache, rodando no mesmo servidor há cerca de 10 anos) é tão complexa que você preferiria quebrar alguma coisa. Então ninguém se atreve a fazer isso. Mas agora temos que avançar e, por esta razão, precisamos de algum tipo de solução alternativa inteligente.
Pensei em desligar todos os serviços Perl e Apache e transferir o disco rígido pela ddrede - mas o problema é que o host KVM de destino tem menos espaço do que o sdado servidor bare metal é grande (no final, ele usa menos espaço do que está disponível, sdaé apenas superdimensionado).
A segunda opção seria instalar os mesmos pacotes no KVM com exatamente os mesmos números de versão (de acordo com dpkg --list), desabilitar todos os serviços no servidor bare metal (para manter os dados consistentes) e colocar /etc, /var/, /usre tudo mais que for importante do o servidor bare metal em um tarball e simplesmente descompacte-o no KVM. Claro que eu também poderia fazer isso via rsync, mas o princípio é mais ou menos o mesmo.
O que você acha da última ideia?
Você tem alguma outra ideia?
Como você procederia com tal tarefa?
Responder1
Comoanxme pediu para fazer isso, responderei minha própria pergunta :) Minha solução não era tão sofisticada eanx's, mas eu gostaria de compartilhar com você de qualquer maneira.
Na verdade, o que fiz foi verificar primeiro os tamanhos do Inode e do bloco em ambos os sistemas de arquivos para ter certeza de que são idênticos entre si (usando tune2fs).
Então desliguei todos os serviços, exceto os existenciais como o SSHd.
Depois disso decidi usar apt-clonee não copiar os pacotes e binários de uma máquina para outra:
# on the physical machine:
apt-get install apt-clone
apt-clone clone packages
# on the virtual machine:
apt-get install apt-clone
apt-clone clone packages.apt-clone.tar.gz
# check on the VM:
vimdiff <(dpkg --list) physical_mchine_packages.txt
Em seguida, sincronizei os dados usando rsync. Os diretórios que sincronizei:
/root/etc(Excluí arquivos comohostname,fstab,/default/grube/network/interfacesvários outros diretórios relacionados ao kernel/initram/lvm)/usr(nem tudo, depende do software que você usa)/var(nem tudo, depende do software que você usa)
A etapa final foi verificar se o nome de host ou endereço IP da máquina física antiga está colocado em alguns arquivos de configuração:
find . ! \( -path "*proc*" -o -path "*sys*" -o -path "*var/mail*" -o -path "*var/spool/mqueue*" -o -path "*var/log*" \) -type f -exec grep -iH -- "x.x.x.x" {} \;
Isso é tudo. Everythink funciona na VM agora. Espero poder ajudar alguém :)
Responder2
(Esta resposta discute onível de dispositivo de blocoalternativa, é mais apropriado se você deseja manter intactas a configuração do particionamento e do gerenciador de inicialização durante a migração para o virtual)
O problema que você descreve não ocorre necessariamente na prática. EUacidentalmenteevitei isso recentemente:
mas o problema é que o host KVM de destino tem menos espaço que o sda do servidor bare metal
É perfeitamente válido criar, montar em loop e editar partições em umescassoarquivo que é (até substancialmente) maior que o sistema de arquivos host - contanto que você não faça nada realmente gravando dados nas áreas ignoradas do arquivo.
O que eu fiz foi aproximadamente fstrim / && systemctl stop appserver && mount -o remount,ro / && sync && dd bs=64k if=/dev/nvme0n1 | ssh vmhost dd bs=64k conv=sparse of=... Em seguida, no host vm, losetupdisponibilizei a imagem fdiske resize2fsalterei seu tamanho (virtual). Como a imagem já continha apenas zeros na maior parte de seu final, minhas operações nela não aumentaram muito seu tamanho real.
O pior caso necessário de espaço para esta abordagem mais simples seria 3 vezes o conteúdo de dados do servidor antigo. Uma vez para copiar a imagem esparsa, uma vez para redimensionar (ou seja, para mover todo o seu conteúdo para o início sem fazer novos furos no final) e depois mais uma vez para converter a imagem bruta do disco para o formato (ou para mover o arquivo então -imagem baseada em seu próprio volume lógico) usado pelo gerenciamento da máquina virtual.
Algumas coisas a serem observadas:
- a maneira como você faz esta operação deve depender do software/configuração da virtualização planejada (por exemplo, se o seu sistema atual inicializa via EFI, mas sua virtualização não está preferindo isso, qual é o sentido de fazer umacópia de discoquando você terá que refazer as coisas relacionadas ao carregador de inicialização?)
- fstrim (especialmente quando combinado com SSDs ou RAID defeituosos) pode ser perigoso em termos de perda de dados. Se você não tiver certeza de que é uma operação segura em sua configuração, faça oescrevendo um arquivo enorme contendo apenas bytes nulosalternativa - nos preocupamos apenas com a detecção de áreas não utilizadas (sendo zeradas), e não se o disco está ciente.
- Apenas colocar o root somente leitura faz o trabalho, mas obtém o resultadocomo se o servidor travasse antes de ser reiniciado na máquina virtual. Se você copiar a imagem após interromper seus aplicativos, isso pode serbom o bastante: afinal, você espera que seu servidor já possa continuar após uma falha.