De vSphere para Proxmox: o que migra mesmo

Todos os guias de migração para sair do VMware começam pelo disco, porque o disco é a parte que tem um ficheiro. Converter o VMDK, importar, arrancar, feito.

O disco é a parte fácil. O que faz uma máquina vSphere funcionar está noutros quatro sítios, nenhum deles dentro do VMDK: como a plataforma identifica a máquina, como o convidado é configurado no primeiro arranque, para que hardware virtual o convidado tem controladores, e que agente dentro do convidado responde a perguntas sobre ele. Cada um é um problema diferente no Proxmox, e só um deles se anuncia quando corre mal.

Foi isto que encontrámos ao construir caminhos de leitura e de escrita contra os dois, medido contra o vCenter 6.7.0 build-24323669.

O disco, e a chamada que não existe

Há duas formas de disco virtual em jogo. Uma VM vSphere em funcionamento tem um VMDK plano mais um pequeno descritor. Um OVA ou uma imagem de nuvem descarregada tem um VMDK stream-optimized: comprimido, sequencial e não arrancável tal como está.

O caminho de conversão óbvio é o CopyVirtualDisk_Task com uma especificação de destino a nomear o formato pretendido. Essa chamada existe num anfitrião ESXi isolado e não existe no vCenter: responde «The requested operation is not implemented by the server». É um bom exemplo de uma armadilha mais ampla nesta API, em que a mesma operação existe a um nível de gestão e não existe a outro.

Duas coisas funcionam mesmo, e vale a pena conhecê-las por esta ordem:

• O CopyVirtualDisk_Task sem especificação de destino funciona no vCenter 6.7 e copia um disco preservando o seu tipo. Neste vCenter exige o argumento datacenter; a forma só com um caminho de datastore é recusada.
• O caminho de importação OVF (CreateImportSpec → ImportVApp → HttpNfcLease → HTTP POST → HttpNfcLeaseComplete) aceita um disco stream-optimized e converte-o à entrada. Precisa apenas do descritor .ovf, não do OVA inteiro: um OVA é um arquivo tar com o descritor à cabeça, que se obtém com um único pedido de intervalo de 128 kB.

Do lado do Proxmox, o equivalente é o qm disk import, que pega num VMDK e o escreve no armazenamento de destino no formato próprio desse armazenamento. Essa parte é mesmo simples.

O aprovisionamento é modelado de forma diferente nos dois lados. O vSphere tem dois indicadores, thinProvisioned e eagerlyScrub, e não formam uma escolha de três: thin exclui eager, pelo que os estados válidos são thin, thick lazy zeroed e thick eager zeroed. Tudo o que modele isto como um único enumerado de quatro valores acabará por enviar uma combinação impossível.

Identidade: o identificador que tem não é uma identidade

Este problema morde meses depois, não no dia da migração.

Um objeto vSphere é endereçado por uma referência a objeto gerido, algo como vm-101. Parece um identificador e não é: é uma chave na base de dados daquele vCenter em concreto. Reconstrua ou restaure essa base de dados e a referência não acompanha a máquina, e volta a ser entregue a outra VM. Aquilo que guardou há seis meses aponta agora para a máquina de outra pessoa, e a operação que estava prestes a executar é um desligar.

O identificador duradouro é o config.instanceUuid. Guarde esse e resolva a referência a cada operação através do FindByUuid.

O Proxmox tem a forma oposta. Uma VM é um vmid: estável, legível por pessoas, visível em todos os comandos, único por cluster. É mais agradável de usar, e tem a sua própria consequência numa migração. Está a escolher identidades novas, pelo que todos os sistemas externos que se referiam a uma máquina pelo seu identificador de vSphere têm de ser reapontados.

O modelo de localização também difere. Com o DRS ativo, o anfitrião onde uma VM corre muda sem que ninguém peça, pelo que a um clone se dá um resource pool e é o vSphere que escolhe. No Proxmox, o nó é a unidade e mudar de nó é explícito. Um inventário que registava «que anfitrião» para um cluster com DRS registava algo que muda sozinho.

Personalizar o convidado: outro mecanismo, não outra sintaxe

Ambas as plataformas conseguem configurar um convidado no primeiro arranque. Fazem-no de maneiras que não partilham código.

No vSphere, a via que funciona sem depender do convidado é o guestinfo: quatro chaves em extraConfig, lidas pela fonte de dados VMware do cloud-init.

As chaves .encoding não são opcionais. Deixe-as de fora e o cloud-init lê o texto base64 como sendo o próprio conteúdo, e a máquina sobe com um nome de anfitrião de quarenta caracteres sem sentido. Sem erro, apenas uma resposta errada.

A alternativa, o CustomizeVM_Task do próprio VMware, precisa das VMware Tools no convidado e, em modelos Linux mais antigos, de um perl funcional, que é o género de requisito que se descobre quando um aprovisionamento fica pendurado a meio.

No Proxmox, a personalização é uma unidade de cloud-init ligada à VM, configurada com um pequeno conjunto de chaves: ipconfig0 até ipconfig3, nameserver, searchdomain, ciuser, cipassword, sshkeys, citype, ciupgrade.

Uma delas tem uma armadilha que fica invisível até um cliente se queixar. O ciupgrade tem default = 1 no esquema do Proxmox, pelo que omiti-lo não quer dizer «não atualizar pacotes no primeiro arranque»; quer dizer «atualizar». Uma caixa por assinalar tem de ser enviada como um ciupgrade=0 explícito ou a caixa está a mentir. Também não existe antes do PVE 8.1, onde enviá-lo é um erro duro e não uma chave ignorada.

Mais duas coisas correm mal da mesma maneira dos dois lados. O identificador de instância tem de mudar quando uma máquina recebe uma identidade nova: o iid-local01 da maioria dos exemplos faz com que uma máquina clonada fique com a configuração do modelo. E a interface não vai ter o nome que espera: ens160 no VMware, outra coisa em KVM. É o Netplan com match: {name: "e*"}, em vez de um nome de dispositivo adivinhado, que faz uma imagem funcionar nos dois.

Hardware virtual para o qual o convidado tem controladores

O vmxnet3 é a placa de rede predefinida sensata no VMware, e tem uma condição prévia: precisa das VMware Tools no convidado. Instale um modelo sem as Tools, dê-lhe uma placa vmxnet3, e o sistema operativo não vê placa de rede nenhuma.

Isso conta duas vezes. Antes, porque um modelo que arranca bem em ESXi pode precisar de e1000e. E depois, porque a escolha de alto desempenho do Proxmox é o virtio, que precisa dos seus próprios controladores: presentes no Linux moderno, absolutamente ausentes numa imagem Windows de origem. O e1000 é a opção lenta, aborrecida e que funciona em todo o lado nas duas plataformas, e é o primeiro arranque certo para uma máquina que está a mudar de casa.

O controlador de disco tem a mesma forma de problema: no Proxmox o caminho rápido é o virtio-scsi, que é outra vez uma questão de controladores. Não medimos o que a troca de tipo de controlador faz a um convidado já instalado, e é uma causa frequente de uma máquina que migra sem problemas e depois não arranca.

O agente dentro do convidado muda de nome

Uma quantidade surpreendente do que um painel mostra não vem de todo do hipervisor.

No vSphere, o guest.ipAddress vem das VMware Tools. O uso real de disco também, através do guest.disk: o summary.storage.committed ao nível do datastore é o número do aprovisionamento e lê-se errado para um disco thin. Tools que não correm quer dizer campos vazios, e vazio quer dizer «não sei», nunca «a máquina não tem endereço».

Depois da mudança, a mesma informação vem do qemu-guest-agent, outro pacote com outro nome, que tem de ser instalado. Um parque que migra sem ele parece, no seu próprio inventário, um parque que perdeu os endereços.

Mais um cuidado com esse endereço: chega pelo canal próprio do hipervisor para o convidado, não pela rede. Pode ser perfeitamente exato para uma máquina cuja placa não está ligada a nada. A única coisa que prova alcançabilidade é alcançar.

A rede, e a ligação que em silêncio não é uma

O vSphere tem dois tipos de suporte de rede e não se parecem. Uma Network normal é referida pelo nome; um DistributedVirtualPortgroup pelo UUID do seu switch mais a chave do próprio grupo de portas.

Construa só a primeira forma e, em qualquer ambiente com um switch distribuído, fica com uma placa ligada a nada. O vCenter não a recusa, porque o nome existe mesmo como objeto de rede. A máquina arranca sem ligação e o erro está dentro do convidado.

O Proxmox é mais simples: uma NIC nomeia uma bridge, com uma etiqueta de VLAN opcional. O mapeamento é seu para escrever; não há tradução automática de um grupo de portas para uma bridge. Mais duas coisas a decidir antes da primeira mudança:

• Os endereços MAC. Levá-los consigo mantém válidas as reservas de DHCP e as ligações de licenças, e significa duas máquinas com o mesmo MAC se a origem alguma vez voltar a ser ligada. Escolha de propósito.
• O firewall por VM. O vSphere não tem um; isso é o NSX, um produto à parte. O Proxmox tem. As máquinas que chegam do VMware nunca tiveram um firewall ao nível do hipervisor, e ligar um é um projeto e não uma caixa para assinalar.

O que não viaja, e não está em ficheiro nenhum

Algumas coisas não têm equivalente, e um plano que não as nomeia descobre-as uma a uma:

• As imagens instantâneas. A máquina atravessa como um disco plano; uma árvore de snapshots é uma estrutura do vSphere sem nada para onde ser importada.
• O changed block tracking, e com ele todo o histórico de cópias incrementais que dependia dele.
• Etiquetas, atributos personalizados e pastas. Vivem na base de dados do vCenter, não na máquina.
• Resource pools, regras de DRS, reservas e shares. O Proxmox não tem escalonador equivalente, pelo que uma política de colocação escrita em regras de DRS passa a ser decisões sobre em que nó fica cada máquina.
• A versão de hardware da VM. Um conceito do vSphere sem equivalente no Proxmox, pelo que tudo o que na sua automatização dependa dele é agora código morto.

O que as nossas ferramentas fazem, e o que não fazem

Sem rodeios: não construímos a migração de vSphere para Proxmox. As nossas ferramentas de migração cobrem hoje exatamente uma rota, entre dois painéis de jogos, e ficam atrás de um indicador de funcionalidade que está desligado.

Duas regras dessa única rota valem a pena ser roubadas na mesma, porque tornam uma migração revisível em vez de esperançosa. A origem é apenas de leitura, como constante e não como indicador, pelo que não existe configuração em que a ferramenta escreva no sistema que está a deixar. E uma execução de ensaio é obrigatória antes de aplicar, com uma contagem por categoria no fim, origem contra destino. Uma migração que não lhe consegue dizer quantas máquinas moveu não terminou; parou.

Isto saiu da construção das integrações de vSphere e de Proxmox para o Provibr, um painel de gestão de servidores para alojadores, onde os dois hipervisores têm de ser legíveis por uma só interface sem que nenhum seja descrito como o outro. As notas de configuração estão na documentação do vSphere e do Proxmox.