Utilizando o Hyper-V Replica Parte II - Boas Práticas para RTO e RPO

18 janeiro 2014 msincic Hyper-V, MSARC, System Center, Virtual Machine Manager, Virtualizaçao, Windows, Windows 2012
No primeiro post sobre Hyper-V Replica abordamos as vantagens sobre réplica de storage e como iniciar a configuração e réplica http://www.marcelosincic.com.br/blog/post/Utilizando-o-Hyper-V-Replica-Parte-1e28093Vantagens-e-Primeira-Replica.aspx Neste segundo post vamos abordar como o RTO e RPO são importantes e como o Hyper-V Replica se encaixa nestes conceitos. Recovery Time Objective e Recovery Point Objective Basicamente os termos RTO e RPO indicam os objetivos que uma solução de desastre deve cumprir: RTO – Tempo máximo para se recolocar o serviço em produção RPO – Tempo máximo de dados que podem ser “perdidos” entre o evento de desastre e o ambiente restaurado Um bom exemplo de como estes valores se relacionam e o que significam pode ser explicado no gráfico abaixo: No exemplo acima conseguimos “enxergar” claramente o RTO e o RPO: RTO foi de 5 horas e 3 minutos, entre as 05:15 e as 10:18 RPO foi de 3 horas e 15 minutos, entre as 02:00 e as 05:15, uma vez que o backup foi realizado as 2 da manhã Como determinar o RTO e RPO Estes valores são determinados por um plano que é chamado de DRP (Disaster Recovery Plan) que é orquestrado por consultorias especializadas neste tipo de processo. Geralmente é realizado quando uma organização está atualizando seu datacenter e, consequentemente revendo suas políticas de recuperação dos dados ou montagem do datacenter redundante. O processo de levantamento destes dados se baseia em entrevistas e dados do ambiente de TI e, entre outras coisas, coleta: Porque o Hyper-V Replica é uma ótima opção O processo de backup é uma das formas que o RPO e RTO podem ser cumpridos, porem as práticas normais de restore muitas vezes são impeditivas levando em conta o tempo que é perdido entre o ultimo backup e a falha (RPO) e o tempo necessário para se restaurar um servidor a partir de backups (RTO). Com o Hyper-V Replica o tempo de RTO é minimo, uma vez que as réplicas mantem a maquina virtual (VM) no ambiente de redundância integra. E o RPO? Em um ambiente de backup o RPO é facilmente calculado e mantido. Por exemplo, se o RPO da aplicação CRM tem perda máxima calculada em 30 minutos, podemos fazer o backup incremental a cada 15 ou 30 minutos. No caso do Hyper-V Replica este tempo não é determinado de forma simples, uma vez que o tempo de replicação (Replication Frequency) de cada VM indica o intervalo e não o periodo desejado de proteção. Seria muito bom ter uma opção onde pudesse ser indicado qual o tempo máximo em que uma réplica pode estar desatualizada… Um segundo item importante é levar em conta o grupo de uma aplicação, por exemplo mais de um servidor que forma a mesma aplicação e precisa estar com a réplica sincronizada por igual. Como o Hyper-V Replica não tem o conceito de grupo de serviço, não temos como garantir a integridade do conjunto da aplicação. Outra dificuldade no Hyper-V Replica é o baixo número de opções de intervalo da réplica (Windows 2012 a cada 5 minutos, Windows 2012 R2 a cada 30 segundos, 5 minutos ou 15 minutos): Imagine um cluster com 80 VMs, sendo que cada VM tem impacto diferente no negócio ou requisitos técnicos particulares. Destas 80 VMs algumas são servidores web que podem ser replicadas uma vez por dia, outras são servidores de aplicação que só precisam ser replicados quando sofrem algum tipo de atualização e, por fim temos os servidores que precisam ser replicados continuamente. Como configurar diferentes RPO? Uma prática que pode ser adotada de forma simples, é colocar as máquinas em grupos de criticidade e configurar utilizando as 3 janelas de réplica do Windows 2012 R2 (30 segundos, 5 minutos e 15 minutos). O problema é que se a VM que será replicada a cada 30 segundos for, por exemplo um banco de dados e o ambiente de redundância for por WAN, o consumo do link será muito alto e as outras VMs entrarão em intervalo de réplica e com isso todas as réplicas ocorrerão simultaneamente. Com isso, o RPO ficará prejudicado para todas as VMs críticas e muito baixo para as maquinas não criticas. Uma boa prática neste caso é configurar as VMs com RPO maior que 2 horas para serem replicadas manualmente por meio de PowerShell abaixo: Resume-VMReplication MaquinaVirtual –Resynchronize –ResynchronizeStartTime “8/1/2012 05:00 AM” Este comando pode ser executado pelo Task Scheduler ou utilizando o Orchestrator com schedule embutindo o comando. No exemplo citado anteriormente, as VMs de banco de dados ou informações como File Server ficariam com a configuração do próprio Hyper-V a cada 5 ou 15 minutos. As VMs estáticas poderiam ser configuradas com replicação manual, e com tarefas ou runbook agendados e recorrentes replicar pontualmente conforme o grupo de criticidade. Conclusão Este segundo post abordamos como alcançar o RTO e RPO. O próximo post irei abordar os comandos e a sequencia de comandos PowerShell que podem ser executados como script ou com Runbook no Orchestrator.

Utilizando o Hyper-V Replica Parte I–Vantagens e Primeira Réplica

18 janeiro 2014 msincic Hardware, Hyper-V, MSARC, Outros, Windows 2012
O segundo artigo sobre Hyper-V Replica abordando RPO e RTO esta disponivel em http://www.marcelosincic.com.br/blog/post/Utilizando-o-Hyper-V-Replica-Boas-Praticas-para-RTO-e-RPO.aspx Apesar de muito noticiado como novidade no Windows Server 2012, o Hyper-V Replica não está sendo tão utilizado pelos profissionais de TI como esperado. Muito provavelmente temos o desconhecimento e a restrição a ser uma nova tecnologia, o que é natural. Porem, uma das formas hoje usadas para réplica de VMs e que no Hyper-V criam diversos problemas é a réplica de storage, ou seja, a replicação que ocorre entre os storages em casos de datacenter de redundância (DR). A tabela abaixo mostra alguns motivos pelo qual Hyper-V Replica é melhor opção a réplica de storage: Storage Hyper-V Replica Performance da Réplica Performance da cópia usa algoritmos dedicados de compressão Boa performance, só replica alterações no VHDX, Windows 2012 R2 oferece compressão Consistência Assegura consistência na réplica Replica baseada em NTFS, permitindo ativo/passivo e Live Migration RPO Permite a réplica em agendamentos regulares ou contínuos Permite agendar a primeira réplica, as atualizações são a cada 5 minutos no Windows 2012 RTM e 30 segundos, 5 minutos ou 15 minutos no Windows 2012 R2 RTO Necessita que os discos sejam ativados e os hosts Hyper-V inicializados Imediatamente os hosts ativam as VMs no DR Replica de Novas VMs É necessário criar manualmente no site DR Replica qualquer alteração no XML da VM Admin Tools Storage console Console do Cluster/Hyper-V Nivel de Especialização Conceitos de Storage geral e do fabricante Hyper-V e Microsoft Cluster Cancelamento da Réplica Permite cancelar réplica de uma LUN Permite cancelar a réplica apenas de uma VM ou até mesmo um VHDX Inversão Necessário reconfigurar a réplica Permite a inversão em modo gráfico Cluster Mode Ativo/Passivo Ativo/Ativo Ação de Recover Recriar/Reiniciar os algoritmos de réplica Menu de contexto para reiniciar ou inverter O maior problema da réplica de storage para Hyper-V é que a LUN replicada no site DR está offline. Sendo assim, não dá para alterar ou mesmo ver no Hyper-V as VMs no site DR, uma vez que a LUN não está acessivel e só pode ficar no momento de uma virada de operação. Já o Hyper-V Replica permite inverter as VMs sem qualquer passo adicional, incluindo a reversão (inverter primário com secundário). Porem, iremos falar disso em outro post. Vamos focar no momento da primeira réplica. Existem duas formas de a primeira réplica ser realizada sem utilizar o link entre os sites do exemplo abaixo: A primeira forma é fazer local a configuração do Hyper-V Replica e esperar o secundário ter todas as VMs prontas. Este método tem a desvantagem da montagem do storage e servidores em dois momentos, o que pode encarecer o serviço e em muitos casos não haver espaço ou recursos de energia elétrica suficientes. A outra forma é fazer isso por usar o próprio wizard do Hyper-V Replica escolhendo exportar a VM. Para isso, ao configurar a réplica de uma VM escolha a opção "Send initial copy using external media” e defina um local para exportar os arquivos como abaixo: O passo seguinte é importar a VM no host onde ela foi criada. Note que a VM é criada no final do wizard acima no host destino, mas sem os arquivos e sem ativar a réplica: Escolha a localização criada pelo wizard e aguarde a importação: Completado este item no servidor destino o status estará Warning e no servidor de origem Normal indicando que está ok. O próximo passo é clicar no servidor de origem na VM e usar a opção Resume Replica para que ele inicie a cópia de sincronização. Uma dica importante é que o Hyper-V Replica funciona criando um snapshot e enviando o arquivo de snapshot da origem para o destino, portanto não demore muito tempo para fazer a sincronização inicial pois poderá ter problemas de espaço e performance por conta do uso de um disco diferencial do snapshot. Nos próximos posts iremos abordar melhores configurações e como montar um ambiente de Hyper-V Replica.

Conceitos de Storage para IT Pro 3 – Virtualização e Tierização

21 junho 2013 msincic Virtual Machine Manager, Virtualizaçao, Hardware
No primeiro artigo desta série Conceitos de Storage para IT Pros–Tipos de RAID e IOPS abordamos alguns conceitos importantes e básicos para profissionais de TI sobre os tipos de RAID disponiveis e utilizados hoje em storages e também como calcular IOPS (operaçoes de leitura e escrita) para cada tipo de disco e aplicações. No segundo artigo http://www.marcelosincic.com.br/blog/post/Conceitos-de-Storage-para-IT-Pro-2-e28093-Controladoras-e-Modelos.aspx abordamos os tipos de controladoras e tecnologias de storage mais comuns hoje existentes no mercado. Neste terceiro artigo veremos o que são conceitos de tierização e virtualização de storages. Virtualização A virtualização de storage conceitualmente é diferente da virtualização de computadores. Na virtualização de storages o conceito é utilizarmos um produto que faça a conexão com vários tipos e modelos de storage. Por exemplo, o System Center Virtual Machine Manager 2012 é capaz de ser a interface entre os diferentes storages e as máquinas virtuais. Mais detalhes sobre isso podem ser vistos no post http://www.marcelosincic.com.br/blog/post/Gerenciamento-de-Storage-com-o-System-Center-Virtual-Machine-2012.aspx O mesmo recurso pode ser alcançado com o SMB 3.0 do Windows Server 2012, onde podemos apontar todas as LUNs disponíveis em um File Server e por meio do SMB 3.0 mapear as VMs entre os diferentes storages. Tierização Este recurso está presente em alguns storages de mercado e pode ser simulado pelo VMM. Significa ter a possibilidade de termos diversos storages com performances diferentes e ter a capacidade de mover uma VM de um storage mais lento para outro mais rápido de forma transparente a operação. Isso pode ser simulado pelo VMM e pelo Hyper-V 3.0 com o recurso Storage Migration, onde podemos mover as VMs com Live Storage Migration permitindo que a operação não seja interrompida quando movemos entre os diferentes modelos de storage disponíveis. Porem, alguns modelos storage como, por exemplo Compellent e Equallogic, podem conter “gavetas” de discos de diferentes tipos e mover os dados entre as gavetas conforme a performance necessária da aplicação ou maquina virtual. Neste caso o software do storage faz isso automaticamente conforme a carga que cada VM ou aplicação impõe ao storage. Fonte: http://www.dellstorage.com/storage-tiering-archiving/storage-tiering.aspx Para mais informações sobre o Windows Server 2012, acesse: http://clk.atdmt.com/MBL/go/425205719/direct/01/

Conceitos de Storage para IT Pro 2 – Controladoras e Modelos

16 junho 2013 msincic Hardware, Windows 2012, Virtualizaçao
No primeiro artigo desta série Conceitos de Storage para IT Pros–Tipos de RAID e IOPS abordamos alguns conceitos importantes e básicos para profissionais de TI sobre os tipos de RAID disponiveis e utilizados hoje em storages e também como calcular IOPS (operaçoes de leitura e escrita) para cada tipo de disco e aplicações. Neste artigo iremos abordar os tipos mais comuns de controladoras e modelos de storages. A tabela a seguir retirada do documento da Microsoft “Analyzing Characterizing and IO Size Considerations” disponivel em http://bit.ly/18nlbTg mostra como o tipo de barramento da controladora fisica utilizada para o seu storage influencia diretamente na performance: HBA – Host Bus Adapter Este é um tipo de barramento muito utilizado antes do iSCSI e muito eficiente, interligando o storage diretamente com o servidor por uma placa dedicada, sendo utilizado pelo Fibre Channel (exemplo Compellent) ou modelo de conexão direta (exemplo MD3000). Como pode ser visto na tabela acima, por ser um barramento dedicado temos toda a performance sem concorrencia, diferente do iSCSI, pois no HBA cada servidor se conecta a uma saida do storage ou a um switch dedicado e no iSCSI usamos duas saidas de rede para todos os servidores. Alem disso, em um storage dedicado são pelo menos duas controladoras, sendo elas redundantes e simultaneas para acesso, garantindo segurança e alta performance. A desvantagem dos modelos HBA se dá por conta da limitação de conexões possiveis, uma vez que em alguns modelos (exemplo MD3000) são 4 portas, limitando a 4 servidores. Para este modelo utilizar HBA e montar um cluster de 4 nós é uma boa alternativa. Fibre Channel O FC é um dos modelos de HBA muito utilizado por conta da alta performance e numero ilimitado de hosts que podem ser conectados pelo switch Fibre Channel. Alem disso, o FC permite boot de servidores sem disco local, o que garante a substituição de um host apenas colocando outro hardware identico e alterando o WWN no storage. Nos storages FCs utilizamos o WWN (World Wide Name) para indicar qual LUNs será utilizado por cada servidor, sendo muito simples de ser realizado e configurado. Com o Windows 2012 podemos entregar storages diretamente as VMs por criar um WWN virtual no Hyper-V: A desvantagem do FC se dá pelo custo mais alto que as outras soluções envolvendo HBA e, principalmente, iSCSI. Porem, as vantagens técnicas, administrativas e performance fazem do FC o melhor tipo de conexão a storage. iSCSI O iSCSI (Internet SCSI) é o modelo mais utilizado hoje por conta do custo acessivel, diversas opções de fabricantes, modelos e tamanhos. Basicamente o iSCSI utiliza comunicação pela rede ethernet comum, porem com algumas vantagens que melhoram a performance se seguidos: Utilizar switches de rede separados apenas para a rede de storage Trabalhar com 2 placas de rede em cada servidor para configurar o recurso de MPIO (Multipath I/O) que permite utilizar as duas placas simultanêas no acesso aos dados, duplicando a velocidade de acesso Configurar o Jumbo Frame para trabalhar com pacotes de dados de 9K ao invés de 1.5K, uma vez que storage sempre trafega dados em pacotes maiores diferentemente da comunicação comum em rede A desvantagem do iSCSI se dá exatamente pelos pontos acima, já que a estrutura de rede precisa ser dedicada para ter melhor performance e redundância. O suporte ao iSCSI pode ser pelo storage ou até por softwares que habilitam um servidor comum a se tornar um storage iSCSI, o que é chamado de iSCSI Initiator Server e o cliente de iSCSI Initiator. A Microsoft tem este software disponivel, mas é muito conhecido no mercado o StarWind iSCSI Initiator Server. NAS com SMB 3.0 A tecnologia de NAS (Network Attached Server) é baseada no Windows Server 2012 que com o SMB 3.0 torna ele compativel com virtualização, permitindo que o Hyper-V utilize um File Server para armazenar as maquinas virtuais, possibilitando que seja montado um Cluster baseado apenas em File Server. As vantagens deste modelo são o baixo custo, facilidade na administração e entrega para novos servidores. As desvantagens se dão por conta da rede que tem os mesmos requisitos listados do iSCSI, tendo algumas considerações adicionais: O MPIO precisa ter placas de rede redundantes no servidor baseadas em SMB Direct e RDMA que não são modelos triviais em servidores atualmente O Jumbo Frame impossibilita que maquinas de usuários (clientes) utilizem o servidor para guarda de arquivos, a menos que se habilite neles o modo Jumbo Frame com implicações em todos os switches da rede Core Storages possuem recursos de multicontroladoras e fontes, o que nem sempre é presente em File Servers Conclusão Utilizando corretamente os tipos de storages disponiveis e pensando em sua necessidade é possivel ter um ambiente confiável e com boa performance e redundância. Fonte: http://bit.ly/13uRbOs (Windows Server 2012 White Paper Storage) Para mais informações sobre o Windows Server 2012, acesse: http://clk.atdmt.com/MBL/go/425205719/direct/01/

Windows Server 2012: Novidades do Failover Cluster Services (MSCS)

17 janeiro 2013 msincic Windows 2012
Novidades do Microsoft Cluster Services (MSCS) Muitas funcionalidades são de gerenciamento e configuração, mas algumas se destacam: Live Migration com multiplicas placas de rede – Hoje designamos uma placa para dar suporte ao Live Migration e somos limitados a uma VM por vez. O Windows 2012 utilizará todas as placas que estejam disponiveis para o processo, o que permitirá maior desempenho e multiplas operações. O processo será alterado de uma placa dedicada como é hoje para utilizar a banda livre em toda as placas. Priorização e Afinidade de VMs – Estes eram dois tópicos delicados quando vendíamos soluções MSCS, pois não temos como indicar a sequencia com que as VMs deverão iniciar e, muito menos, a dependência entre elas. Isso causava problemas com aplicações como SharePoint, System Center ou IIS que dependiam do SQL Server estar iniciado para funcionarem. Como não podíamos indicar esta ordem os servidores IIS subiam antes do SQL, causando queda ou instabilidade nos serviços. Novos limites de 64 nós e até 8000 VMs – Hoje o limite é 16 nós de cluster com até 1000 VMs ou 384 por host. Com o novo limite de 64 nós, aumentou correspondentemente para 8000 VMs. Um aumento de 4 e 8 vezes respectivamente no número de host e VMs suportadas. Transferência de File Server transparente – Este é um dos itens muito importantes que para muitos passava despercebido em projetos e que na administração do dia-a-dia se davam conta. Quando se move um share de um File Server virtual de um nó para outro o SMB (protocolo de comunicação) derrubava a sessão e o usuário recebia uma mensagem de erro de I/O. No SMB 3.0 no Windows 2012 será possivel fazer a migração sem a perda da sessão, resolvendo este problema. Adicionalmente isso também acontecerá se o File Server foi movido para um site remoto, porém neste caso entra o Hyper-V Replica que já é outro recurso novo no Hyper-V e não do MSCS. Configurando o Failover Clustering no Windows 2012 Como qualquer nova funcionalidade desejada no Windows 2012, iniciamos por instalar e habilitar as features desejadas pelo Server Manager. Para isso utilizamos o menu Manage à Add Roles and Features e selecionamos a Failover Clustering, que automaticamente irá incluir as ferramentas de gerenciamento e outros itens que sejam necessários para o funcionamento, sendo possível escolher ou não a instalação, por exemplo, se for remoto não precisaremos do console local: O passo seguinte é definir o nome e o IP que o cluster utilizará, uma vez que o acesso dos clientes não será pelo nome e IP dos servidores e sim pelo nome e IP configurado posteriormente. Neste exemplo foi escolhido o nome MSCS-Lab e o IP 192.168.0.230 que manualmente foram acrescentados ao DNS: Já na console do Cluster utilizamos a opção Create Cluster... para iniciar o assistente do cluster. Note que no menu lateral acima da opção de criação temos a opção Validate Configuration que funciona como um BPA (Best Practices Analyzer) e é recomendado que se execute primeiro. Voltando ao assistente, o primeiro passo é selecionar quais servidores estarão no grupo: O passo seguinte é indicar o nome e o IP criados para esta finalidade: Ao finalizar temos uma importante opção antes de simplesmente clicar no Next que é indicar se discos de storage serão automaticamente acrescentados no cluster. Isso é interessante para evitar que após a configuração do cluster seja necessário incluir os discos, mas deve ser usado com cuidado caso existam LUNs no storage dedicada a discos de acesso direto (Pass-Throught): Na sequencia são definidos os serviços que estarão contemplados pela alta disponibilidade, como maquinas virtuais, DHCP, DNS, etc. Cada serviço tem um assistente próprio e configurações próprias, portanto não teríamos como abordar cada um neste momento. Alguns dos recursos disponíveis pode ser visto a imagem logo abaixo (tópico Hyper-V Replica Broker). Hyper-V Replica Broker Um dos novos recursos do Hyper-V 3.0 é a réplica de VMs que permite criarmos ambientes de alta disponibilidade com Datacenters remotos. Porem, este mesmo recurso pode ser configurado pelo Failover Cluster, habilitando o recurso de alta disponibilidade em Datacenter remoto automaticamente, diferente do Hyper-V que apenas faz a réplica exigindo a inicialização da VM remota em caso da parada do Datacenter principal. Este recurso é criado por meio do assistente de papeis (New Role...) como a imagem abaixo: Após acrescentar o serviço, será habilitado um novo nome e IP virtual específico para este cluster trabalhar as réplicas: Após adicionar este serviço, acesse as máquinas virtuais e com o botão direito será possível ver a opção Replication à Enable Replication e seguir o assistente mostrado no artigo de Hyper-V, indicando o nome do servidor habilitado para réplica, seja ele um cluster ou standalone. Para maiores detalhes sobre Hyper-V Replica Broker consulte o link abaixo onde poderá entender porque é necessário para os casos de cluster criar um novo nome e IP virtual: http://blogs.technet.com/b/virtualization/archive/2012/03/27/why-is-the-quot-hyper-v-replica-broker-quot-required.aspx Trabalhando com VMs no Failover Cluster Para que uma maquina virtual esteja sendo protegida e controlada pelo Cluster ela precisa ser criada nele e não pelo Hyper-V Manager (é possível mover pelo System Center Virtual Machine Manager ou VMM) e para isso utilize o menu lateral Create Role como no caso mostrado no tópico anterior para acrescentar o Replica Broker ou a opção Virtual Machines à New Virtual Machine. Na sequencia irá ter acesso a criação de uma VM normalmente como acontece com o Hyper-V, e após a criação está irá aparecer na lista de Roles do Cluster. Alguns recursos interessantes já existentes no Windows 2008 R2 continuam a funcionar, como Live Migration e Quick Migration, onde o Live migra as maquinas em funcionamento e o Quick ao fazer um Save State. Algumas mudanças ocorrem nesta nova versão, pois é possível agora fazer a migração entre máquinas que não estejam em um cluster, mas não é o tópico em questão. Storage File Share Um recurso interessante é poder agora armazenar maquinas virtuais em um cluster utilizando um File Share, ou seja, utilizar um terceiro servidor como Storage ao invés de um storage físico. Para utilizar este recurso acesse uma das VMs e utilize a opção Virtual Machine Storage: Na sequencia define o File Share onde deseja que a VM fique hospedada: Este recurso é excelente por permitir que utilizemos clusters de alta disponibilidade sem ter um storage físico dedicado. Prioridades Outro interessante recurso do Failover Cluster do Windows 2012 é indicar a prioridade de cada VM, assim garantindo que um servidor de banco de dados inicialize antes de um servidor com SharePoint ou IIS estejam solicitando a este os dados para funcionamento. Este é um recurso importante para impedir os problemas comuns que temos quando utilizamos várias VMs, uma para cada função, sendo elas dependentes entre si. Para configurar este recurso utilize as propriedades da maquina virtual: No exemplo citado, o servidor de banco de dados estaria com prioridade Alta, o servidor com IIS ou SharePoint com prioridade média ou mesmo baixa dependendo do tempo total de inicialização do banco de dados. Importante: Não existe um relacionamento entre as VMs, portanto todas que estiverem selecionadas como High serão iniciadas, depois as Medium e por ultimo as Low. Referencias: Windows 2012 – Failover Clustering http://technet.microsoft.com/en-us/library/hh831579   Para mais informações sobre o Windows Server 2012, acesse: http://clk.atdmt.com/MBL/go/425205719/direct/01/

Live Migration + vMotion + XenMotion–System Center Virtual Machine Manager 2012

04 outubro 2011 msincic System Center, Virtual Machine Manager, Virtualizaçao
É isso mesmo, o VMM 2012 irá contar com as três tecnologias de migração “a quente”. O VMM 2008 R2 já conta com o vMotion, mas ele gerencia de forma isolada do Live Migration do Hyper-V. Já o recurso do Xen, o XenMotion, não era suportado. Aliás, o Xen não era suportado no VMM 2008 R2. O que a Microsoft fez agora é compatibilizar as três tecnologias de migração. Porem não apenas isso, mas permite juntar no mesmo grupo de servidores (managed pool) Hyper-V, ESX e XenServer !!!!! Agora podemos colocar em um grupo, por exemplo, 3 servidores Hyper-V + 2 servidores VMWare ESX + 2 servidores XenMotion e o VMM 2012 irá conseguir migrar as VMs entre as 3 plataformas. Sensacional !!!!! Porem, note que entre os host Xen será usado o XenMotion, entre ESX o vMotion e entre o Hyper-V o Livre Migration. Entre eles o processo é de V2V, ou seja, com um restart. A grande mudança é usar o PRO Tips entre hosts mesmo que não Hyper-V e utilizar a tecnologia de move entre os hosts. Figura 1: Servidores ESX junto com servidores Hyper-V Figura 2: Nova arquitetura integrada Se quiser conhecer mais sobre isso poderá baixar os ppts da palestra que fizemos no TechEd 2011 em http://bit.ly/nTwJcZ Também acesse os portais do TechNet: Integração do VMM 2012 com XenServer: Managing Citrix XenServer Overview Integração do VMM 2012 com VMWare ESX: Managing VMware ESX Hosts Overview Alem disso, recente post do VP do Gartner comenta as novidades do VMM 2012 e do Hyper-V 3.0 colocando a Microsoft como a nova lider em recursos: http://blogs.gartner.com/chris-wolf/2011/09/20/hyper-v-3-a-windows-server-2003-remix