Quick Talk

Esse é um trabalho em andamento, mas eu vou publicar o que aprendi até agora ao virtualizar um servidor Dell rodando Linux CentOs 6.1. E vou explicar do ponto de vista de quem prefere usar Windows.

Mas vou começar explicando por que valia a pena ter esse trabalho todo.

A aplicação rodando nesse servidor é uma aplicação “legada”, consultada por apenas dois funcionários da empresa talvez uma vez por mês. O servidor é um monstro que uma pessoa só tem dificuldade para tirar do rack e carregar sozinha, consumindo energia 24h por dia (eu tentei fazer com que ele fosse ligado apenas quando necessário, mas ligar e desligar esse servidor “é um processo”, por isso deixei para lá) e roubando autonomia do no-break. Num rack com quatro máquinas semelhantes virtualizar uma já aumenta essa autonomia, numa estimativa grosseira, em 25%. Apesar do tamanho essa máquina consome surpreendentemente pouco: apenas 70W. Mas todas as outras parecem ter consumos semelhantes. E essa máquina virtualizada em vez de ser um possível problema de reposição de peças (motherboard e fonte proprietárias da Dell, memória ECC, HDD SAS…) se torna uma valiosa reserva de peças. Nesse caso específico eu tenho ainda mais a ganhar, porque esse servidor é o único no rack com generosos 64GB de RAM (o consumo segundo o htop é de 0.5GB) e eu tenho me virado até agora nessa empresa com um servidor de virtualização e TS/RDP que tem “apenas” 24GB.

Além de tudo isto eu não tenho acesso remoto ao servidor físico. Ele tem uma versão antiga do Teamviewer que não funciona mais e não consegui atualizar, não consegui instalar Anydesk e o suporte a RDP eu não consigo ativar porque requer a senha do “default keyring” que não sei qual é, apesar de ter a senha do usuário root.  E não me atrevo a mexer muito no original e acabar quebrando a aplicação. Virtualizando eu passo a ter acesso remoto indireto através do acesso remoto que tenho ao servidor de virtualização.

São basicamente três passos:

1. Fazer uma imagem “raw” (bit a bit) do disco
2. Converter essa imagem em um HDD virtual
3. Fazer os ajustes necessários de drivers/interfaces para a instalação do linux rodar na máquina virtual

Para virtualizar um servidor Windows os passos 1 e 2 se tornam um só usando o Disk2VHD, mas este não enxerga partições Linux.

Ferramentas de software utilizadas

• LiveCD Linux Mint 18.1 Mate x64 (KDE Partition Manager);
• LiveCD Linux Mint 19.3 Cinnamon x64 (Gparted);
• Sergei Strelec 2019-12-28 (Trueimage 2019 e HDD Regenerator 2011)

As três ferramentas acima estavam integradas no mesmo pendrive de boot usando o AioBoot

PASSO 1 – Fazer uma imagem “raw” (bit a bit) do disco

• Dê boot na máquina com um LiveCD Linux. Use um LiveCD moderno, com suporte estável a NTFS, como o Linux Mint;
• Conecte um HDD externo na máquina formatado com NTFS e espaço suficiente para acomodar todo o disco que você está duplicando (se o HDD original tem 1TB, você tem que ter 1TB de espaço livre). Monte a partição. No Linux Mint 19.3 isso ocorre automaticamente quando você clica nela no Gerenciador de Arquivos;
• Identifique o dispositivo linux que corresponde ao disco que você quer duplicar (sda, sdb, etc);
• Certifique-se de que nenhuma das partições desse disco esteja montada. Ao iniciar por um LiveCD normalmente não vão estar, mas se você abrir o Gerenciador de Arquivos e clicar nas partições vai inadvertidamente montá-las então precisa ficar atento a isso;
• Considerando que o dispositivo seja /dev/sdb e que a partição do HDD externo esteja montada em /media/mint/backups/, abra um terminal e dê um comando como o seguinte:

sudo dd if=/dev/sdb of=/media/mint/backups/imagem_raw

Se você desconfia de que seus discos ou sistemas de arquivos podem ter defeitos (é melhor checar e consertar antes) e quiser passar por cima deles use o parâmetro conv=sync,noerror

sudo dd if=/dev/sdb of=/media/mint/backups/imagem_raw conv=sync,noerror

O comando dd não dá nenhuma indicação de progresso. A única indicação de que você vai ter de que algo está acontecendo são as luzes do HDD da máquina e do HDD externo piscando. O comando dd é o mais popular, mas você poderia usar qualquer outro que possa ler um arquivo bit a bit (no Linux “tudo é um arquivo”), como o comando cat.

Isso pode levar muitas horas dependendo do tamanho do disco e velocidade das interfaces.

PASSO 2 – Converter essa imagem em um HDD virtual

Plugue esse HDD com a imagem RAW em uma máquina Windows com o Virtualbox instalado e espaço livre no mínimo igual ao tamanho da imagem RAW e dê um comando como este:

“C:\Program Files\Oracle\VirtualBox\VBoxManage.exe” convertfromraw -format vdi g:\imagem_raw k:\hdd_virtual.vdi

Isso pode também levar horas, dependendo do tamanho da imagem e da velocidade dos discos envolvidos.

Isso é tudo o que você precisa fazer neste ponto, mas é bom saber que, se você tiver acesso ao Virtualbox já no passo 1, pode economizar este passo, o tempo que ele leva e a necessidade de duas vezes o espaço livre se concatenar os comandos já no primeiro passo. Seria algo como (não testado):

sudo dd if=/dev/sdb | VBoxManage –convertfromraw stdin /media/mint/backups/hdd_virtual.vdi

PASSO 3 – Fazer os ajustes necessários

Essa pode ser a parte mais complicada porque o que chamamos coletivamente de “Linux” é uma bagunça do ponto de vista de um usuário Windows. O primeiro cuidado que você precisa ter é simples e o mesmo cuidado que você precisa ter ao virtualizar um servidor Windows: escolher a versão correta do SO na lista do Virtualbox. Mas a complicação já aparece nesse passo porque, por exemplo, CentOS não aparece na lista. Eu tive que pesquisar e constatar que o CentOS é uma variante do Red Hat e escolher essa opção ao criar a máquina virtual.

Ao dar boot o CentOS reconheceu todo o hardware, mas um problema consistente que eu tive foi com a rede, que não “subia” apesar da interface de rede ter sido detectada. Eu nem vou tentar explicar aqui como se resolve esse problema porque isso varia demais entre distros e aparentemente até mesmo dentro de uma mesma distro. Por exemplo, nenhuma das explicações de como resolver isso no CentOS 6.1 (que supostamente usa um tal de “Network Manager” e scripts em /etc/sysconfig/network-scripts/) surtiu qualquer efeito. Eu tive que usar a explicação de como resolver em um Linux genérico, que era acrescentando/editando linhas em /etc/rc.local

• /sbin/ifconfig eth0 10.0.0.121 netmask 255.255.255.0
• /sbin/ip route replace default via 10.0.0.54

Ainda que no seu caso a conexão de rede “suba” automaticamente, se você precisar mudar o IP da máquina por alguma razão vai precisar saber onde se configura isso e não parece haver um roteiro padronizado como Iniciar->Executar ->ncpa.cpl ->Click, click, click do Windows.

NOTAS

O passo a passo que descrevi é o caminho mais simples. Eu segui um caminho mais tortuoso mas mais seguro e que me ajudou a aprender mais coisas no caminho.

Eu fiz um clone físico do servidor original e trabalhei nele

Com a ajuda do Acronis Truimage 2019 (o TI 2020 travava nessa operação) eu fiz uma imagem .tib do servidor em um HDD externo e depois fiz a recriação do disco em uma outra máquina bem mais modesta. A virtualização poderia não funcionar por n razões e acrescentava uma camada de complexidade. Eu primeiro precisava me certificar de que:

1. O Linux rodando no original iria rodar em outra máquina;
2. A aplicação rodando na cópia não ia espernear acusando problemas de licença.

Essa clonagem funcionou na primeira tentativa, exceto a rede. O que me deixou otimista quanto ao sucesso da virtualização. Mesmo que esta não funcionasse eu poderia substituir o servidor superdimensionado atual por uma máquina muito mais modesta, com peças abundantes de manutenção e que não dava medo manusear.

Testei o shrink das partições no clone

O servidor original tinha um HDD superdimensionado de 1TB, mas apenas 454GB estavam sendo utilizados e muita coisa era desnecessária. Identifiquei uns 80GB de email na caixa do usuário root e mais várias dezenas de GB em backups e logs que podia ser apagados. Mesmo assim eu fiz do jeito que o servidor estava e o processo, via USB 2.0, levou duas horas e criou um arquivo de meros 136GB (o TI faz compressão).

Recriei em outro HDD de 1TB, apaguei tudo o que eu achava que era desnecessário (ainda estava tudo no servidor original e no arquivo .tib), testei se continuava funcionando e com a ajuda do LiveCD do Linux Mint fiz o shrink das partições (dependendo da versão você pode usar o KDE Partition Manager ou o Gparted) e o resultado cabia em um HDD de 320GB com folga.

Fiz nova imagem do disco (1TB) com o TI 2019 e apliquei em um disco de 320GB.

Mas esse processo foi o mais demorado porque muita coisa deu errado no caminho e somente a movimentação da partição de 136GB levava 4h porque o programa roda o fsck (chkdsk) na partição antes e depois. Foram dois dias testando (sábado e domingo), errando e começando tudo de novo. Dicas para maximizar suas chances de dar tudo certo:

• Se parecer que no Gparted uma operação não pode ser feita, teste o KDE Partition Manager e vice-versa;
• Faça um roteiro otimizado dos passos para encolher o disco e faça uma operação de cada vez. O gerenciador de partições não é esperto o bastante para fazer essa otimização por você e se você mandar ele mover uma partição duas vezes para a esquerda, ele vai mover duas vezes para a esquerda, mesmo que seja possível otimizar passos intermediários de forma a só precisar mover uma vez. E mover partições implica em copiar todos os dados da posição antiga para a nova. Nas minhas duas primeiras tentativas, quando eu mandei fazer várias operações de uma vez, uma falhou inutilizando a partição e a outra não deu falha alguma mas o Linux não chegava mais à tela de login. Só funcionou mesmo quando fiz uma de cada vez, testando o boot após cada operação;
• Faça as clonagens do TrueImage usando um arquivo .tib intermediário. Isso pode funcionar onde a clonagem disco para disco do TrueImage falha inexplicavelmente. Eu sou bastante reticente para usar clonagem disco-a-disco desde que fiz essa m**da aqui, mas mesmo fazendo tudo certo não estava dando nada certo. E o erro “falhou” do TI não ajudava em nada.

Desta forma, quando finalmente usei o danado do dd, que não tem nenhuma indicação de progresso, eu estava lidando com uma imagem de 320GB e não com uma de 1TB. Tanto o dd quanto o convertfromraw levaram um terço do tempo que normalmente levariam e meu HDD virtual ficou com “apenas” 210GB.  Notar que é possível reduzir o tamanho do HDD virtual depois com o comando VBoxManage -compact mas antes você vai precisar fazer o “zero fill” do espaço livre.

Use a melhor máquina que você tiver sobrando para fazer esses testes

Eu usei uma máquina baseada em uma motherboard Biostar H110MHV3 porque estava sobrando na bancada e era comprovadamente estável, mas senti falta de uma interface USB 3.0 e o boot do CentOS era estranhamente lento. 2min48s só para chegar à tela de login e 6min10s para o fim da atividade frenética do HDD. Com 4GB ou 6GB de RAM não fazia diferença. A máquina virtual resultante está levando 35s para chegar à tela de login com 4GB de RAM reservados para ela no meu Core i5-2310.

Mesmo que eu fosse usar essa Biostar para substituir o servidor original esses números ainda valeriam a pena. Eu não duvido nada que o servidor Dell original leve dois minutos só para terminar o danado do POST.

Teste todos os HDDs que você vai usar com o HDD Regenerator antes

Elimine a variável “defeito no HDD” dos seus testes e o HDD Regenerator faz “milagres” que é importante que já tenham acontecido antes de iniciar o processo.

Evite desligar a máquina Linux incorretamente

Mesmo que seja apenas uma máquina para testes e nada importante seja corrompido, as operações intermediárias que você deseja fazer podem ser impedidas ou prejudicadas. Por exemplo, o Trueimage pode aceitar fazer apenas uma cópia setor-a-setor (mais demorada) do disco se encontrar o “dirty bit” ativo na partição.

Após certas operações é normal que o primeiro boot subseqüente seja lento

Seja no clone físico ou no clone virtual o tempo de boot pode aumentar muito na primeira inicialização seguinte. Algo como o tempo normal ser 35s e nesse boot demorar 4min. Ao reiniciar a máquina o tempo de boot terá voltado ao normal.

Não adianta usar o Clonezilla como substituto do dd

Não quando você quer uma imagem de disco inteiro.

Para o famoso Clonezilla uma “imagem do disco inteiro” não é o que nós, usuários Windows, normalmente esperamos. Embora você possa configurar o Clonezilla no assistente para usar o dd e assim obter uma imagem RAW perfeita, não importa que opção você escolha o Clonezilla faz uma imagem separada de cada partição do disco, que depois você não vai poder processar usando o VBoxManage -convertfromraw.  Para o Clonezilla uma “imagem do disco” é um diretório com todas as imagens individuais de partições, MBR, tabela de partições, instruções e logs. Eu perdi horas e horas apanhando com isso achando que estava fazendo algo errado antes de me render e usar o dd, que é potencialmente perigoso se você não prestar muita atenção.

Mas o Clonezilla, com sua interface gráfica limitada de duas décadas atrás, não é muito melhor.

Esse é o Clonezilla em 2020. Qualquer semelhança com o antiquado Norton Ghost já é uma alucinação.

É muito mais fácil você ter certeza do que está fazendo com o TrueImage, mas infelizmente este grava em um formato proprietário.

É possível recriar manualmente uma imagem do disco inteiro usando as imagens individuais (você pode concatenar os arquivos até com o comando type do Windows), mas você precisa saber em que ordem colocar tudo, incluindo MBR e tabela de partições. E precisa saber quais arquivos são relevantes pois em uma imagem de 5 partições o Clonezilla gera 25 arquivos, mesmo gerando um arquivo só por partição.