GetVirtual – Virtualization 4 All

My vision what Microsoft Virtualization and Cloud Computing bring to IT World

Category Archives: Hyper-V Server 2008 R2

Como configurar os utilizadores não-administradores para controlar o Hyper-V

Por padrão o Hyper-V está configurado que somente membros do grupo de administradores podem criar e controlar máquinas virtuais. Muitas das vezes e por razões de segurança, devemos configurar um utilizador não-administrativo criar e controlar máquinas virtuais.

O Hyper-V usa a estrutura de gestão de autorização do Windows para permitir que configure o que os utilizadores podem e não podem fazer com máquinas virtuais. Isso é muito poderoso e permite algumas opções de configuração úteis e interessantes. Para definir o processo é necessário ter em conta alguns termos do mundo da estrutura de gestão de autorização:

  • OPERAÇÃO Este é o bloco de construção básico do Gestor de autorização – e representa alguma acção que o utilizador pode executar. Algumas operações que existem na store de autorização incluem op_Create_VM (o ato de criar uma nova máquina virtual) ou op_Start_VM (o ato de iniciar uma máquina virtual).
  • TAREFA Uma tarefa é um agrupamento de operações. Não se cria todas as tarefas por padrão – mas poderá criar uma tarefa que foi rotulada como ‘control_VM’ e, em seguida, adicionar as operações para iniciar, parar, pausar e reiniciar uma máquina virtual para essa tarefa.
  • PAPEL Uma função que define um trabalho/posição/responsabilidade que é realizada por um utilizador. Por exemplo, pode ter uma função chamada ‘Virtual_Network_Admin’. Este papel teria todas as tarefas e operações relacionadas a redes virtuais. Os utilizadores são então atribuídos a funções conforme necessário.
  • ESCOPO Um escopo permite que seja definido quais objectos pertencentes a quais funções. Se tiver um sistema onde queira conceder acesso administrativo a um subconjunto das máquinas virtuais para um utilizador específico – irá criar um escopo para as máquinas virtuais e aplicar as alterações de configuração só nesse âmbito.
  • ESCOPO PADRÃO O escopo padrão é onde as máquinas virtuais são armazenadas por padrão. É o equivalente a ter nenhum escopo definido.

O Hyper-V pode ser configurado para armazenar a autorização de configuração no Active Directory ou em um arquivo XML local. Após a instalação inicial será sempre configurado para usar um arquivo XML local localizado em \programdata\Microsoft\Windows\Hyper-V\InitialStore.xml na partição do sistema. Para editar este arquivo, deverá seguir os seguintes passos:

  1. Abra a caixa de diálogo Run.
  2. Inicie o MMC.exe
  3. Abrir o menu File e seleccione Add/Remove Snap-in
  4. Na lista Available snap-ins selection Authorization Manager.
  5. Clique em Add > e, em seguida, clique em OK.
  6. Clique no novo nó Authorization Manager no painel esquerdo.
  7. Abra o menu Action e selection Open Authorization Store
  8. Escolha XML file para o Seleccionar a opção Select the authorization store type: e, em seguida, usar o Browse… para abrir \programdata\Microsoft\Windows\Hyper-V\InitialStore.xml na partição do sistema (programdata é um directório oculto, então vai precisar digitar em primeiro lugar).
  9. Clique em OK.
  10. Expanda InitialStore.xml, depois Microsoft Hyper-V services, depois Role Assignments e finalmente seleccione Administrator.
  11. Abra o menu Action e selection Assign Users and Groups para depois seleccionar From Windows and Active Directory
  12. Digite o nome do utilizador que quer seja capaz de controlar o Hyper-V e clique em OK.
  13. Feche a janela do MMC.

E agora está feito. O utilizador que adicionou será capaz de controlar completamente o Hyper-V, mesmo se ele não pertença ao grupo de administradores no computador físico local.

Configuração do controle não-administrativo do Hyper-V através do PowerShell

Em algumas ocasiões é necessário configurar o Hyper-V para permitir que um utilizador não-administrativo (Ex: Administrator) possa controlar tudo no Hyper-V. Como um utilizador consciente de segurança nunca deve usar uma conta administrativa – a menos que seja absolutamente fundamental para efectuar as operações diárias. Mas muitas das vezes existe a necessidade de seguir o processo manual documentado acima para configurar.

Desta forma por utilizar o script PowerShell abaixo para fazer esta configuração de uma forma automática:

# Get current users account information

$myWindowsID=[System.Security.Principal.WindowsIdentity]::GetCurrent()

$myWindowsPrincipal=new-object System.Security.Principal.WindowsPrincipal($myWindowsID)

# Get the security principal for the Administrator role

$adminRole=[System.Security.Principal.WindowsBuiltInRole]::Administrator

# Check to see if we are currently running “as Administrator”

if ($myWindowsPrincipal.IsInRole($adminRole))

   {

   # We are running “as Administrator” – so change the title and background color to indicate this

   $Host.UI.RawUI.WindowTitle = $myInvocation.MyCommand.Definition + “(Elevated)”

   $Host.UI.RawUI.BackgroundColor = “DarkBlue”

   clear-host

   }

else

   {

   # We are not running “as Administrator” – so relaunch as administrator

   # Create a new process object that starts PowerShell

   $newProcess = new-object System.Diagnostics.ProcessStartInfo “PowerShell”;

   # Specify the current script path and name as a parameter

   $newProcess.Arguments = $myInvocation.MyCommand.Definition;

   # Indicate that the process should be elevated

   $newProcess.Verb = “runas”;

   # Start the new process

   [System.Diagnostics.Process]::Start($newProcess);

   # Exit from the current, unelevated, process

   exit

   }

# Get the current AzMan store location from the registry

$AzManStoreLocation = (Get-ItemProperty -path “HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Virtualization”).StoreLocation

# Open the AzMan store

$AzManStore = new-object -ComObject “AzRoles.AzAuthorizationStore”

$AzManStore.Initialize(2, $AzManStoreLocation)

# Handle the default Hyper-V AzMan store and the SCVMM AzMan store

if (@($AzManStore.Applications | ? {$_.Name -contains “Hyper-V services”}).count -eq 1)

   {

   $HyperVAzManStore = $AzManStore.OpenApplication(“Hyper-V services”)

   }

elseif (@($AzManStore.Applications | ? {$_.Name -contains “Virtual Machine Manager”}).count -eq 1)

   {

   $HyperVAzManStore = $AzManStore.OpenApplication(“Virtual Machine Manager”)

   }

else

   {

   Write-Host “Unable to find AzMan application group.”

   Write-Host -NoNewLine “Press any key to continue…”

   $null = $Host.UI.RawUI.ReadKey(“NoEcho,IncludeKeyDown”)

   exit

   }

# Get the administrator role from the Hyper-V service in the AzMan store

$HyperVAdministratorsRole = $HyperVAzManStore.OpenRoleAssignment(“Administrator”)

# Check to see if the current user is in the Hyper-V administrator role

if (@($HyperVAdministratorsRole.Members | ? {$_ -contains $myWindowsID.User.Value}).count -eq 0)

   {

   # If no – add the user and submit the changes

   $HyperVAdministratorsRole.AddMember($myWindowsID.User.Value)

   $HyperVAdministratorsRole.Submit()

   }

Else

   {

   # If yes – inform the user that they are already a Hyper-V administrator

   Write-host $myWindowsID.Name “is already part of the Hyper-V administrators role assignment”

   Write-Host -NoNewLine “Press any key to continue…”

   $null = $Host.UI.RawUI.ReadKey(“NoEcho,IncludeKeyDown”)

   }

Algumas coisas importantes sobre este script:

  • Deve ser executado como administrador – e irá elevar mesmo que seja executado sem privilégios administrativos.
  • Irá adicionar automaticamente o utilizador actual como um administrador do Hyper-V. Se quiser adicionar outros utilizadores diferentes, irá de precisar de alterar o script.
  • Este script fala com objectos COM do AzMan – o que significa que não pode ser executado remotamente e deve ser executado directamente no servidor Hyper-V.
  • Este script irá lidar com o padrão Hyper-V e configurações de autorização do SCVMM –, mas se executar o script em um servidor autónomo Hyper-V, que mais tarde irá usar o SCVMM para gerir – vai precisar de executar o script novamente.

Windows Server 2008 R2 Failover Cluster: Cuidados com as redes!

O Failover Clustering do Windows Server 2008 R2 não é exactamente “desorientado” no que diz respeito às redes que ele usa. O que pode ser problemático, especialmente é quando as pessoas estão adquirir novos servidores com muitos e muitos NICs. Principal dica, documentar tudo, e só usar o que realmente precisa. Aqui estão algumas dicas:

  1. Rótulo suas conexões de rede com algo descritivo, como “Parent”, “CSV”, “VM1”, “Live Migration”, “HeartBeat”, ou “iSCSI1”, em vez dos inúteis “Conexão de Área Local 2”. Isso permite que possa acompanhar o que está fazer o quê.
  2. Desabilitar NICs não utilizados. Eles apenas atravancam as coisas em todo o lugar. E podem causar um pesadelo em quando eles são corrigidos em redes DHCP.
  3. Não desactive o IPv6, mesmo se não tem IPv6 na sua rede. MS irá apoiá-lo, mas é recomendado que o IPv6 é deixado ligado a todas as NICs física em nós do cluster.
  4. Desactivar tudo, exceto para o protocolo de switching do Hyper-V nos NICs do host que são utilizados ​​para redes das VMs, uma vez que verificar se estão mapeadas para a rede correctas. Isso é para evitar que o host seja um participante acidental na rede da VM, se a VLAN tem um escopo DHCP. Desta forma também mantém as coisas arrumadas.
  5. Desvincular tudo, excepto para TCP na rede iSCSI (que deve ser uma rede dedicada para iSCSI com switches dedicado). Muitas das vezes habilitar o Jumbo Frames pode ser benéfico na performance.
  6. Desactivar a opção de registo no DNS no NIC a ser utilizado pelo HeartBeat do Cluster

Como excluir o “Saved State” de uma máquina virtual por WMI?

O que se esta a referir é o fato de que, por meio da interface do utilizador do Hyper-V Manager, podemos excluir o “Saved State” de uma máquina virtual que está em um estado salvo (Figura abaixo):

O motivo mais comum para querer fazer isso porque moveu uma máquina virtual (com um estado salvo) para outro computador, e o estado salvo já não é compatível nesse computador.

O problema é que não há nenhum “excluir estado salvo” WMI API. A razão para isto é que, a um nível WMI, para excluir um estado salvo tudo que precisa fazer é “desligar” a máquina virtual. Aqui está um exemplo de script que desactiva uma máquina virtual:

TurnOffVM.ps1 – Copiar o conteúdo abaixo para o um ficheiro de Script de PowerShell “TurnOffVM.ps1”.

# Function for handling WMI jobs / return values

Function ProcessResult($result, $successString, $failureString)

{

   #Return success if the return value is “0”

   if ($result.ReturnValue -eq 0)

      {write-host $successString}

   #If the return value is not “0” or “4096” then the operation failed

   ElseIf ($result.ReturnValue -ne 4096)

      {write-host $failureString ”  Error value:” $result.ReturnValue}

   Else

      {#Get the job object

      $job=[WMI]$result.job

      #Provide updates if the jobstate is “3” (starting) or “4” (running)

      while ($job.JobState -eq 3 -or $job.JobState -eq 4)

         {write-host $job.PercentComplete “% complete”

          start-sleep 1

          #Refresh the job object

          $job=[WMI]$result.job}

       #A jobstate of “7” means success

       if ($job.JobState -eq 7)

          {write-host $successString}

       Else

          {write-host $failureString

          write-host “ErrorCode:” $job.ErrorCode

          write-host “ErrorDescription” $job.ErrorDescription}

       }

}

# Prompt for the Hyper-V Server to use

$HyperVServer = Read-Host “Specify the Hyper-V Server to use (enter ‘.’ for the local computer)”

# Prompt for the virtual machine to use

$VMName = Read-Host “Specify the name of the virtual machine”

# Get the management service

$VMMS = gwmi -namespace root\virtualization Msvm_VirtualSystemManagementService -computername $HyperVServer

# Get the virtual machine object

$VM = gwmi MSVM_ComputerSystem -filter “ElementName=’$VMName'” -namespace “root\virtualization” -computername $HyperVServer

# Turn off the virtual machine

$result = $VM.RequestStateChange(3)

# Check to see that we were successful

ProcessResult $result “The virtual machine has been turned off.” “Failed to turn off the virtual machine.”

Se executar este script em uma máquina virtual em execução, a máquina virtual será desactivada. Mas se executar este em uma máquina virtual que está em um estado salvo, o estado salvo será excluído em vez disso.

 

Network Load Balancing (NLB) em máquinas virtuais no Windows Server 2008 R2

Ao correr o NLB numa máquina virtual (Guest) no Windows Server 2008 R2 Hyper-V é necessário ter atenção a algumas definições de configurações específicas no host Hyper-V antes de configurar o NLB.

No Hyper-V, o host VM impede actualizações dinâmicas de endereço MAC como uma camada extra de segurança no datacenter.  Isso ocorre porque a máquina virtual pode ter direitos de administrador, no entanto, não pode ser confiável no data center, por exemplo, quando a hospedagem de VM é fornecida por uma empresa de hospedagem independente. Neste cenário, é preciso certificar de que uma VM não causa um ataque de divulgação DOS ou informações contra outra VM. Se uma máquina virtual é capaz de simular o seu endereço MAC, ele pode falsificar os endereços MAC de outras VMs (spoofing) e impacto sobre outras VMs nesse host. Os switches físicos têm protecções semelhantes e cabe ao administrador permitir a protecção ou não.

Se não habilitar a falsificação de endereço MAC antes da configuração do NLB sobre a máquina virtual, pode potencialmente ter problemas com o cluster de NLB.

Ao habilitar a configuração do NLB em modo unicast no Hyper-V com falsificação de endereço MAC desactivado, pode encontrar alguns dos seguintes sintomas:

  • Ao configurar inicialmente o NLB perderá conectividade de rede sobre o NLB que foi configurado no adaptador de rede.
  • Haverá um evento de erro NLB no log de eventos do Windows, afirmando que o adaptador de rede não oferece suporte a actualizações dinâmicas do MAC address.
  •  Após a reinicialização do servidor, o NLB parece estar ligado ao adaptador de rede, mas o VIP do cluster não tenha sido adicionado ao adaptador de rede.
  • O endereço MAC do cluster continuará a ser o endereço MAC original associado com o adaptador de rede antes de configurar o NLB.

    NOTA Utilize o CMD > ipconfig /all para ver o endereço MAC.  Deve começar com “02-BF-***”

  • Se ignorar todos os sintomas anteriores e adicionar manualmente o VIP pode começar a ter um conflito de IP se houver outros nós no cluster que tenham o mesmo VIP.

Com isto, para permitir que clientes VM corram NLB, precisa definir a propriedade VM para “Enable spoofing of MAC Address“.

Para habilitar a falsificação de endereços MAC (Spoofing), Abra a console de gestão do Hyper-V.  Verifique se a máquina virtual está desligada, abra as propriedades da máquina virtual. Seleccione o adaptador de rede para o NLB e marque “Enable spoofing of MAC Address” e clique em OK.  Em seguida, inicie a máquina virtual.

Densidade de máquinas virtuais no Failover cluster do Windows Server 2008 R2

Recentemente Windows Servidor 2008 R2 Failover Clustering mudou a declaração de suporte para o número máximo de máquinas virtuais (VMs) que pode ser hospedado em um cluster de failover, o aumento foi de 64 VMs por nó para 1000 VMs por cluster.

Apoiar 1000 VMs permitirá maior flexibilidade em utilizar hardware que tem a capacidade de hospedar mais VMs por servidor físico, mantendo a alta disponibilidade e componentes de gestão que o cluster de Failover fornece.

NOTA Não há nenhuma exigência para ter um nó sem qualquer VMs alocadas como um “nó passivo”. Todos os nós podem hospedar VMs e têm o equivalente ao 1 nó da capacidade desalocada (total, em todos os nós) para permitir a colocação de VMs se um nó falhar ou for tomada de activa participação para actividades como executar a manutenção ou aplicar patches em cluster.

Número de nós no cluster Número máximo de VMs por nó Número médio de VMs por nó ativo Max # VMs em cluster
2 Nós (1 activo + 1 failover)

384

384

384

3 Nós (activo 2 + 1 failover)

384

384

768

4 Nós (activo 3 + 1 failover)

384

333

1000

5 Nós (activo 4 + 1 failover)

384

250

1000

6 Nós (activo 5 + 1 failover)

384

200

1000

7 Nós (activo 6 + 1 failover)

384

166

1000

8 Nós (activo 7 + 1 failover)

384

142

1000

9 Nós (activo 8 + 1 failover)

384

125

1000

10 Nós (activo 9 + 1 failover)

384

111

1000

11 Nós (activo 10 + 1 failover)

384

100

1000

12 Nós (activo 11 + 1 failover)

384

90

1000

13 Nós (activo 12 + 1 failover)

384

83

1000

14 Nós (activo 13 + 1 failover)

384

76

1000

15 Nós (activo 14 + 1 failover)

384

71

1000

16 Nós (activo 15 + 1 failover)

384

66

1000

É importante executar o planeamento de capacidade adequada que leva em consideração os recursos do hardware e do armazenamento em host VMs, e o total dos recursos que exigem as VMs individuais, enquanto continua a ter suficiente reserva capacidade de acolhimento das VMs em caso de uma falha no nó para impedir que a memória seja ultrapassada ou um “Over Commitement”. A mesma orientação base de configuração do Hyper-V e os limites de um número máximo de VMs suportado por servidor físico ainda se aplicam. Actualmente indica que nenhum nó pode hospedar mais de 384 executando VMs em determinado momento, e que a escalabilidade de hardware não deve exceder 4 processadores virtuais por VM e não mais que 8 processadores virtuais por processador lógico.

Vários problemas ao tentar gerir um host Windows Server 2008 R2 Hyper-V, ao utilizar o SCVMM 2008

Quando tenta gerir um host Windows Server 2008 R2 Hyper-V, recorrendo ao System Center Virtual Machine Manager 2008 (a versão RTM, não a versão R2), consegue manter em execução mas com muitas questões que podem impedir o correcto funcionamento?  Se assim for a justificação está abaixo:

A versão original do VMM 2008 não oferece suporte a gestão par o hosts do R2 do Windows Server 2008 Hyper-V.  Para gerir hosts do Windows Server 2008 R2 Hyper-V, precisa fazer upgrade para o System Center Virtual Machine Manager 2008 R2.

Para torná-lo ainda mais oficial, o seguinte site TechNet foi atualizado para indicar que a gestão de hosts Hyper-V R2 requer VMM 2008 R2

LINK DO TECHNET

NVSPBind – Nova ferramenta para configurações de adaptadores de rede

A equipe do Hyper-V, lançou uma ferramenta que vem ajudar em muitas instalações core do Windows Server 2008, Windows Server 2008 R2 e Microsoft Hyper-V Server, esta ferramenta é o NVSPBind (Network Virtual Service Provider Bind).

Em uma instalação completa do Windows, é possível habilitar ou desabilitar protocolos de um adaptador de rede utilizando o mini aplicativo de conexões de rede no painel de controle (aka ncpl.cpl) simplesmente ao clicar ou desmarcando protocolos conforme necessário (imagem abaixo).

Este “applet” não está disponível no server core e não existia nenhum utilitário para executar esta acção.

Para demonstrar a facilidade e utilidade desta ferramenta vamos utilizar um exemplo muito simples e dizer que queremos desactivar de arquivos e partilhamento de impressoras ( File and Printer Sharing ) para redes Microsoft em um adaptador.

O primeiro passo é obter o GUID que identifica o adaptador. Isto pode ser conseguido ao executar o nvspbind sem parâmetros de linha de comando. Aqui está a saída truncada de uma máquina de teste mostrando a placa de rede que procuramos:

{F93672D9-9085-4EEF-9669154AD4391ED7}
“pci\ven_8086&dev_10c9&subsys_a03c8086”
“Intel(R) Gigabit ET Dual Port Server Adapter”:
enabled:  ms_netbios       (NetBIOS Interface)
enabled:  ms_server        (File and Printer Sharing for Microsoft Networks)
enabled:  ms_pacer         (QoS Packet Scheduler)
disabled: ms_ndiscap       (NDIS Capture LightWeight Filter)
enabled:  ms_wfplwf        (WFP Lightweight Filter)
enabled:  ms_msclient      (Client for Microsoft Networks)
enabled:  ms_tcpip6        (Internet Protocol Version 6 (TCP/IPv6))
enabled:  ms_netbt         (WINS Client(TCP/IP) Protocol)
enabled:  ms_smb           (Microsoft NetbiosSmb)
enabled:  ms_tcpip         (Internet Protocol Version 4 (TCP/IPv4))
enabled:  ms_lltdio        (Link-Layer Topology Discovery Mapper I/O Driver)
enabled:  ms_rspndr        (Link-Layer Topology Discovery Responder)
enabled:  ms_pppoe         (Point to Point Protocol Over Ethernet)
enabled:  ms_ndisuio       (NDIS Usermode I/O Protocol)
disabled: vms_pp           (Microsoft Virtual Network Switch Protocol)

O GUID é está na parte superior da saída (Iniciado “{F9367”). O protocolo que deseja desvincular neste exemplo é ms_server (o nome abreviado de arquivo e partilhamento de impressoras para redes Microsoft).

Para alcançar o objectivo utilizamos o parâmetro -d como a seguir:

C:\>nvspbind -d {F93672D9-9085-4EEF-9669154AD4391ED7} ms_server
Hyper-V Network VSP Bind Application 6.1.7672.0.
Copyright (c) Microsoft Corporation. All rights reserved.
acquiring write lock…success

Adapters:
{F93672D9-9085-4EEF-9669154AD4391ED7}
“pci\ven_8086&dev_10c9&subsys_a03c8086”
“Intel(R) Gigabit ET Dual Port Server Adapter”:
unbinding ms_server from Intel(R) Gigabit ET Dual Port Server Adapter
unbinding ms_server from Intel(R) Gigabit ET Dual Port Server Adapter
unbinding ms_server from Intel(R) Gigabit ET Dual Port Server Adapter
unbinding ms_server from Intel(R) Gigabit ET Dual Port Server Adapter
unbinding ms_server from Intel(R) Gigabit ET Dual Port Server Adapter
unbinding ms_server from Intel(R) Gigabit ET Dual Port Server Adapter
applying changes…
cleaning up…releasing write lock…success
finished
C:\>

O NVSPBind também tem a capacidade para permitir ligações de vincular ou desvincular o protocolo de switch de rede do Hyper-V de uma placa de rede e reparar ligações de uma NIC.

NOTA
Como com todos os utilitários que alteraram as configurações de rede, deve ser extremamente cuidadoso, pois pode atrapalhar ou até mesmo perder a conectividade de rede se estiver a administrar uma máquina remotamente.

As opções disponíveis no NVSPBind:

  • /n display NIC information only
  •  /u unbind switch protocol from specified nic(s)
  •  /b bind switch protocol to specified nic(s)
  •  /d disable binding of specified protocol from specified nic(s)
  •  /e enable binding of specified protocol to specified nic(s)
  •  /r repair bindings on specified nic(s)
  •  /o show NIC order for specified protocol
  • /+ move specified NIC up in binding order for specified protocol
  • /- move specified NIC down in binding order for specified protocol
  • /++ move specified NIC up to top of binding order for specified protocol
  • /– move specified NIC down to bottom of binding order for specified protocol

Para fazer download da ferramenta, utilize o link abaixo (Microsoft_Nvspbind_package.EXE):
NVSPBind

Como corrigir: Hypervisor not running

Este é um caso do Hypervisor que se aparece tantas vezes em fóruns, listas, etc. A mensagem para o efeito é “The Hypervisor não está em execução”, geralmente acontece quando o utilizador tenta iniciar uma VM. Para tentar ultrapassar esta questão veja o vídeo abaixo, com as etapas para investigar essa falha e corrigir.

Neste vidro de 5 minutos, demonstra como alterar as definições da BIOS no computador para fazer com que o Hypervisor corra.

http://www.microsoft.com/video/en/us/details/25d07f2e-b2e0-4c0c-b456-79b08bfe58be

Actualização do Infrastructure Planning and Design para Virtualização

A Microsoft lançou o Infrastructure Planning and Design com dois guias actualizados de virtualização:

Windows Server Virtualization e o System Center Virtual Machine Manager

Estes guias, foram actualizados para refletir os recursos e funcionalidades do Windows Server 2008 R2 e System Center Virtual Machine Manager 2008 R2, delinear os elementos de design de infra-estruturas críticas que são cruciais para uma implementação bem-sucedida desses produtos de virtualização.

O Infrastructure Planning é um guia de design para o Windows Server Virtualization leva o utilizador através do processo de criação de componentes, layout e conectividade em uma ordem lógica e sequencial. Identifica os hosts de servidor de Hyper-V necessários, e apresenta em etapas fáceis de seguir, o que ajuda o utilizador para projetar e planear datacenters virtuais.

O Infrastructure Planning and Design Guide para o Microsoft System Center Virtual Machine Manager auxilia os utilizadores na concepção e implementação da arquitetura do SCVMM, permite assim centralizar de administração de computadores físicos e virtuais. Identificar as instâncias de servidor do VMM necessárias é um dos processos de design simples e de uma etapa de sete passos apresentados neste guia.

Para fazer download deste guias utilize o link abaixo
Guias IPD para virtualização

Microsoft Hyper-V Server 2008 R2 disponível para download

Foi anunciado que o Microsoft Hyper-V Server 2008 R2 está disponível para download. Foi uma longa e emocionante espera por este produto. Pois com as novas funcionalidades (Live Migration e Cluster, entre outros), vamos poder realmente ter uma plataforma de virtualização estável e segura, para todos os bolsos. Isto porque o Microsoft Hyper-V Server 2008 R2 é gratuito.

O gráfico abaixo diz tudo. É uma plataforma robusta de virtualização com a Live Migration inserida e sem nenhum custo extra.

Comparar o Hyper-V Server V1 versus Hyper-V Server V2

  Microsoft Hyper-V Server 2008 Microsoft Hyper-V Server 2008 R2
Suporte de processador físico Até 4 processadores Até 8 processadores
Suporte de processador lógico Até 16 Até 64
Suporte de memória física Até 32 GB

 

Até 1 TB

 

Live Migration Não Sim
Alta disponibilidade Não Sim
Opções de gestão

 

MMC Hyper-V, Windows Server 2008, Windows Server 2008 R2, System Center Virtual Machine Manager 2008/R2 Remoto Server Administration Tool (gratuita), Windows Server 2008 R2, System Center Virtual Machine Manager 2008 R2

Umas das novas funcionalidadese que o Microsoft Hyper-V Server 2008 R2 também oferece é o suporte a inicialização do flash.

Apenas recordar que recursos esta versão possui:

  1. Alta disponibilidade e Live Migration para gerir uma infra-estrutura dinâmica de TI
  2. Suporte para 64 processadores lógicos para dimensionar com o hardware de revisão
  3. Suporte para executar até 384 máquinas virtuais com até 512 processadores virtuais
  4. Processor compatibility mode para a Live Migration através do SKU de processador diferentes do mesmo fornecedor
  5. Adicionar/remover de armazenamento virtual em execução
  6. Aprimoramentos de rede (VMQ, Chimney, apoio frames Jumbo).
  7. Gestão simplificada utilizando o cmd sconfig
  8. Arrancar a partir de flash

Para fazer download do  Microsoft Hyper-V Server 2008 R2, clique AQUI

Snapshots de Máquina Virtual no Windows Server 2008 Hyper-v

Os Snapshots de uma máquina virtual são ficheiros baseados no estado, nos dados do disco e na configuração da máquina virtual num determinado ponto no tempo. Pode-se tirar vários Snapshots de uma máquina virtual, mesmo que a VM esteja online. Em seguida, pode reverter a máquina virtual a qualquer dos Estados anteriores aplicando-se um snapshot à máquina virtual.

Para ter um snapshots, pode utilizar Hyper-V Manager ou Virtual Machine Connection. Todas as outras tarefas que pode executar com Snapshots, como aplicar ou excluir um snapshots ou exibir a lista de todos os Snapshots para uma máquina virtual específica, estão disponíveis através do Hyper-V Manager. Também pode inspeccionar ou editar os ficheiros .avhd, bem como determinar em qual snapshots um ficheiro de .avhd está associado.

NOTA Não edite um disco rígido virtual quando é utilizado por uma máquina virtual com Snapshots.

Considerações sobre Snapshots de máquina virtual

Os Snapshots podem ajudar a aumentar a eficiência em muitas configurações onde pode precisar de recriar diferentes ambientes e reproduzir várias condições nesses ambientes. Alguns exemplos incluem o desenvolvimento de software e teste, serviços de suporte técnico e desenvolvimento de currículos de formação.

Entretanto, o mesmo poder e flexibilidade que torna esses Snapshots, úteis e eficazes em determinadas configurações podem causar consequências indesejadas e potencialmente graves em outras configurações. Estas consequências incluem os riscos inerentes à perda de dados involuntária se os Snapshots não forem geridos apropriadamente. Por exemplo, se editar um disco rígido virtual ligado a uma máquina virtual com Snapshots, poderá ocorrer na perca de informação.

Umas das configurações mais apropriadas para o uso dos Snapshots são no desenvolvimento e teste de actividades, incluindo a utilização da máquina virtual como um servidor de teste para testar as actualizações e hotfixes antes de implantá-los para servidores de produção. Não é nada recomendável utilizar Snapshots em máquinas virtuais que prestam serviços sensíveis no tempo, tais como serviços do Active Directory, ou quando o desempenho ou a disponibilidade de espaço de armazenamento é crítica.

Além disso, deve considerar o seguinte antes de utilizar os Snapshots:

  • Fazer um snapshots reduz o desempenho da máquina virtual, enquanto o snapshots é criado. Não deve usar esses Snapshots em máquinas virtuais que prestam serviços em um ambiente de produção.
  • Não é recomendável o uso Snapshots em máquinas virtuais que estão configuradas com discos rígidos virtuais fixos, isto porque reduzem os benefícios de desempenho que podem de alguma forma adquirir ao utilizar discos rígidos virtuais fixos.
  • Os Snapshots exigem espaço de armazenamento adequados. Os Snapshots são armazenados como ficheiros de .avhd no mesmo local no disco rígido virtual. Vários Snapshots podem rapidamente consumir uma grande quantidade de espaço de armazenamento. Quando usa Hyper-V Manager para excluir um snapshots, o snapshots é removido da árvore do snapshots, mas o ficheiro .avhd não é excluído até desligar a máquina virtual.

    NOTA Não exclua ficheiros .avhd directamente do local de armazenamento.

  • Os Snapshots de uma máquina virtual não são os mesmos como os Snapshots criados pelo VSS (volume sombra Copy Services). Snapshots da máquina virtual podem ser uma maneira útil para criar cópias de segurança temporárias de uma máquina virtual, mas não um substituto para uma solução de backup permanente.

Reserva de memória no Host com o Windows Server 2008 R2

Com um servidor standalone Windows Server 2008 R2 que corre o Hyper-V (qualquer host de Hyper-V não-cluster), a quantidade de memória reservada para um host (máquina física) é a memória não alocada para a VM guest (máquina virtual). Portanto, quando for criar as VMs pode determinar a quantidade de memória que será reserva para o host. Pode colocar quantas VM num determinado host, quanto o host e as VM guests poderem funcionar eficazmente. Pois VMs em estado shutdown, não entra na contagem de memória reservada do host.

Semelhante a um servidor standalone, a quantidade de memória física não reservada para as máquinas VM guests em um nó de cluster de failover é reservado pelo host. No entanto, como parte do cluster, um host pode muitas vezes receber VM guests de outros nós do cluster e mantê-las altamente disponíveis. Isto pode ser uma passagem iniciada pelo utilizador como uma live migration de uma VM de outro nó ou uma falha de recurso ou hardware que causaria o failover das VMs. Como resultado, o utilizador não tem mais controle sobre a memória reservada para o host. As VM guests do outro nó podem facilmente mover para um determinado nó e encher a sua memória. Isso deixaria a memória insuficiente para serviço de cluster, que é executado no host, para fornecer uma tolerância a falhas para a VM e nas operações de migração. Como resultado, a variável de ambiente de cluster RootMemoryReserved foi introduzida para assegurar que em cluster de hosts de VM, um montante mínimo de memória física é reservada para o host.

RootMemoryReserve

Apesar do nome, a variável RootMemoryReserved não garante literalmente que a partição raiz teria uma certa memória física reservada para si. Pelo contrário, especifica um tamanho de memória para o host do sistema operativo comparar quando o host de sistema operativo está prestes a iniciar uma VM (que foi movida para esse nó por acção do utilizador ou do recurso de failover). Se, em seguida, ao iniciar uma VM, o host a memória física restante do sistema operativo desça abaixo do limite especificado pelo RootMemoryReserved, a operação de início da VM falha.

Por exemplo, em um nó do cluster com 16 GB de memória física e o RootMemoryReserved definida a 1024 MB (1 GB). Se cada VM pode ficar com até 1 GB, o número máximo de VM que pode estar online são 15, pois o 1 GB de memória é reserva pelo host OS. Todas as tentativas de iniciar a 16ª VM traria o uso de memória física das VMs acima de 15 GB, o que causaria que a reserva de memória física para o host OS caísse para abaixo de 1 GB disponíveis. Assim, a operação de início da 16ª VM irá falhar.

O RootMemoryReserved é por padrão de 512 MB. Isso deve ser suficiente para o host de VM que não está executar qualquer operação que não gerir as VMs. Esta variável pode ser vista pelo cmdlet PowerShell

(get-cluster <cluster name>).RootMemoryReserved

Para alterar o RootMemoryReserved, para o tamanho desejado de memória reservada é atribuído com o cmdlet PowerShell acima mencionado. Use o seguinte cmdlet do PowerShell para definir RootMemoryReserved para 1024 MB (como exemplo):

(get-cluster <cluster name>).RootMemoryReserved=1024

Alterar o RootMemoryReserved não afecta quaisquer VMs que já estejam em execução. Por exemplo, em um nó com 16 GB de memória física, se RootMemoryReserved estiver definido como 512 MB e as VMs estão a ocupar mais de 15 GB de memória, isso deixaria o host, com menos de 1 GB de memória. Se por algum motivo, tais como o outro aplicativo em execução no host, provocar o sistema lento, a alteração do RootMemoryReserved para 2048 MB (2 GB) não vai automaticamente libertar memória física para o host. Neste cenário, a única maneira para libertar a memória física para o host é colocar uma das VMs em offline. Por conseguinte, é recomendável que o RootMemoryReserved desejado ser definido adequadamente antes de iniciar qualquer VMs online.

O valor máximo para o RootMemoryReserved é 4096 MB (4 GB). Qualquer alteração de um valor superior a 4 GB vai ser ignorado e o valor anterior iria ser utilizado. Também, RootMemoryReserved, como um parâmetro de cluster, aplica-se a todos os nós do cluster. O valor RootMemoryReserved deve ser usado para reservar a memória no host de VMs em todos os nós do cluster.

A variável RootMemoryReserved não limita a quantidade de memória que o host pode utilizar. O propósito dessa variável visa garantir que o host terá um montante mínimo de reserva de memória física para controlar as VMs. O host definitivamente pode usar muito mais memória do que o valor definido para o RootMemoryReserved. Portanto, o montante de memória física disponível para as VMs deverá ser igual ou inferior ao montante de memória não reservada para o RootMemoryReserved.

Como habilitar o PowerShell no Hyper-V Server 2008 R2

Um dos novos recursos do Microsoft Hyper-V Server 2008 R2 é que agora pode activar o PowerShell sobre ele. Isso é realmente útil quando deseja realizar tarefas básicas localmente, em vez de ter de usar a interface de utilizadore remoto. Para fazer isso tudo o que precisa fazer é executar o comando a seguir:

start /w ocsetup MicrosoftWindowsPowerShell

Depois que pode iniciar a janela de comando PowerShell ao executar o seguinte comando:

start C:\Windows\System32\WindowsPowerShell\v1.0\PowerShell.exe

Pode ver os resultados na imagem abaixo.

Porquê aplicar um snapshot num controlador domínio numa VM pode ter problemas?

Esta é uma questão bastante comum para na comunidade de TI.

Imagine que tem uma VM que está associada a um domínio e está a funcionar perfeitamente. Faz um snapshot, para assim pode restaurar a VM a este ponto mágico de workingness, a qualquer momento. Quando precisar de acionar esta VM e para testar algo, precisa reverter para o snapshot e iniciar a VM. Logo após aparece uma mensagem a dizer que o domínio não confia mais na sua estação de trabalho (virtual). O que é que aconteceu? Não foram feitas alterações no snapshot!  Por isso que ele é chamado de snapshot!  Por isso que isto dá erro?

Bem, tem razão. Não foram feitas alterações no snapshot, e isso é parte do problema.

Faz parte das políticas de domínio (por padrão) do Active Directory para um membro de domínio alterar a password da conta agora e sempre. Sem dúvida tem que alterar a password para a conta de utilizador ocasionalmente, portanto, isso não deveria ser uma surpresa. O que pode ser uma surpresa é que a mesma coisa acontece para contas de computador. Eis a razão – os computadores têm contas, também.

Agora então (por padrão, a cada 30 dias, mas o valor é configurável através de politica de domínio), a estação de trabalho vai negociar uma nova password com o domínio. Tudo acontece nos bastidores, sem o seu conhecimento.

Salvo, se tiver uma VM ingressada no domínio com snapshots tirados ao mesmo tempo (servidor e cliente).

O problema surge porque a estação de trabalho – em algum momento – negoceia uma nova password com o domínio e regista-a para uso futuro.  Em seguida, o snapshot foi aplicado, e desta forma activou a VM a “viajar de tempo”. Esta VM do passado foi levada para o futuro e não tem conhecimento de tudo o que aconteceu no intermédio. Portanto, a Vm pensa que a antiga password é ainda está actualizada. E ele tenta utilizar essa mesma password. E o domínio ao verificar que a password é diferente, nega o acesso.

Por que razão o Hyper-V deixa isso acontecer?

Não é apenas o Hyper-V. Isso acontece o tempo todo para qualquer VM em qualquer tecnologia de virtualização (desde que tenha a possibilidade de fazer snapshot e poder aplica-lo). A mesma coisa vai acontecer em qualquer situação onde tenha que “convencer” o Windows que a password da conta do computador é algo que não é (como restaurar um snapshot ou qualquer outro tipo de backup).

O que pode se pode fazer sobre este problema?

Existem três possibilidades.

  1. Se puder, mudar a política de domínio padrão ou obtenha uma excepção criada para sua conta(s) de computador(es). Isso não é a melhor opção porque abre um buraco de segurança (pequeno como podem ser).
  2. Logon numa conta de administrador local no sistema e retirar do domínio. Em seguida, voltá-lo a colocar no domínio. A conta do computador irá obter uma nova password, e esta actualizada, que a estação de trabalho conhece. Alternativamente, poderá utilizar o NETDOM.EXE para redefinir a senha da conta do computador. Pode sempre automatizar este mesmo processo, se precisar.
  3. Sysprep na VM e criar um arquivo autónomo que irá configurá-la de acordo com o que pretende, que poderá ser ingressar automaticamente no domínio, por exemplo. Uma vez que a máquina utilize o sysprep, pode fazer um snapshot e sempre restaurar para aquele ponto, daqui por diante.

Mais novidades no Windows Server Hyper-V 2008 R2

Foram anunciadas mais novidades no Tech.Ed relativamente ao Windows Hyper-V Server 2008 R2.

Escalabilidade
Apoio de 64 processador lógico Esta é uma melhoria de 4x sobre o Hyper-V R1 e significa que Hyper-V pode tirar proveito da escalabilidade de maiores de sistemas, com maior quantidade de recursos de computação. Assim como a AMD e a Intel estão sempre aumentar o número de núcleos, também o Hyper-V está pronto para aproveitar os recursos de computação nos servidores de hoje e num futuro próximo.

Apoio até 384 VMS simultaneamente e 512 virtual processors por servidor Vai lado a lado com o apoio para 64 processadores lógicos, subiu o número máximo de máquinas virtuais para 384 por servidor e o número máximo de processadores virtuais para 512 para a mais elevada densidade de máquina virtual por servidor no mercado. Aqui estão alguns exemplos do que poderia ser executado num servidor Hyper-V R2:

  1. 384 VM de um único processador virtual
  2. 256 de vms de duplo processador virtual (512 processadores virtual)
  3. 128 de vms de quad processador virtual (512 processadores virtual)
  4. Qualquer combinação tão longa como se estivesse executando 384 VMs e até 512 processadores virtual

Live Migration e Processadores
Com a adição do Live migração no Hyper-V R2, uma das questões imediatas que se faz é: “os processadores físicos têm de ser exactamente os mesmos?”

Vejamos então estes dois exemplos reais:

Cenário 1: suponha que comprou três servidores para o Live Migration e criou um cluster de três nó. Tudo trabalha bem e a 6 a 12 meses pretende adicionar outro par de nós para aumentar os recursos de computação no cluster. Entretanto, o OEM actualizou a sua linha de hardware de servidor com novos processadores, agora o que fazer?

Cenário 2: Trabalha em uma PME e precisa reduzir cada euro que você fica fora do seu orçamento. Deseja usar a virtualização e gostaria de usar o Live Migration, mas tem uma mistura de diferentes servidores variando Pentium 4, Core 2 e talvez no próximo ano obterá orçamento para comprar um novo servidor de Core I7.

Não seria óptimo se pudesse fazer o Live Migration nas máquinas virtuais entre gerações diferentes de processadores?

Então tenho uma novidade, o Windows Hyper-v Server R2 tem a solução!

Compatibilidade de processador
Com Hyper-V R2, incluem um novo recurso de compatibilidade de processador. Compatibilidade de processador permite mover uma máquina virtual para cima e para baixo várias gerações de processador do mesmo fornecedor. Eis como funciona.

Quando uma máquina virtual (VM) é iniciado em um host, o hypervisor expõe o conjunto de processadores suportados como recursos disponíveis no hardware subjacente para a VM. Este conjunto de recursos de processador é chamado de recursos de processador visível convidado e estão disponíveis para a VM até que a VM seja reiniciada.

Quando uma VM é iniciada com modo de compatibilidade de processador activo, o Hyper-V normaliza o conjunto de recurso de processador e só expõe funcionalidades de processador visível de convidado que estão disponíveis em todos os processadores de Hyper-V activo da arquitectura de processador mesmo, ou seja, a AMD ou Intel. Isso permite que a VM seja migradas para qualquer plataforma de hardware da arquitectura de processador. Recursos de processador são “ocultos” pelo hypervisor interceptando instrução de CPUID de uma VM e desmarcando os bits retornados correspondentes os recursos ocultos.

NOTA Significa que é possivel de AMD <-> AMD e de Intel <-> Intel. Não se consegue fazer Live Migration entre diferentes fornecedores de processador (ex: AMD <-> Intel ou vice-versa).

Além disso, pode estar ciente de que tanto a AMD e como a Intel fornecem capacidades semelhantes em hardware, Extended Migration e Flex Migration, respectivamente. Extended e Flex Migration são tecnologias interessantes disponíveis em processadores relativamente recentes, mas este é um caso onde fornecer a solução de software permite ser mais flexível e fornecer esse recurso para sistemas mais antigos também. Compatibilidade de processador também facilita a actualização para um hardware de servidor mais recente. Além disso, a compatibilidade de processador de Hyper-V pode ser feita numa base por VM (é um checkbox, conforme figura 1) e não requerem quaisquer alterações de BIOS.

Figura 1 – Opção de compatibilidade de diferentes processadores durante a Live Migration