Uma preocupação comum entre os administradores de sistema são aos processos de teste e qualificação necessários na implementação de uma nova versão do sistema operacional. É bem possível que as vantagens do novo software não sejam tão significativas para grande parte das aplicações, mas podem ser necessárias para atender uma determinada aplicação ou hardware.

A virtualização oferece uma solução para esse problema. A estrutura existente pode continuar operacional como guest em uma máquina virtual, enquanto o hypervisor mais recente tranqüilamente suporta o novo hardware, com conseqüentes benefícios de confiabilidade e desempenho. As poucas aplicações que precisam da nova versão do sistema operacional podem ser executadas em uma outra máquina virtual com essa versão mais recente.

Isso significa que as atualizações só serão feitas onde o administrador julgar necessário. Ele nunca mais será forçado a passar por um processo imprevisto e dispendioso de atualização de software.

Embora um sistema utilizado apenas por uma aplicação possa ter seu acesso limitado, muitos sistemas atualmente permitem acesso compartilhado, sendo fundamental garantir a privacidade. A virtualização permite que cada aplicação e conjunto de dados sejam colocados em uma máquina virtual distinta. Isso traz muitas vantagens, além de reduzir o número de hardware. Como a virtualização isola cada guest, cada um deles fica muito menos susceptível a compartilhamento não desejado. Qualquer ataque bem sucedido restringe-se apenas ao guest invadido. Junto com SELinux e Red Hat Identity Management, é possível conseguir um alto nível de isolamento dos dados e do usuário, sem necessidade de um servidor distinto para cada usuário.

O desenvolvimento de software é um processo longo, com muitas interações envolvendo codificação, depuração e testes. Antigamente os processos de depuração e testes freqüentemente exigiam muitos sistemas distintos. Era difícil criar redes maiores e os conjuntos de dados necessários para os testes. A virtualização oferece várias soluções para esses problemas.

Os desenvolvedores podem contar com máquinas virtuais individuais capazes de serem inicializadas e encerradas sem nenhuma interferência nas outras. Eles não precisam mais de máquinas físicas individuais, o que simplifica a depuração de código, especialmente de código kernel.

Como as máquinas virtuais podem ser rápida e facilmente inicializadas, encerradas e modificadas, é possível automatizar uma série de testes de regressão. Os scripts podem aprovisionar diferentes versões das aplicações e sistemas operacionais, executar conjuntos de dados conhecidos e apresentar os resultados em gráficos e relatórios. No caso de paralisação do sistema, o script consegue detectar a situação porque apenas o guest irá parar e não o DOM 0 base.

Se houver necessidade de utilizar diversos sistemas, podem ser configurados vários guests na rede simulando uma grande rede física com um pequeno número de servidores físicos. Isso aumenta a escalabilidade para os testes, uma raridade hoje em dia. Na verdade, fora o horário comercial, é possível usar as máquinas não utilizadas da produção para os testes, tudo isso com total segurança, graças às medidas de segurança e firewall em cada guest.

A Migração sem Interrupção das Operações (Live Migration) possibilita a migração para guests “paravirtualizados” no Red Hat Enterprise Linux Version 5 de um servidor físico para outro da rede. Quando é solicitado que um guest seja transferido (solicitação essa feita por um programa ou pelo administrador do sistema via ferramentas de gerenciamento padrão do Red Hat Enterprise Linux), o hypervisor do sistema de “origem” age em conjunto com o hypervisor do sistema de “destino” na alocação de memória para suportar a migração do guest. A memória é então copiada na rede até que reste apenas memória necessária para as operações. Como o guest da máquina de “destino” ainda está sendo executado e servindo os guests, definimos essa memória como memória que está sendo utilizada. Em seguida, o hypervisor do sistema de “origem” dá uma pausa no guest e copia o restante dessa memória. Depois disso, hypervisor da máquina de "destino" ativa o guest. Como todas as conexões de rede e de E/S são preservadas na memória copiada, elas se mantêm, e por isso, apenas com uma breve pausa (inferior a 200 ms), a tarefa prossegue servindo os clientes. Observe que é necessário que os sistemas façam parte da mesma sub-rede para que o soquete da rede fique ativo e também que haja armazenamento comum, para que não haja impacto sobre os arquivos abertos. Não é necessário um lock manager, apenas iSCSI, GNDB ou SAN.

Esse tipo de migração pode ocorrer por várias razões.

1. Um guest é utilizado tanto que, ou ele é migrado para umanova máquina, ou outros guests daquela máquina precisam ser migrados para liberar recursos para esse guest sobrecarregado.
2. O sistema começa a emitir alertas sobre pequenos erros de memória, sobre temperatura ou outros indicativos de falha iminente. É necessário migrar os guests antes que eles sejam encerrados, para que o servidor possa ser liberando para manutenção.
3. Para a preparação para um fluxo pesado de lote, comum em alguns ERP e transações financeiras. É necessário que os guests sejam migrados do servidor para liberar capacidade. Eles podem ser consolidados em menos máquinas, de forma que a capacidade em excesso possa ser eliminada, economizando potência.