Virtio-blk vs Virtio-scsi: Arquitetura de I/O para Workloads NVMe

A evolução do armazenamento de dados nos últimos anos criou um problema interessante, que gosto de chamar de "o paradoxo da latência". Quando operávamos em um mundo dominado por discos rotacionais (HDD) e arrays SAS, a latência do dispositivo físico era tão alta (milissegundos) que a camada de virtualização podia se dar ao luxo de ser "pesada". O software não era o gargalo.

Hoje, com o advento do NVMe e memórias de classe de armazenamento (como Intel Optane ou as novas NANDs de ultra-baixa latência), o cenário inverteu. O hardware é tão rápido que o hypervisor e os drivers do Guest OS se tornaram os principais ofensores na latência total da transação.

Ao desenhar uma infraestrutura de virtualização moderna, seja baseada em KVM (Proxmox, Red Hat Virtualization) ou adaptando conceitos para o mundo VMware, a escolha entre Virtio-blk e Virtio-scsi não é apenas uma questão de "qual driver funciona". É uma decisão arquitetural que define como o I/O flui do sistema operacional convidado até o bloco físico no seu array all-flash.

Resumo em 30 segundos

• Virtio-blk: É o caminho mais curto e leve. Menor overhead de CPU e latência ligeiramente menor, ideal para performance bruta, mas historicamente menos flexível em recursos de gerenciamento.
• Virtio-scsi: Oferece compatibilidade total com o conjunto de comandos SCSI. Essencial para suporte robusto a TRIM/UNMAP, gerenciamento de centenas de discos por VM e integração com storage externo complexo.
• O Fator Decisivo: A escolha do driver é inútil se você não configurar IOThreads e Multi-Queue. Sem isso, o processamento de I/O compete com a aplicação pela mesma vCPU.

---

O Paradoxo da Latência em Infraestrutura All-Flash

Para entender a diferença entre os drivers, precisamos visualizar o caminho do dado. Em um ambiente virtualizado, uma operação de escrita não vai direto para o disco. Ela atravessa o filesystem do Guest, a camada de bloco do Guest, o driver paravirtualizado, o anel de comunicação (Virtqueue), o processo do QEMU no Host e, finalmente, o driver de armazenamento do Host (seja um arquivo qcow2, um volume LVM ou um Zvol).

Figura: O "Tax" da Virtualização: Com NVMe, o tempo gasto no software supera o tempo de acesso à mídia.

Quando usamos armazenamento NVMe capaz de entregar centenas de milhares de IOPS com latência na casa dos microssegundos, qualquer tradução de protocolo adiciona um custo perceptível.

O Virtio-blk foi desenhado para ser simples. Ele expõe o dispositivo de bloco diretamente ao Guest. Não há simulação de cabos, controladoras ou protocolos complexos. É um tubo direto.

O Virtio-scsi, por outro lado, mantém a semântica do protocolo SCSI. Isso significa que o Guest "vê" uma controladora SAS/SCSI e fala essa língua. O QEMU então precisa traduzir esses comandos SCSI para operações de backend. Essa tradução é o que chamamos de overhead de emulação, embora no caso do Virtio seja uma emulação acelerada (paravirtualização).

A Anatomia do Funil de Serialização no QEMU

Aqui é onde a maioria dos administradores de storage falha. Eles compram o SSD NVMe mais rápido do mercado, configuram o driver correto, mas esquecem como o QEMU processa esse I/O.

Por padrão, o I/O de uma VM é processado na thread principal do QEMU ou nas vCPUs. Isso cria um "funil". Se sua VM está rodando um banco de dados pesado (SQL Server ou PostgreSQL) consumindo muita CPU para processar queries, o I/O de disco vai disputar ciclos de clock com o processamento de dados. O resultado é jitter (variação de latência).

💡 Dica Pro: Em ambientes de alta performance, o uso de IOThreads é obrigatório. Isso cria threads dedicadas no Host exclusivamente para processar o I/O daquela controladora de disco, desacoplando o "dataplane" do processamento geral da VM.

Virtio-blk: A Abordagem "Lean"

O Virtio-blk é extremamente eficiente porque elimina a camada SCSI do Guest. O sistema operacional convidado não precisa montar pacotes de comando SCSI (CDBs); ele apenas envia solicitações de leitura/escrita para o anel de virtio.

Vantagens:

• Latência: Marginalmente menor que o virtio-scsi em testes sintéticos de 4K.

• Simplicidade: Menos código no caminho crítico.

Desvantagens:

• Limitação de Dispositivos: Historicamente limitado no número de discos por barramento PCI (embora contornável com multifunção).

• Comandos de Gerenciamento: Suporte a comandos avançados de storage (como SCSI Reservation para clusters) é limitado ou inexistente.

Virtio-scsi: A Abordagem "Enterprise"

O Virtio-scsi foi criado para superar as limitações de escalabilidade do blk. Ele permite centenas de dispositivos por controladora e, crucialmente, passa comandos SCSI quase transparentemente.

Por que a abstração SCSI adiciona overhead? Imagine que você quer pedir um café.

• Virtio-blk: Você grita "Café!" para a cozinha.

• Virtio-scsi: Você preenche um formulário padrão ISO-9001 solicitando um café, entrega ao garçom, que traduz o formulário para a cozinha.

Essa "burocracia" do SCSI permite coisas vitais para o storage moderno, principalmente o UNMAP (TRIM). Embora o virtio-blk tenha ganho suporte a discard em versões recentes, o virtio-scsi lida com isso de forma nativa e robusta, garantindo que, quando você apaga um arquivo de 100GB na VM, o seu array All-Flash (ou seu pool ZFS/Ceph) realmente libere esse espaço.

Figura: Comparativo de Latência: A diferença diminui conforme a profundidade da fila (Queue Depth) aumenta e o Multi-Queue entra em ação.

Desacoplando o Dataplane: Multi-Queue é o Segredo

Independentemente de você escolher blk ou scsi, o verdadeiro ganho de performance em storage NVMe vem do paralelismo. Um único anel de virtio (single queue) é um gargalo em sistemas multicore modernos.

A tecnologia Virtio Multi-Queue permite que o driver de armazenamento crie múltiplas filas de comando, idealmente uma para cada vCPU do Guest.

1. Sem Multi-Queue: Todas as vCPUs enviam I/O para uma única fila. Ocorre locking (bloqueio) para evitar corrupção, serializando o acesso.

2. Com Multi-Queue: A vCPU 0 escreve na Fila 0, a vCPU 1 na Fila 1. O bloqueio é eliminado ou drasticamente reduzido.

Para workloads NVMe, onde o dispositivo físico suporta 64.000 filas, limitar a VM a uma única fila é desperdiçar o hardware.

⚠️ Perigo: Habilitar Multi-Queue sem ajustar o número de vetores de interrupção (MSI-X) pode causar degradação. O Guest precisa ser capaz de rotear as interrupções de conclusão de I/O para a CPU correta.

Validação de Throughput e Distribuição de Interrupções

Como validar se sua escolha arquitetural funcionou? Não confie apenas na "sensação" de velocidade. Use dados.

Ao testar com ferramentas como fio, observe não apenas os IOPS, mas o consumo de CPU no Host (via htop ou esxtop equivalente) e as interrupções no Guest.

No Linux Guest, verifique /proc/interrupts. Se você configurou Multi-Queue corretamente (seja em virtio-blk ou scsi), você deve ver interrupções de "virtio-input" e "virtio-output" distribuídas entre todos os núcleos da CPU, e não martelando apenas o CPU0.

Cenário de Exemplo:

• VM: Database Server, 8 vCPUs.

• Storage: NVMe Namespace passado via QEMU (raw image).

• Configuração Ideal:

  • Driver: Virtio-scsi (para flexibilidade futura).
  • Controladora: iothread=1 (dedicada).
  • Filas: num_queues=8 (casando com as vCPUs).

Se você usar essa configuração, a diferença de performance bruta entre blk e scsi se torna negligenciável para 99% dos workloads, mas você ganha a robustez do stack SCSI.

Figura: Validação de Sucesso: Interrupções de I/O distribuídas uniformemente entre os núcleos da VM confirmam o funcionamento do Multi-Queue.

O Impacto no Ecossistema: Snapshots e vMotion

Não podemos falar de storage sem falar de operações de Dia 2. O Virtio-blk é simples, mas essa simplicidade às vezes cobra o preço na integração. Embora o QEMU moderno lide bem com live migration (vMotion) usando virtio-blk, o Virtio-scsi tende a ser mais resiliente em cenários complexos, como quando há mudanças na topologia de disco ou quando se utiliza SCSI Persistent Reservations para clusters de failover (ex: Windows Failover Cluster rodando sobre KVM).

Se o seu ambiente depende de snapshots consistentes de aplicação (quiescing) ou integração profunda com arrays de armazenamento que enviam comandos UNMAP para recuperar espaço, o Virtio-scsi é a escolha segura. O Virtio-blk pode economizar alguns nanossegundos, mas o Virtio-scsi pode salvar seu fim de semana ao garantir que o reclaim de espaço funcione automaticamente.

Recomendação Estratégica

A batalha entre Virtio-blk e Virtio-scsi não é sobre quem é o "melhor", mas sobre alinhamento de requisitos.

Minha recomendação para infraestruturas modernas baseadas em NVMe:

1. Adote Virtio-scsi como padrão ("Go-to"): A flexibilidade, o suporte robusto a TRIM/UNMAP e a capacidade de anexar dezenas de discos a uma única controladora superam a vantagem marginal de latência do virtio-blk na maioria dos casos.

2. Reserve Virtio-blk para Edge Cases: Use apenas se você tiver um workload extremamente sensível a latência (High Frequency Trading, Caches em tempo real) onde cada microssegundo de overhead de tradução SCSI conta, e onde recursos de gerenciamento de storage são secundários.

3. A Regra de Ouro: Nunca implemente nenhum dos dois sem avaliar a configuração de IOThreads e Multi-Queue. Um driver Virtio-scsi bem tunado com Multi-Queue superará um Virtio-blk "single-threaded" em qualquer dia da semana.

O futuro aponta para tecnologias como vDPA (Virtio Data Path Acceleration), que prometem trazer a performance de passthrough de hardware com a flexibilidade do virtio, mas até que isso se torne onipresente, dominar a stack atual é o que diferencia um ambiente lento de um que voa baixo.

Referências & Leitura Complementar

• OASIS Virtio Specification 1.1: Detalhes técnicos sobre a implementação dos dispositivos de bloco e SCSI.

• QEMU/KVM Performance Tuning Guidelines: Documentação oficial sobre IOThreads e afinidade de CPU.

• NVMe Specification 1.4: Para entendimento das filas de hardware e paralelismo nativo.

• Red Hat Enterprise Linux Virtualization Tuning Guide: Capítulos específicos sobre I/O scheduler e Virtio-scsi.