Migração VMware para Proxmox: Guia de Engenharia de Storage (vmdk para qcow2/zvol)

O pânico recente com licenciamento da VMware gerou uma corrida para o Proxmox VE. Mas, como engenheiro de storage, vejo administradores cometendo o erro clássico: tratar a migração como uma simples cópia de arquivos. Não é. Mover uma VM do ESXi para o KVM é uma cirurgia de transplante de órgãos na camada de I/O.

Você está trocando um ecossistema proprietário (VMFS + Drivers SCSI emulados) por uma stack aberta (ZFS/LVM + VirtIO). Se você não entender como os bits aterrissam no disco, terá VMs que não bootam, ou pior: VMs que funcionam, mas com 50% da performance de disco devido à amplificação de escrita e desalinhamento de blocos.

Este guia ignora o marketing de "migração em um clique" e foca na engenharia de dados necessária para garantir integridade e performance.

A Migração de Storage em V2V (Virtual-to-Virtual) é o processo de transcodificação de formatos de disco (ex: VMDK esparso para RAW Zvol ou QCOW2) e a readequação da interface de barramento (SCSI/SATA para VirtIO). O sucesso depende da injeção prévia de drivers no kernel do sistema operacional convidado e do alinhamento correto dos blocos de dados no storage de destino para evitar latência excessiva de I/O.

---

O Abismo de Tradução: Diferenças de I/O entre ESXi e KVM

O maior erro conceitual é achar que o disco virtual é apenas um contêiner. Ele é uma abstração que depende de como o kernel do Guest "fala" com o Hypervisor.

No mundo VMware, suas VMs provavelmente usam o controlador LSI Logic SAS ou Paravirtual SCSI (PVSCSI). O Windows e o Linux "veem" um hardware específico. Quando você joga esse disco no Proxmox, o padrão de ouro é o VirtIO SCSI.

Se você simplesmente converter o disco e ligar a VM definindo o barramento como VirtIO, o kernel do Guest vai procurar o controlador SCSI antigo, não vai achar o novo barramento VirtIO (porque o driver não subiu no boot time) e você terá o infame BSOD INACCESSIBLE_BOOT_DEVICE no Windows ou um Kernel Panic no Linux.

Figura: Diagrama de Pilha de I/O: A diferença de latência entre vmdk em VMFS vs Zvol direto no ZFS.

A imagem acima ilustra a diferença na pilha. Note que o VirtIO corta camadas de emulação de hardware legado, falando mais diretamente com o kernel do host. Mas essa eficiência exige que o Guest saiba "falar" VirtIO antes de ser migrado.

---

Pré-Requisito Crítico: Injeção de Drivers VirtIO e Coexistência

Não confie em injetar drivers "offline" (montando o registro do Windows via ferramenta de recuperação) a menos que seja sua última opção. É propenso a falhas humanas e corrupção.

A estratégia mais robusta é a Coexistência de Controladores. Você deve ensinar o sistema operacional a falar VirtIO enquanto ele ainda roda feliz no VMware.

O "Pulo do Gato" da Preparação

Antes de desligar a VM no vSphere para a última vez:

1. Instale o pacote virtio-win.iso (no Windows) ou garanta que o módulo virtio_scsi está no initramfs (Linux).

2. Adicione um novo disco dummy na VM dentro do VMware.

3. Truque: Configure este disco dummy para usar um controlador diferente do disco de boot. Se possível, force o reconhecimento de um dispositivo VirtIO (se o VMware permitir passthrough ou compatibilidade) ou, mais comum, instale o driver VirtIO no Windows antes de ter o hardware, forçando a instalação manual via Gerenciador de Dispositivos -> Adicionar Hardware Herdado.

4. Certifique-se de que o serviço qemu-guest-agent e os drivers de viostor (Storage) e vioscsi (SCSI) estejam instalados e ativos.

Figura: O segredo do boot: Coexistência de controladores SCSI antes do desligamento final no VMware.

Ao fazer isso, o registro do Windows/Kernel do Linux marca o driver como "necessário no boot". Quando você migrar e trocar o barramento do disco principal para VirtIO SCSI no Proxmox, o SO saberá o que fazer.

---

Estratégias de Ingestão: Wizard Nativo vs. CLI

O Proxmox introduziu recentemente um assistente de importação que conecta diretamente na API do vSphere. É bonito, mas esconde o que está acontecendo. Como engenheiros, precisamos ver os números e erros.

Figura: Fluxograma de Decisão: Qual método de ingestão de disco usar baseado na sua infraestrutura.

Método 1: O Wizard de Importação do Proxmox

Use quando:

• Você tem clusters pequenos e baixa complexidade.

• A rede entre o ESXi e o Proxmox é de 10Gbps+ e estável.

• Você não se importa com um pouco de "bloat" no disco final.

O Risco: O Wizard muitas vezes converte para vm-###-disk-0 como um disco RAW importado. Se falhar no meio, o resume é complicado.

Método 2: A "Mão Pesada" com qemu-img (Recomendado)

Para volumes grandes (>1TB) ou migrações críticas, a linha de comando é soberana. Ela permite controlar a esparsidade (não copiar zeros) e a compressão.

Primeiro, traga o arquivo .vmdk (o arquivo flat, se houver) para o armazenamento local ou um share NFS montado no Proxmox.

# Inspecione o disco antes de tocar nele
qemu-img info /mnt/nfs_share/servidor-banco.vmdk

# Conversão com controle explícito
# -f vmdk: Formato origem
# -O qcow2: Formato destino (se for usar arquivo)
# -p: Mostra barra de progresso (essencial para ansiedade)
# -c: Aplica compressão (economiza espaço, custa CPU na conversão)

qemu-img convert -p -f vmdk -O qcow2 \
  /mnt/nfs_share/servidor-banco.vmdk \
  /var/lib/vz/images/100/vm-100-disk-0.qcow2

Se o destino for ZFS (Zvol), você não converte para qcow2. Você escreve direto no bloco:

# Criar o Zvol
zfs create -V 500G rpool/data/vm-100-disk-0

# DD inteligente (qemu-img sabe escrever em block devices)
qemu-img convert -p -f vmdk -O raw \
  /mnt/nfs_share/servidor-banco.vmdk \
  /dev/zvol/rpool/data/vm-100-disk-0

---

Arquitetura de Storage no Proxmox: Qcow2 vs. Raw Zvol

Esta é a decisão arquitetural mais importante pós-migração. O Proxmox suporta dois modelos principais de armazenamento local. Escolher errado aqui pode matar a performance de bancos de dados.

Tabela Comparativa: Onde armazenar seus dados

Característica	Qcow2 (sobre Ext4/XFS)	Zvol (Raw sobre ZFS)	Veredito Pragmático
Natureza	Arquivo em um Filesystem	Dispositivo de Bloco Virtual	Zvol vence em integração.
Overhead	Filesystem do Guest + Ext4 do Host	Filesystem do Guest + ZFS ARC	Zvol elimina uma camada de FS.
Snapshots	Internos do arquivo qcow2	Nativos do ZFS	ZFS é superior. Snapshots instantâneos e replicáveis.
Performance	Boa, mas sofre com "Write Amplification" em random I/O	Excelente, mas exige RAM (ARC)	Zvol é mais rápido para DBs.
Thin Provisioning	Nativo e simples	Nativo (sparse), mas cuidado com fragmentação	Empate.
Problema Crítico	Copy-on-Write Duplo: Se usar qcow2 EM CIMA de ZFS, você tem penalidade severa.	Padding: Zvols podem usar mais espaço físico devido ao volblocksize.	NUNCA use qcow2 em cima de ZFS.

A Regra de Ouro:

1. Se você tem hardware RAID (controladora física) -> Use LVM-Thin ou Ext4 com qcow2.

2. Se você tem HBA (IT Mode) e discos diretos -> Use ZFS com Zvols (Raw).

---

Sanidade Pós-Migração: Alinhamento de Blocos e TRIM

A VM subiu. O Windows deu boot. Acabou? Não. Agora você verifica se o armazenamento está saudável.

1. Verificando Alinhamento (Write Amplification)

Discos modernos e ZFS operam melhor com setores de 4K (ou maiores, ashift=12 no ZFS). Se o seu VMDK antigo foi criado no tempo do Windows Server 2003 ou XP, ele pode estar alinhado em 63 setores (legado), não 64 ou 2048.

Isso significa que cada gravação de 4K do Guest obriga o Host a ler dois blocos de 4K, modificar e gravar dois blocos. Performance cai pela metade.

No Linux Guest, verifique com:

lsblk -t
# Procure por colunas PHY-SEC e LOG-SEC.
# Verifique o start sector da partição com fdisk -l. Deve ser divisível por 8.

2. Configuração de Cache e Discard

No Proxmox (Hardware -> Hard Disk):

• Cache: Use Write Back (inseguro se não tiver nobreak/bateria na controladora) ou None (deixe o ZFS cuidar). Evite Writethrough a menos que paranoico.

• Discard: Marque esta opção. Isso habilita o TRIM. Sem isso, quando você apaga um arquivo de 10GB na VM, o ZFS/Storage do Proxmox não sabe que o espaço está livre. O disco virtual continua inchado.

---

Checklist de Rollback: Quando a VM não boota

Se você migrou e a tela ficou preta ou deu erro de boot, siga este protocolo de triagem antes de reverter o snapshot:

1. UEFI vs BIOS (SeaBIOS): O erro número 1. O VMware moderno usa EFI por padrão. O Proxmox cria VMs novas como BIOS (SeaBIOS) por padrão.

   • Sintoma: A VM liga, mas diz "No bootable device found".
   • Correção: Mude a "BIOS" da VM para OVMF (UEFI) e adicione um disco "EFI Disk".

2. Ordem de Boot: Ao trocar o barramento para VirtIO, o ID do disco muda. Verifique em "Options -> Boot Order" se o disco correto está marcado.

3. Interface de Rede: O Windows detectará uma nova placa de rede e a classificará como "Rede Pública" (Firewall restritivo). Se não consegue pingar a VM, é provável que seja o Firewall do Windows, não o roteamento.

4. MAC Address: Se a VM tem licenças atreladas ao MAC, você deve copiar o MAC Address da vNIC do VMware manualmente para a vNIC do Proxmox.

Referências & Leitura Complementar

• RFC 3720: Internet Small Computer Systems Interface (iSCSI) - Para entender os fundamentos de blocos sobre rede.

• VirtIO Specification: OASIS Virtual I/O Device (VIRTIO) Version 1.1 - Detalhes sobre como o driver paravirtualizado funciona.

• OpenZFS Documentation: zvol properties and performance tuning (volblocksize).

• Proxmox VE Admin Guide: Seção 10. Qemu/KVM & Storage Replication.