O Passthrough de controladora impede o uso de Snapshots da VM?

Geralmente, sim. Ao passar a controladora física (HBA) diretamente para a VM, o hypervisor perde a visibilidade do sistema de arquivos subjacente, impedindo snapshots em nível de VM. O gerenciamento de snapshots deve ser feito internamente pelo sistema operacional da VM (ex: ZFS snapshots).

É seguro usar Hardware RAID tradicional com ZFS em uma VM?

Não. O ZFS precisa de acesso direto aos discos para gerenciar a integridade dos dados e curar corrupção silenciosa (bit rot). Colocar uma controladora RAID em hardware na frente do ZFS esconde a geometria real do disco e impede a autocorreção eficaz.

Qual opção oferece menor latência: Passthrough ou VirtIO?

O Passthrough oferece a latência mais baixa possível, pois elimina a camada de emulação do hypervisor, permitindo que a VM fale diretamente com o hardware via DMA. No entanto, drivers modernos de VirtIO são extremamente otimizados e a diferença é imperceptível para a maioria das cargas de trabalho que não sejam bancos de dados de altíssima frequência.

RAID na Virtualização: Passthrough de Controladora vs Software RAID no Hypervisor

Esta é uma das discussões mais polarizadas em arquitetura de infraestrutura. De um lado, os puristas do "bare metal" que exigem acesso direto ao disco; do outro, os administradores que preferem a abstração conveniente dos arquivos de disco virtual (vmdk/qcow2).

Como arquiteto, minha resposta padrão é "depende", mas o "depende" aqui não é uma fuga. É uma questão de calcular onde você quer pagar o preço: na complexidade de configuração inicial (Passthrough) ou na latência e sobrecarga de gerenciamento (Software RAID no Hypervisor). Não existe almoço grátis em I/O.

Vamos dissecar essa topologia para que você pare de adivinhar e comece a arquitetar.

O Dilema do Acesso ao Armazenamento na Virtualização

Passthrough de Controladora (PCIe Passthrough) consiste em dedicar um dispositivo de hardware físico (como uma HBA LSI ou um controlador NVMe) exclusivamente a uma Máquina Virtual, ignorando a camada de gerenciamento do Hypervisor. Software RAID no Hypervisor, por outro lado, envolve o Hypervisor (ESXi, Proxmox, Hyper-V) gerenciando o array de discos e apresentando um "disco virtual" genérico para a VM, abstraindo a geometria física subjacente.

A Anatomia do I/O: Onde a paridade é calculada?

Para tomar essa decisão, você precisa visualizar o caminho do dado. O maior erro que vejo em campo é a ignorância sobre quem está "pagando a conta" do cálculo de paridade (RAID 5/6/Z1/Z2) e do gerenciamento de cache.

Se você usa Software RAID no Hypervisor (ex: ZFS no Proxmox entregando um zvol para a VM), o fluxo é:

Aplicação na VM grava dados.
Sistema de Arquivos da VM (EXT4/NTFS) processa.
Driver de disco virtual (VirtIO/PVSCSI) encapsula.
Context Switch (VM -> Hypervisor).
Hypervisor recebe o I/O.
Sistema de Arquivos do Hypervisor (ZFS/VMFS) calcula paridade/checksum.
Driver físico grava no disco.

Figura: Fluxo de I/O: A diferença crítica no caminho dos dados entre abstração e acesso direto.

Note o passo 4. Cada operação de I/O paga um pedágio de CPU para alternar contextos. Em cargas de trabalho sequenciais massivas, isso é trivial. Em bancos de dados transacionais com alto IOPS aleatório, isso é latência pura.

Se você usa Passthrough, a VM fala diretamente com o hardware. O Hypervisor apenas mapeia os endereços de memória via IOMMU (Input-Output Memory Management Unit). O sistema operacional da VM (ex: TrueNAS, Unraid ou uma VM Linux com mdadm) vê o disco físico real. O "pedágio" do Hypervisor é drasticamente reduzido.

PCIe Passthrough (IOMMU): Entregando o metal para a VM

O Passthrough é a implementação técnica do conceito de "isolamento estrito". Quando você ativa o VT-d (Intel) ou AMD-Vi, você está dizendo ao chipset: "Este dispositivo PCI (a controladora de disco) pertence exclusivamente a este domínio de memória (a VM)".

Como validar se sua arquitetura suporta Passthrough

Não basta querer usar. O hardware precisa permitir o isolamento dos grupos IOMMU. Se a sua controladora de disco compartilha o mesmo grupo IOMMU que a sua placa de rede ou, pior, a ponte PCI raiz, você não conseguirá passar um sem derrubar o outro.

Para verificar grupos IOMMU em um host Linux/Proxmox antes de decidir a arquitetura:

#!/bin/bash
shopt -s nullglob
for g in /sys/kernel/iommu_groups/*; do
    echo "IOMMU Group ${g##*/}:"
    for d in $g/devices/*; do
        echo -e "\t$(lspci -nns ${d##*/})"
    done
done

O Trade-off do Passthrough: Ao entregar a controladora para a VM, o Hypervisor fica cego.

O Hypervisor não pode ver a temperatura dos discos (facilmente).
O Hypervisor não pode fazer snapshots daquele armazenamento (pois ele não controla o sistema de arquivos).
O Hypervisor não pode usar esse espaço para armazenar outras VMs ou ISOs.

Software RAID no Hypervisor: A camada de abstração conveniente

Esta é a rota padrão para 90% das empresas, e por um bom motivo: flexibilidade.

Quando o Hypervisor gerencia o RAID (seja via Hardware RAID card apresentando um volume lógico, ou via ZFS/vSAN), a VM é apenas um arquivo. Isso significa que:

Migração (vMotion/Live Migration): É trivial mover a VM entre hosts.
Snapshots: Você pode congelar o estado da VM antes de um update crítico.
Thin Provisioning: Você pode prometer 10TB para a VM gastando apenas 100GB reais inicialmente.

O Risco Oculto: Write Amplification e Double Caching O perigo aqui é a redundância de camadas. Se você roda ZFS no Host e ZFS na VM (sobre um disco virtual), você está criando um pesadelo de performance conhecido como CoW sobre CoW (Copy-on-Write sobre Copy-on-Write).

Se a VM tenta alinhar um bloco de 4K, o Hypervisor pode ter que reescrever um bloco de 128K (recordsize padrão do ZFS). Isso destrói o desempenho de escrita e a vida útil de SSDs de consumo.

Regra de Ouro: Se usar RAID no Hypervisor, o sistema de arquivos da VM deve ser "burro" e leve (EXT4, XFS), não outro gerenciador de volume complexo.

Comparativo Técnico: Passthrough vs Virtual Disk

Abaixo, uma análise direta dos atributos que impactam o TCO e a operação diária.

Atributo	PCIe Passthrough (IOMMU)	Software RAID no Hypervisor (Virtual Disk)
Latência de I/O	Nativa (Quase zero overhead)	Média/Alta (Depende da fila do Hypervisor)
Portabilidade da VM	Baixa (A VM está "presa" ao hardware físico)	Alta (A VM é um arquivo agnóstico)
Snapshots	Complexo (Depende do OS da VM, ex: ZFS snapshots)	Simples (Nativo do Hypervisor)
Recuperação de Desastre	Exige hardware similar ou reconfiguração	Restauração de arquivo em qualquer hardware
Monitoramento S.M.A.R.T	Direto na VM	Apenas no Host (VM não vê saúde do disco)
Uso Ideal	NAS Virtualizado (TrueNAS), Storage Server	Aplicações Gerais, Web Servers, AD, DBs leves

Portabilidade e Recuperação: O pesadelo do Vendor Lock-in

Aqui é onde a teoria encontra a realidade da operação às 3 da manhã de um domingo.

Se você usa Passthrough de uma controladora RAID de Hardware (ex: PERC, HP SmartArray) para uma VM, e essa placa morre, você está em apuros. Você precisa de uma placa idêntica (ou compatível com a mesma estrutura de metadados proprietários) para recuperar os dados.

Se você usa Passthrough de uma HBA (IT Mode) para ZFS/Software RAID na VM, o risco diminui. Você pode plugar os discos em qualquer controladora HBA "burra", em qualquer servidor, e importar o pool ZFS. Esta é a única forma de Passthrough que eu recomendo para arquiteturas resilientes.

No modelo de RAID no Hypervisor, se o servidor inteiro pegar fogo, basta pegar os discos, importar no novo Hypervisor e registrar as VMs novamente. A camada de abstração protege a VM das especificidades do hardware.

Veredito Arquitetural: Quando usar Passthrough vs Virtual Disk

Não decida baseado em "qual é mais rápido". Decida baseado em "quem deve gerenciar os dados".

Figura: Matriz de Decisão: Escolhendo a topologia de storage baseada em requisitos operacionais.

Use Passthrough (IOMMU) SE:

Você está virtualizando um NAS/SAN (TrueNAS, Unraid, OMV): Esses sistemas operacionais precisam de acesso direto aos discos para gerenciar cache, integridade e S.M.A.R.T. corretamente. Virtualizar o ZFS sem acesso direto aos discos é pedir para perder dados.
Performance Máxima de BD: Você tem um banco de dados que satura o barramento NVMe e o overhead do virtio-scsi ou nvme-of é inaceitável.
Tape Drives/Hardware Legado: Você precisa que a VM acesse um dispositivo de fita ou dongle de segurança específico.

Use Software RAID no Hypervisor (Virtual Disks) SE:

Consolidação de Cargas Gerais: Você tem 20 VMs (Web, App, AD). Não faz sentido dedicar controladoras para cada uma.
Necessidade de Alta Disponibilidade (HA): Recursos como vMotion/Live Migration exigem armazenamento abstraído ou compartilhado. Passthrough geralmente quebra o HA automatizado.
Simplicidade Operacional: Você quer fazer backup da VM inteira copiando um arquivo .qcow2 ou .vmdk.

Resumo para o Arquiteto

O Passthrough é uma ferramenta poderosa para transformar uma VM em um appliance de armazenamento dedicado. No entanto, ele quebra o paradigma da virtualização (abstração de hardware). Use-o apenas quando a aplicação (como o ZFS dentro do TrueNAS) for inteligente o suficiente para gerenciar o hardware melhor do que o Hypervisor. Para todo o resto, a abstração do disco virtual, apesar do pequeno custo de performance, paga-se em flexibilidade e facilidade de recuperação.

Referências & Leitura Complementar

Intel Virtualization Technology for Directed I/O (VT-d) Architecture Specification: Detalhes técnicos sobre como o remapeamento de DMA e interrupções funciona no nível do silício.
ZFS on Linux - The intent log (ZIL): Compreensão crítica para entender por que o Passthrough é vital para latência de escrita síncrona em ZFS virtualizado.
VMware KB 1010789: Configuração de Passthrough (DirectPath I/O) e limitações associadas (perda de vMotion, Snapshots).
Proxmox VE Admin Guide - PCI Passthrough: Documentação prática sobre implementação de IOMMU em ambientes baseados em KVM.