Jefferson, 
22 de março de 2020, 
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:
- Fazer uma imagem “raw” (bit a bit) do disco
- Converter essa imagem em um HDD virtual
- 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:
- O Linux rodando no original iria rodar em outra máquina;
- 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.
Esse é o tipo de tutorial que amo ver; não tenho muita intimidade com virtualização, e nem imagino ter que fazer um procedimento desse no médio prazo; mas como podem aparecer clientes novos, com demandas diferentes, posso precisar vir aqui rever em breve.
Desde já agradeço, Jeff; Aproveito pra um pedido off-topic: um novo cliente usa roteador tp-link eap 115, com 5 equipamentos com mesmo nome/senha para que o usuário esteja sempre conectado em qualquer ambiente, sem precisar de login/senha diferentes. Qualquer tutorial mais prático sobre esse sistema, agradeço.
Se for o que estou pensando, eu não gosto desse tipo de equipamento nem desse tipo de configuração.
1)Ter todos os equipamentos com o mesmo SSID implica que você vai levar um longo tempo para notar que um está defeituoso. Você nunca sabe, num dado momento, a qual AP está conectado. Você pode estar embaixo de um e o seu celular estar teimosamente agarrado ao outro de onde você veio, a dezenas de metros. Se a tecnologia WiFi pelo menos já tivesse resolvido esse problema e o celular não precisasse esperar perder a conexão atual para procurar um sinal mais forte, eu teria menos objeções.
2)Eu tenho um cliente que usa quatro APs “enterprise” da Ubiquity. Você gerencia todos de um mesmo lugar, quando muda a senha isso é propagado para todos automaticamente… parece ótimo no papel, mas na realidade é um saco, porque você só pode gerenciar de uma única máquina (se quiser configurar em casa para instalar no cliente, precisa usar o mesmo notebook sempre) e o processo é muito enrolado. Se você tiver, digamos, 100 APs, certamente é melhor do que configurar um por um. Mas meia dúzia? Dá menos trabalho configurar um por um do que lidar com as frescuras e limitações do software de gerenciamento da Ubiquity.
No caso desses equipamentos, não parece haver modo de configurar um por um. Eles não tem uma interface gráfica própria acessível via navegador. Só isso aí eu já considero um sinal de retrocesso e não de avanço. Mesmo que você queira usar esse aparelhos como APs normais, não pode.
Parabens pelo tutorial. Ja tive necessidades semelhantes e na epoca a melhor saida devido ao tempo disponivel foi usar o vmware converter e rodar a maquina gerada no vmware player.
Uma dica com relacao ao comando dd, voce pode instalar o comando dcfldd que tem as mesmas finalidades que o dd, porem ele mostra a saida dos blocos lidos/gravados em tempo real. Isso faz com que você não fique naquela duvida após um tempo de sera que ta indo ou travou?
abraço