O desafio do motorista

Em seu ambiente VMware, o Windows carrega os drivers paravirtualizados VMware ( vmxnet3 para rede, pvscsi para armazenamento e assim por diante) e os vincula a identificadores de hardware específicos. Quando você move o disco para o VPC, o hardware é alterado:

• Rede: VMware vmxnet3 → Adaptador de rede de E/S virtual ( VirtIO )
• Armazenamento (inicialização): VMware PVSCSI → VirtIO adaptador SCSI
• Armazenamento (dados): VMware PVSCSI → VirtIO adaptador de bloco

Se o Windows for inicializado e encontrar IDs de hardware diferentes para o controlador de armazenamento de inicialização, ele não conseguirá inicializar (tela azul INACCESSIBLE_BOOT_DEVICE).

Solução A: Abordagem com o Sysprep

O utilitário sysprep da Microsoft "generaliza" uma instalação do Windows, redefinindo-a para um estado de primeira inicialização. Isso:

• Libera os vínculos de driver
• Redefine o identificador de segurança do Windows (SID)
• Remove informações específicas do computador
• Prepara a imagem para reimplantação

Conclua o seguinte processo para sysprep:

1. Instale os drivers VirtIO em sua máquina virtual Windows enquanto ainda estiver hospedada em VMware:

   1. Baixe a imagem ISO do virtio-win de uma instância de servidor virtual RHEL (/usr/share/virtio-win).
   2. Monte o ISO, execute virtio-win-gt-x64.exe e virtio-win-guest-tools.exe.
   3. Instale drivers para o sistema operacional e para a partição de recuperação.

2. Execute o sysprep:

   C:\Windows\System32\Sysprep\sysprep.exe /generalize /oobe /shutdown
   

3. Exporte e migre usando qualquer um dos métodos de migração, exceto a extração direta de VDDK, que é apenas para vCenter.

4. Primeira inicialização na VPC:

   • O Windows executa um mini-assistente de configuração (OOBE)
   • Detecta novo hardware, carrega os drivers VirtIO
   • Pode ser necessário reinserir a chave do produto
   • Pode ser necessário voltar a acessar o domínio

Vantagens:

• Processo bem documentado da Microsoft
• Funciona de forma confiável para implementações do Windows

Desvantagens:

• Redefine a identidade do computador (problemático para servidores unidos por domínio)
• Pode acionar a reativação do Windows
• Problemas específicos do aplicativo (alguns aplicativos não lidam bem com o sysprep)
• Requer a conclusão do OOBE na primeira inicialização

Decisão de projeto: Use o sysprep para implantações baseadas em modelos ou quando você migrar para máquinas virtuais de desenvolvimento ou teste em que a redefinição de identidade seja aceitável. Evite para servidores de produção unidos por domínio com dependências complexas de aplicativos.

Solução B: Injeção do driver “ virt-v2v ”

A ferramenta libguestfs virt-v2v pode injetar drivers VirtIO em uma instalação do Windows sem executar o sysprep. Isso:

• Monta o sistema de arquivos do Windows (sem inicializar o Windows)
• Injeta drivers VirtIO no armazenamento de drivers
• Modifica o registro para forçar o Windows a carregar esses drivers
• Preserva a identidade da máquina, a associação ao domínio e o estado do aplicativo

Pré-requisitos:

• A máquina virtual deve ser desligada de forma limpa (sem falhas, sem desligamento forçado)
• A versão do Windows deve ser compatível (Server 2008 R2 até 2025, Windows 7 até 11)
• Pacote de driver Virtio-win (disponível em sistemas RHEL: /usr/share/virtio-win)

Veja a seguir o processo para a injeção do driver virt-v2v:

1. Instale os drivers VirtIO nas partições de inicialização e recuperação do Windows (a mesma abordagem do sysprep)

2. Desligamento limpo da máquina virtual do Windows

3. Exporte/transfira o disco para uma instância de servidor virtual de trabalho utilizando qualquer um dos métodos de migração.

4. Executar virt-v2v:

   virt-v2v -i disk windows-vm.img -o disk -os /target --block-driver virtio-scsi
   

   Parâmetros:

   • -i disk: A entrada é um arquivo de imagem de disco
   • -o disk -os /target: Saída para o diretório
   • --block-driver virtio-scsi: Use o driver SCSI para o primeiro disco (necessário para volumes de inicialização VPC)

5. Se estiver gravando diretamente no dispositivo:

   ln -fs /dev/vdb /target/windows-vm-sda
   virt-v2v -i disk windows-vm.img -o disk -os /target --block-driver virtio-scsi
   

Vantagens de virt-v2v:

• Preserva a identidade da máquina (sem reativação, sem junção de redomínio)
• Não há assistente de configuração na primeira inicialização
• Estado do aplicativo intacto
• Funciona para servidores de produção

Desvantagens:

• Requer configuração híbrida RHEL/ Ubuntu
• Mais complexo que o sysprep
• Requer desligamento limpo (não processe máquinas virtuais com falha/forçadas a desligar)

Decisão de projeto: Use virt-v2v para servidores Windows de produção em que a preservação da identidade é fundamental. Aceite a complexidade adicional das ferramentas como uma compensação para migrações mais limpas.

# On Ubuntu worker virtual server instance
apt-get install libguestfs-tools
# Copy virtio-win from a RHEL system
# On RHEL: tar czf virtio-win.tar.gz /usr/share/virtio-win
# Transfer to Ubuntu and extract:
tar xzf virtio-win.tar.gz -C /usr/share/
# Now virt-v2v on Ubuntu has both SCSI support and drivers
virt-v2v -i disk windows.img -o disk -os /target --block-driver virtio-scsi

# On RHEL worker (has drivers, no SCSI support)
virt-v2v -i disk windows.img -o disk -os /tmp
# Transfer to Ubuntu worker
scp /tmp/windows-sda ubuntu-worker:/tmp/
# On Ubuntu worker (has SCSI support)
virt-v2v -i disk /tmp/windows-sda -o disk -os /target --block-driver virtio-scsi

Arquitetura do driver de armazenamento do Windows na VPC

Entender como o VPC apresenta o armazenamento ao Windows ajuda a solucionar problemas de inicialização:

Primeiro volume (disco de inicialização):

• Apresentado como VirtIO dispositivo SCSI
• Requer um driver virtio-scsi
• É por isso que o site --block-driver virtio-scsi é obrigatório

Volumes subsequentes (discos de dados):

• Apresentado como VirtIO dispositivos de bloco
• Requer um driver virtio-blk
• Driver diferente do disco de inicialização

Ambos os drivers devem ser instalados em ambos:

• O sistema operacional em execução
• O ambiente de recuperação ( WinRE )

Instalação de drivers no ambiente de recuperação

O Ambiente de Recuperação do Windows ( WinRE ) é um mini-ambiente do Windows independente, utilizado para operações de recuperação. Se não houver drivers de E/S virtual ( VirtIO ), não será possível utilizá-lo para recuperação após a migração.

Localização WinRE:

reagentc /info

Isso pode informar um volume de recuperação, mas a imagem real do WinRE pode estar em:

C:\Windows\System32\Recovery\winre.wim

Instalação de drivers em WinRE:

1. Montar a ISO do virtio-win

2. Identifique o local do WinRE por meio de reagentc /info

3. Se estiver em um volume separado, monte-o temporariamente

4. Use o DISM para injetar drivers:

   dism /mount-wim /wimfile:C:\Windows\System32\Recovery\winre.wim /index:1 /mountdir:C:\mount
   dism /image:C:\mount /add-driver /driver:E:\viostor\w10\amd64 /recurse
   dism /image:C:\mount /add-driver /driver:E:\netkvm\w10\amd64 /recurse
   dism /unmount-wim /mountdir:C:\mount /commit
   

Considerações sobre a partição GPT:

Se o seu disco do Windows usa GPT (não MBR):

• Use list volume e select volume em vez de list partition
• A configuração das IDs de volume é diferente:
  • Volume de dados: set id=ebd0a0a2-b9e5-4433-87c0-68b6b72699c7
  • Volume do sistema: set id=c12a7328-f81f-11d2-ba4b-00a0c93ec93b

Versões do Windows compatíveis

Red Hat o pacote virtio-win da Microsoft fornece drivers para:

Windows Server:

• 2008 R2
• 2012, 2012 R2
• 2016, 2019, 2022, 2025

Cliente Windows:

• 7
• 8, 8.1
• 10
• 11

Não há suporte para versões mais antigas (Server 2003, 2008 non-R2, Vista).

A tabela a seguir é a matriz de decisão de design para o Windows