Os arquivos da área de trabalhoImplantando o Windows em um mundo virtual

Wes Miller

A computação virtual está em todos os lugares. Se você ainda não está aproveitando as suas vantagens, deveria estar. A virtualização reduz a dependência do hardware ao criar, essencialmente, sua própria camada de abstração de hardware e ao permitir que você mova um ou mais sistemas convidados, como os sistemas operacionais Windows Server ou o cliente do Windows, entre os sistemas host.

É claro que a virtualização é diferente da emulação, já que ela não imita o processador do convidado. Ela simplesmente representa os recursos do sistema host de uma forma que os sistemas convidados possam acessá-lo. Como resultado, os sistemas host são genéricos para os convidados. Geralmente você pode mover um convidado virtual de um sistema criado por um OEM para um criado por outro OEM — o hardware do host normalmente não importa. Mas é preciso fazer algumas advertências. Por exemplo, se você mover um convidado do hardware com um processador de um fornecedor de CPU, como a AMD, para outro, como a Intel, poderá ter problemas (dependendo da tecnologia de virtualização utilizada). Isso acontece porque a tecnologia de computação virtual só passa informações de um host para o convidado e vice-versa; ela não emula uma CPU específica para o convidado (como faz, por exemplo, o Microsoft® Virtual PC executado em um Macintosh baseado em PowerPC herdado).

No entanto, a virtualização emula componentes fundamentais de hardware para o convidado. Quase sempre isso está limitado à rede, vídeo (geralmente um dispositivo bastante limitado sem uma GPU emulada avançada) e armazenamento em massa. Isso abrange todas as funções ao apresentar um ou mais tipos de dispositivos emulados por software para o convidado. Agora, se você lê a minha coluna há algum tempo, observará que é a mesma lista de dispositivos considerada pelo Windows® PE. Na virtualização, esses são os mesmos tipos de dispositivos que você precisa ter para que o Windows realmente funcione. Adicionalmente, todas as tecnologias de virtualização devem emular um BIOS. Embora também possam emular a EFI (Extensible Firmware Interface), a seleção limitada de sistemas operacionais baseados em EFI de hoje faz com que essa característica tenha um uso limitado. Toda essa emulação permite que os convidados virtuais sejam reinicializados. O BIOS e cada um dos dispositivos emulam um dispositivo real em software e o apresentam aos convidados. Isso significa que eles exigem os mesmos drivers (nem sempre os drivers fornecidos pelo Windows) que o dispositivo real exigiria. Esse é um conceito importante que você deve ter em mente.

Embora algumas tecnologias de virtualização também permitam que dispositivos USB (ou USB 2.0) façam interface com eles, não mergulharei em seus aspectos particulares aqui. Além dos dispositivos USB que exigem outros drivers (impressoras, placas sem fio USB e assim por diante) ou certo suporte a DirectX® (que geralmente não está presente na maioria das tecnologias de virtualização), não há muito que fazer para que tudo funcione. Tenha em mente que o suporte para USB e outros dispositivos não emulados depende, é claro, da tecnologia de virtualização utilizada. Certifique-se de que você conhece as limitações (as pontas afiadas, como gosto de dizer) do produto de virtualização que está usando antes de tentar fazer com que novos dispositivos funcionem com ele.

Hoje, existem dois fornecedores principais de tecnologia de virtualização para Windows: a Microsoft e a VMware (vmware.com). Também existem outros fornecedores promissores, como a Parallels (parallels.com).

Agora que você tem uma idéia do que é a virtualização, vou passar o resto desta coluna explicando como configurá-la, como evitar as armadilhas mais comuns e como implantá-la em algumas máquinas do seu ambiente.

Implantação virtual

A implantação de sistemas virtuais não precisa ser diferente da implantação de sistemas físicos. Mas como você verá, existem alguns bons motivos para ser diferente.

Nos primórdios do Windows NT®, você tinha que implantar via configuração. Você podia criar um script, mas tinha de passar por todo o processo. Após a conclusão da configuração, a cópia dessa imagem para vários sistemas, embora fosse um conceito bastante útil, simplesmente não era suportado.

Entretanto, eventualmente, a Microsoft decidiu que fazia sentido oferecer suporte a sistemas Windows NT em discos duplicados ou "clonados". Assim, hoje, todos os métodos disponíveis para a implantação de sistemas físicos também estão disponíveis para a implantação de sistemas virtuais. Você pode usar: o Winnt32 (ou setup.exe no caso do Windows Vista® e do Windows Server® 2008); o Windows PE (1.x ou 2.x, dependendo do cliente que está sendo implantado, como explicado em minhas colunas anteriores); o RIS (Serviços de Instalação Remota), o WDS (Serviços de Implantação do Windows) ou o Sysprep (a ferramenta Preparação do Sistema para implantação apresentada no Windows NT 4.0) e a sua tecnologia de duplicação de discos favorita (o ImageX, por exemplo).

Mas é claro que você só terá de fazer isso na primeira vez em que implantar um sistema operacional específico. Depois disso, talvez você só queira copiá-lo. Mas há um problema com os métodos de duplicação baseados em disco como os que acabei de mencionar.

Usando o Sysprep

A decisão original da Microsoft de não oferecer suporte à duplicação baseada em disco foi estimulada principalmente pelo SID (Identificador de Segurança do Windows NT). Felizmente, o Sysprep oferece uma solução. Mas primeiro vamos examinar o problema que ele resolve. Como discutido em support.microsoft.com/kb/314828, o SID consiste em um número de revisão de estrutura de SID (normalmente um Identificador Global Exclusivo, ou GUID) que identifica um computador individual baseado em Windows. Esse ID é usado como a raiz do identificador para todas as contas locais. As contas locais possuem seu próprio identificador exclusivo, chamado de RID (Identificador Relativo). O RID consiste em um ID de conta concatenado no final do SID. Assim, a combinação dos dois se torna o identificador de contas locais.

Vamos ver porque isso é um problema ao usarmos o SID de Administrador S-1-5-21-191058668-193157475-1542849698-500. Aqui, S-1-5 é o descritor que define que esse é um SID (o S é onipresente na representação textual do SID) e que 1 e 5 representam o número de revisão do SID do Windows NT e o valor do identificador de autoridade (aqui, a Segurança do Windows), respectivamente. O resto é o SID real, incluindo o número 500, que o identifica como um SID reconhecido — o da conta Administrador do Windows. A conta Administrador é criada por padrão (e que não pode ser excluída) em todas as instalações do Windows e possui um SID que termina em 500. As contas de usuários locais adicionadas ao Windows após a instalação iniciam a iteração a partir de 1000.

O PSGetSID, disponível no Windows Sysinternals (mencionado em minha coluna sobre PSTools, em technetmagazine.com/issues/2007/03/DesktopFiles), permite que você enumere um SID para um determinado usuário em um sistema ou o SID do sistema. Consulte a Figura 1 para ver a saída de PSGetSID para o SID do meu sistema virtual e o SID da minha conta de usuário, 1003.

Figure 1** Output of PSGetSID for a virtual system's SID and the SID of user account 1003 **(Clique na imagem para aumentar a exibição)

Uma vez que os RIDS de contas locais se baseiam nesse SID, o problema que acontece quando você duplica um sistema em disco ou simplesmente copia uma imagem de máquina virtual deve se tornar relativamente aparente. Ao não alterar o SID (a principal tarefa do Sysprep, embora não seja a única), você poderia terminar com uma cópia do componente principal que torna um sistema Windows exclusivo. Se o Sistema A e o Sistema B tiverem o mesmo SID de Administrador, os usuários em cada um dos sistemas poderiam se identificar de forma legítima como o mesmo usuário. O mesmo seria verdadeiro para todas as contas locais do Sistema B quando se autenticassem no Sistema A e vice-versa. Pior, esses sistemas teriam o mesmo SID quando apresentados no Active Directory®. Dessa forma, se você permitir que o Sistema A se autentique em um recurso do domínio, mas não permitir que o Sistema B faça isso, acarretará uma colisão. Se você definir que B deve ser negado, então A também será negado.

Portanto, é fundamental que você regenere os SIDs em sistemas que utilizam o Sysprep — especialmente em cenários de sistemas virtuais, uma vez que as imagens de sistema podem ser propagadas com muita facilidade. Além disso, não utilize uma ferramenta de alteração de SID de terceiros — somente o Sysprep. O Sysprep foi projetado, testado e suportado pela Microsoft para a preparação de sistemas para duplicação (até mesmo os sistemas virtuais). Consulte a Figura 2 para obter um exemplo da aparência do Sysprep antes da alteração do SID em um sistema. Mantenha sempre a opção "Não regenerar os identificadores de segurança" desmarcada se estiver preparando o sistema para duplicação como sua próxima etapa.

Figure 2** "Don't regenerate security identifiers" should be unchecked when preparing for duplication **

Além da atualização do SID para um novo ID, o Sysprep também modifica os armazenamentos de dados privados que reconhece para refletir o SID e o nome da máquina ou para alterar sua criptografia para que ela funcione com o novo SID. Alguns exemplos são os armazenamentos de dados e os valores das Tarefas Agendadas da Metabase do IIS (caso o IIS esteja instalado).

O Sysprep também exclui obrigatoriamente todas as NICs do sistema e leva com ele os dados de configuração de rede das placas. Como a configuração de rede "se destaca" da NIC no registro, e o relacionamento dessa NIC se baseia em seu ID de Hardware (que fora de uma passagem de sistema virtual para virtual é freqüentemente corrompido), o Sysprep limpa esses dados tradicionalmente abandonados.

O Sysprep também limpa todas as informações de associação ao Active Directory de um sistema. Como resultado, ele deve forçar a remoção de um sistema do domínio como parte de seu trabalho. Isso garante que os sistemas que acabaram de receber novos SIDs possam ser associados ao domínio com segurança. Alguns utilitários que alteram o SID permitem que você mude o SID de uma máquina sem removê-la do domínio, mas isso não é confiável nem seguro. Se for imprescindível que você execute o Sysprep em uma máquina membro de um domínio, remova-o do domínio antes da execução ou execute-o e deixe que ele cuide dessa tarefa para você.

Em uma situação parecida, se você estiver virtualizando qualquer um dos seus controladores de domínio (DCs), precisará duplicar sistemas que sejam simplesmente servidores autônomos que ainda não foram promovidos a controlador de domínio e que ainda não se associaram ao domínio. Com a exceção do Windows Server 2003 Small Business Server Edition, não é possível duplicar um controlador de domínio em disco com segurança. Para criar novos controladores de domínio com segurança, crie uma imagem em disco de um servidor que esteja pronto para se associar ao domínio e para ser promovido a controlador de domínio. O Sysprep (exceto na instância SBS, bastante especializada, que é uma floresta única/servidor único) não sabe como alterar SIDs em um controlador de domínio com segurança.

Por fim, além da alteração do SID e da remoção da máquina do domínio, o Sysprep também altera o nome da máquina.

Pode parecer tirânico dizer que você precisa executar todas as etapas anteriores durante a criação de imagens (ou até mesmo durante a cópia) de sistemas virtuais. Mas é fundamental — especialmente se você estiver usando esses sistemas em uma rede com outros sistemas físicos ou virtuais, em um domínio ou em qualquer outra cópia deles na rede.

Se você não utilizar o Sysprep na duplicação de sistemas virtuais, certamente encontrará alguns dos problemas óbvios (colisões no Active Directory ou de rede) e outros tantos que talvez sejam inesperados. Por exemplo, as suas imagens virtuais são muito suscetíveis a ataques de hackers, já que o acesso a elas garante o acesso às outras.

Os drivers e as camadas de abstração de hardware

Eu mencionei que os dispositivos virtuais incluídos em uma imagem virtual podem não ter drivers "nativos" para o Windows. Verifique se você possui drivers úteis para os seus dispositivos quando estiver implantando (ou quando estiver implantando imagens de disco usando o Sysprep), já que o temido erro 0x0000007B de driver pode aparecer facilmente durante a mudança de uma imagem virtual de um driver de barramento de armazenamento para outro da mesma forma como quando trabalhamos com hardware físico. O mesmo se aplica às NICs. Embora a maioria dos produtos de virtualização tenham conseguido oferecer um dispositivo virtual quase universal, talvez você ainda precise de um driver adicional para ele.

Também não é possível ignorar aquela incômoda HAL (camada de abstração de hardware). Teoricamente, você deseja criar as suas máquinas virtuais para que suportem multiprocessadores ACPI (interface de energia e configuração avançada) (consulte intel.com/technology/iapc/acpi), se é para isso que a sua tecnologia de virtualização oferece suporte. A conversão entre HALs geralmente não é suportada (consulte support.microsoft.com/kb/309283 para obter mais informações específicas). No entanto, algumas tecnologias de virtualização — ou, mais importante, muitas tecnologias de migração — prometem que podem mover com segurança uma instalação do Windows não ACPI para uma instalação ACPI ou vice-versa. Isso não é verdade e a instalação do Windows resultante não será suportada pela Microsoft quando e se você encontrar problemas. As mesmas limitações discutidas na página da Web de suporte que acabei de mencionar são verdadeiras para os sistemas virtualizados. Consulte a Figura 3 para obter um exemplo da HAL no Gerenciador de Dispositivos em uma de minhas máquinas virtuais — nesse caso, executada com a HAL do uniprocessador ACPI. Para não ser confundido com um único processador, ele é intercambiável com sua família de multiprocessadores.

Figure 3** HAL in Device Manager on a virtual machine **(Clique na imagem para aumentar a exibição)

Alterações diversas

Mude o que você pode e aceite o que não puder mudar

Quando estiver considerando a migração do físico para o virtual e vice-versa, você precisa se lembrar daquilo que pode ou não mudar. Você pode alterar os seguintes aspectos de uma instalação do Windows:

• A HAL (mas somente do uniprocessador para o multiprocessador ou vice-versa, desde que eles se baseiem na mesma configuração de energia).
• Os controladores de armazenamento em massa (isso não é fácil —mas a maioria das soluções de migração física para virtual já tenta fazer isso por conta própria). Observe que a maioria dos fornecedores oferece uma solução de armazenamento IDE e uma SCSI. Escolha com sabedoria durante a implantação, já que mudar de uma para outra não é muito fácil. Geralmente, escolher a SCSI resulta em um dispositivo mais confiável (esse é o caso das implementações de emulação de dispositivos SCSI da maioria dos fornecedores).
• O controlador de rede (embora isso geralmente seja igual para as tecnologias de um fornecedor em um cenário de migração virtual para virtual).

Você não pode alterar os seguintes aspectos de uma instalação do Windows:

• A HAL (exceto no caso mencionado anteriormente, quando for usada a mesma configuração de energia). Você não deve supor que uma solução de migração que faz isso resultará em uma instalação do Windows estável ou confiável (e, mais importante, ela não será suportada pela Microsoft).

Além da alteração do SID e do nome da máquina, você também precisa alterar certos valores que podem ser específicos da tecnologia de computação virtual utilizada. Em particular, você precisa alterar o endereço MAC (a identificação exclusiva para dispositivos de rede). E mais, muitos aplicativos virtuais também possuem seu próprio identificador exclusivo. A maioria os armazena em seus próprios arquivos de configuração das máquinas e, portanto, você vai querer saber como manipular essas entradas (e manter a sua validade). Observe que muitos produtos de virtualização que oferecem suporte a PXE (Pre-Boot Execution Environment) têm o UUID do SMBIOS baseado em sua própria identificação exclusiva — enfatizando a necessidade de alterá-lo (ou deixar que o software de virtualização se encarregue disso, se houver suporte) caso você esteja se associando a um domínio; caso contrário, o gerenciamento de sistemas WDS ou de clientes RIS pode se tornar impossível (se houver conflitos de GUID). A maioria das soluções de virtualização com que trabalhei pode ter graves problemas de rede se existirem endereços MAC duplicados; dessa forma, se você não está simplesmente movendo uma máquina virtual, é muito importante que altere o endereço MAC caso o software de virtualização não faça isso em seu lugar.

Outros componentes que devem ser considerados na preparação de um sistema virtual para implantação são quaisquer discos ou instantâneos vinculados. Dependendo da sua solução de virtualização, eles também podem ser chamados de discos diferenciais ou por outro nome. Mas se você executar o Sysprep para preparar um sistema e se tiver instantâneos (ou outro estado reversível) que funcione com o sistema virtual, eles deverão ser destruídos para que a imagem permaneça segura, confiável e protegida quando for duplicada. No caso de um instantâneo ou de outra abordagem da tecnologia "desfazer alterações de disco", a reversão de um instantâneo poderia significar voltar ao ponto onde mais de um sistema que foi gerado a partir da máquina virtual original agora está em conflito com outra (ou até mesmo com o sistema original, caso ele seja ligado novamente). Assim, execute o Sysprep em quaisquer instantâneos ou relacionamentos de discos diferenciais.

Otimização

A maioria das tecnologias de virtualização inclui adições de máquinas virtuais ou ferramentas que ajudarão a aperfeiçoar o desempenho e a experiência de interação entre o convidado e o host. Isso normalmente inclui a otimização da entrada de mouse e de teclado, entre outros aprimoramentos de desempenho, e quase sempre inclui a interação avançada de copiar e colar (ou outra interação do host para o convidado). Instale a versão mais recente dessas ferramentas em seus sistemas virtuais antes da implantação.

Você também precisa garantir que a memória do cliente seja configurada de forma ideal para o sistema operacional convidado, mas também no contexto com os hosts em que será implantada. Afinal, a última coisa que você deseja é implantar uma imagem do Windows XP definida para usar 1 GB de RAM em sistemas host que não possuem tanta memória assim.

Lembre-se também das limitações da maioria das tecnologias virtuais de hoje — é importante para os seus usuários a forma de interação com os periféricos conectados ao sistema virtual assim como quais aplicativos funcionarão ou não no sistema operacional convidado (a maioria não oferece suporte ao DirectX 9 ou 10, por exemplo, ou oferece suporte a versões mais antigas de forma limitada). Os usuários podem não saber o que isso significa ou como se manifesta (alguns aplicativos não lidam muito bem com falhas).

Preocupações com o host

Observe que, em geral, não há muito com que se preocupar em relação ao PC host que está executando a tecnologia de virtualização, a despeito do que está sendo executado seja um sistema operacional completo ou um Hypervisor de tipo 1 executado diretamente sobre o hardware. A maioria das tecnologias de virtualização foi projetada para garantir que o sistema operacional convidado não precisasse saber nada (ou muito pouco) sobre o host. No entanto, é preciso saber que hosts estão sendo usados, caso um convidado movido de um host para outro tenha problemas. Verifique também se você conhece as limitações do produto do seu fornecedor de virtualização em certas plataformas. Embora você possa ser capaz de mudar de um para outro, talvez perca ou ganhe certos recursos do Hypervisor de tipo 2 do sistema operacional do host (o aplicativo de virtualização) no processo.

Outros mecanismos de implantação

Links sobre o Sysprep relacionados

Os documentos a seguir oferecem muita ajuda sobre o Sysprep:

• Projetando instalações baseadas em imagem com o Sysprep
• Como usar a ferramenta Sysprep para automatizar uma implantação do Windows XP
• Como usar a Ferramenta de Preparação do Sistema (Sysprep.exe) para executar a duplicação de discos
• Usando a Ferramenta de Preparação do Sistema em computadores diferentes

A utilização do Sysprep ou a duplicação de disco (ou simplesmente a execução do Sysprep e a cópia da máquina virtual) são opções óbvias para a implantação de sistemas virtuais, mas existem outras. Na verdade, se forem usadas imagens ou a configuração, a utilização do Windows PE pode ser mais fácil com a virtualização do que com máquinas físicas, já que você estará trabalhando com arquivos ISO em vez de um CD físico. Observe que algumas tecnologias de virtualização não lidam bem com mídia de DVD e, portanto, não se esqueça de verificar se há suporte do fornecedor de virtualização. Você pode usar o winnt32 ou o setup.exe (no caso do Windows Vista ou do Windows Server 2008), mas não há quaisquer vantagens específicas. Se você usar outras tecnologias de implantação da Microsoft, como o Automated Deployment Services, a sua tecnologia de virtualização oferecerá suporte ao PXE para iniciar uma implantação baseada em rede como se RIS ou WDS estivessem sendo utilizados.

Migração

Por fim, além da migração real de um PC completo, não se esqueça da USMT (Ferramenta de Migração de Perfil do Usuário). A USMT permite que você mova as configurações de um usuário de um cliente físico para um novo sistema virtual com facilidade. Dessa forma, se os seus usuários quiserem migrar seus dados e configurações antigos para uma nova máquina virtual, você pode, por exemplo, obter com facilidade os arquivos e as configurações do Windows XP, armazená-los em um UNC e enviá-los para uma nova máquina virtual.

Wes Miller mora em Austin, no Texas. Já trabalhou na Winternals Software, em Austin, e na Microsoft, como gerente de programas e gerente de produtos do Windows. Entre em contato com ele pelo email technet@getwired.com.

© 2008 Microsoft Corporation e CMP Media, LLC. Todos os direitos reservados. A reprodução parcial ou completa sem autorização é proibida..