Entendendo os dois modos de acesso a disco em VMs
O VMware oferece basicamente duas formas de uma máquina virtual acessar um datastore ou storage LUN. A escolha entre elas define tudo: performance, escalabilidade, funcionalidades de backup e até se você consegue migrar a VM de um host para outro sem dor de cabeça.
diferencie vdm de rdm citando um exemplo de cada respectivamente
A diferença fundamental é simples, mas as implicações não são triviais. Vamos começar pelo conceito. VDM é o modo padrão onde a VM vê um disco virtual (.vmdk) armazenado como arquivo dentro de um datastore. O hipervisor abstrai o storage físico por baixo, e tudo flui pela stack de arquivo do ESXi. RDM, por outro lado, mapeia diretamente um LUN SCSI do storage para a VM. O disco não existe como arquivo; ele é um apontamento direto para o dispositivo de bloco no storage. No dia a dia, eu já vi equipes escolherem RDM achando que resolviam problemas de performance. Na maioria das vezes, eles só criavam outra camada de complexidade sem ganho real. Vou explicar onde cada um se encaixa de verdade.
Como funciona VDM na prática
VDM cria um arquivo .vmdk no datastore. Esse arquivo pode estar em VMFS, NFS ou qualquer storage compatível. A VM acessa esse arquivo como se fosse um disco IDE, SCSI ou NVMe, mas na verdade todas as operações de leitura e escrita passam pela camada do hipervisor e pelo cache do datastore. O maior benefício do VDM é a compatibilidade total com todas as funcionalidades do vSphere. Você pode fazer vMotion, DRS, SRM, snapshots, backup via agente ou imagem, e clone instantâneo sem qualquer problema. Se a sua carga de trabalho não tem requisitos especiais de latência ou controle direto sobre o storage, VDM é a resposta correta em praticamente todos os casos.
Um exemplo clássico: uma VM com SQL Server rodando em um datastore VMFS com VMDK em SSD. A VM é migrada semanalmente entre hosts via DRS. Aqui, VDM é a escolha óbvia. O DRS redistribui a VM baseada em uso de CPU e memória, e como o disco é um arquivo no datastore compartilhado, a migração é transparente. Se você usasse RDM, o DRS ainda funcionaria, mas perderia flexibilidade em cenários mais específicos, como certos tipos deStorage vMotion.
Como funciona RDM na prática
RDM funciona como um túnel direto entre a VM e o LUN SCSI no storage. O arquivo .rdm que você vê no datastore do ESXi é apenas um descritor de alguns kilobytes — um ponteiro. Os dados reais ficam no LUN. A VM acessa o disco em modo physical compatibility ou virtual compatibility, dependendo da configuração. O modo physical permite que o sistema operacional da VM veja o dispositivo SCSI puro, com comandos SCSI completos. Isso é essencial para clusters como MSCS no Windows ou Oracle RAC, onde múltiplas VMs precisam acessar o mesmo disco simultaneamente. O modo virtual mantém algumas limitações para preservar funcionalidades como snapshots, mas ainda oferece acesso mais direto ao storage.
👉 Clique no botão abaixo para saber mais sobre o assunto!
Um exemplo onde RDM faz sentido: um cluster Oracle RAC com duas VMs acessando o mesmo ASM diskgroup. Cada node do cluster precisa enxergar o mesmo dispositivo SCSI em raw mode para que o ASM gerencie os extents corretamente. Ninguém resolve isso com VMDK compartilhado de forma confiável. O RDM no modo physical é o caminho padrão documentado pela Oracle para esse cenário.
O problema que ninguém conta sobre RDM
Aqui está a parte que a documentação quase nunca enfatiza com a força que deveria. RDM tem limitações sérias que transformam maintenance routine em dor de cabeça. Snapshots não funcionam em discos RDM physical. Backups baseados em imagem falham porque o agente não consegue capturar o estado consistente do disco. Storage vMotion é extremamente limitado — você pode migrar a VM, mas o RDM precisa permanecer no mesmo LUN, o que reduz drasticamente as opções de move. Eu perdi uma manhã inteira tentanto fazer backup de um cluster RDM com Veeam. O job simplesmente ignorava os discos mapeados. A solução foi reconfigurar tudo para VMDK com uma camada adicional de agent-level backup dentro das VMs, o que adicionou overhead de CPU mas restaurou a capacidade de backup.
Outro ponto prático: monitoramento. Com VDM, o vSphere mostra o uso de disco, latência e throughput de forma consolidada. Com RDM, você perde granularidade porque o disco não é mais gerenciado pela stack VMFS do ESXi. Ferramentas como vSan Health e IOPs throttling não se aplicam da mesma forma.
Quando NÃO usar cada um
Não use RDM se você precisa de snapshots frequentes, backup via image-level, ou planeja migrar VMs entre datacenters com SRM. O custo de manutenção não compensa o suposto ganho de performance, que na maioria dos cenários é marginal — talvez 5 a 10% em IOPS brutos em workloads de escritura sequencial pesada, desaparecendo completamente em workloads random access típicas de produção. Não use VDM se sua workload exige acesso raw a disco SCSI, como clusters de alta disponibilidade que dependem de quorum disk ou lock SCSI de nível hardware. Nesse caso, RDM no modo physical é obrigatório, não opcional.
A regra prática que eu uso: comece sempre com VDM. Só migre para RDM se houver um requisito técnico documentado que exija acesso SCSI raw, e documente esse requisito com o nome da workload, a versão do software e a justificativa técnica. Sem isso, você está apenas adicionando complessidade sem propósito.
