Este documento descreve os procedimentos usados a fim pesquisar defeitos Series Switch do nexo 1000V de Cisco (N1KV) em server hyper-v de Microsoft (MS). A aplicação em hyper-v é muito diferente do que em ESXi, tão haverá algum edições frequente-encontradas; assim, este documento foi criado.
Muita da informação descrita neste documento vem diretamente da introdução de novos produtos da engenharia (NPI), e das edições encontradas durante o teste beta. Este documento é dinâmico na natureza, e será atualizado em conformidade.
A Cisco recomenda que você tenha conhecimento destes tópicos:
Este documento não se restringe a versões de software e hardware específicas.
As informações neste documento foram criadas a partir de dispositivos em um ambiente de laboratório específico. Todos os dispositivos utilizados neste documento foram iniciados com uma configuração (padrão) inicial. Se a sua rede estiver ativa, certifique-se de que entende o impacto potencial de qualquer comando.
Há muitas edições com o applicaton do instalador, e esta seção descreve as mais comuns.
Estão aqui os alguns motivos pelas quais você deve usar este aplicativo com cuidado:
O applicaton do instalador é significado somente trabalhar em ambientes do Greenfield. Não tente usar o aplicativo em uma configuração precedente-estabelecida. A fim verificar se os erros-para fora do instalador, navegam ao C: > os usuários > o <username> > AppData > o Local > o Temp > 2 > Nexus1000vInstaller_xxxxxxxx.txt, e verificam o log.
O comportamento do padrão (e somente) do aplicativo de instalador é indicar e usar o NIC físico a que a relação do mgmt é conectada. Quando você executa o aplicativo de instalador, você pode somente escolher um NIC - o mgmt NIC.
O aplicativo de instalador:
Esta imagem ilustra como um dos anfitriões tem agora um interruptor lógico MS atribuído, e um NIC virtual que leve o tráfego do mgmt:
Você pode ver que o uplink está definido sem a equipe do uplink quando você vê o interruptor lógico que está criado. Este é um problema porque você não pode adicionar um outro NIC ou um NIC teamed a este interruptor. Não está permitido você mudar o tipo de equipe uma vez que o interruptor é criado. Também, o aplicativo de instalador não permite que você adicione uma relação teamed.
A fim mudar o interruptor ao teamed, você deve removê-lo e adicionar-lo para trás com um grupo do equipe. Isto é possível, mas fastidioso. Você quer a Redundância, assim que se não teamed, a seguir lá é um problema potencial.
Este é um outro problema porque os VS são amarrados somente a estes dois anfitriões. Assim, a migração viva e o Home Agent de Cisco (HA) são limitados a dois anfitriões. Você tem a opção para migrar os outros anfitriões hyper-v ao interruptor lógico MS que é criado, mas não é terminado automaticamente pelo aplicativo de instalador.
Quando os ajustes da máquina virtual VS (VM) são criados, a Disponibilidade tem um valor do ponto baixo. O MS permite somente que os VM com Disponibilidade dos valores da elevação sejam incluídos no armazenamento Conjunto-Basear. Isto coloca o disco virtual VS (VD) e a informação VM no armazenamento local do host hyper-v. Além disso, isto limita a vivo-migração e o HA para o VS VM.
O aplicativo de instalador cria muito uma configuração básica no VS, e importa alguma dessa configuração ao gerente da máquina virtual de System Center (SCVMM).
O aplicativo executa estas ações do lado N1KV:
O aplicativo cria não somente estes ajustes no VS, mas povoa esta informação em SCVMM quando cria o interruptor lógico.
O aplicativo faz bem no Aspecto da configuração, mas tem problemas com a rede do uplink. Isto é como o uplink da rede é criado:
nsm network uplinkn1kv_uplink_network_1_VSM-install1
import port-profile n1kv_uplink_network_policy_VSM-install1
allow network segment pool n1kv_network_segment_pool_VSM-install1
native network segment n1kv_vmaccess_1_VSM-install1
system network uplink
publish network uplink
Há um uplink da rede de sistema, que cause uma edição. Se você tem um uplink com o uplink da rede de sistema ajustado, a seguir todos os segmentos de rede e porta-perfis que usam esse uplink devem ser sistema também. Isto significa que você está limitado a 32 segmentos de rede que podem usar esse uplink.
Não é claro que este é um problema, mas deixa-nos mostrar um exemplo do que acontece se você constrói um segmento de rede e um molde novos do IP pool para VLAN 152:
VSM-install1(config)# nsm ip pool template vlan-152
VSM-install1(config-ip-pool-template)# ip address 192.168.152.2 192.168.152.253
VSM-install1(config-ip-pool-template)# network 192.168.152.0 255.255.255.0
VSM-install1(config-ip-pool-template)# default-router 192.168.152.1
VSM-install1(config)# nsm network segment segment-vlan-152
VSM-install1(config-net-seg)# switchport mode access
VSM-install1(config-net-seg)# switchport access vlan 152
VSM-install1(config-net-seg)# ip pool import template vlan-152
VSM-install1(config-net-seg)# member-of network segment pool n1kv_network_
segment_pool_VSM-install1
VSM-install1(config-net-seg)# publish network segment
VSM-install1(config-net-seg)#
Refresque a extensão SCVMM N1KV, e adicionar a rede VM para o segmento de rede que você criou. Quando você tenta atribuir um VM à rede nova VM, você obtém estes erros:
Error (12700)
Failed while applying switch port settings 'Ethernet Switch Port Profile Settings'
on switch 'n1kv_VSM-install1': A device attached to the system is not functioning.
(0x8007001F). Unknown error (0x8005)
Error (26908)
Virtual switch on host to which the virtual network adapter is to be connected
(n1kv_VSM-install1) is a non compliant logical switch instance
Estes erros são causados porque o uplink da rede leva uma rede de sistema e o segmento de rede não faz. Você tem duas opções: crie um uplink novo da rede sem uma rede de sistema, ou adicionar uma rede de sistema a seu segmento de rede novo.
A Conectividade entre o VS e o SCVMM é diferente com hyper-v do que com ESXi. Na solução hyper-v, SCVMM fala a nosso (nexo 1000V) API. Isto significa que a conexão está estabelecida e mantida do host SCVMM. Quando o comando connection svs da mostra é usado no VS, não mostra nada; não há nenhuma conexão SV nesta solução.
SCVMM igualmente vota o VS uma vez cada trinta minutos. Isto significa que você deve forçar um refrescamento se você quer ver as mudanças do VS aparecer imediatamente em SCVMM.
O fornecedor para hyper-v é similar ao de encaixe para N1KV em ESXi. A diferença é que não há nenhum fornecedor original para cada VS. Você precisa somente de executar o fornecedor instala uma vez. Isto povoa SCVMM com a informação que é precisada a fim compreender como falar ao VS.
O fornecedor não é específico a cada VS. O fornecedor é registrado no registro de Windows. Você pode procurar por VSEM no registro, ou navegue a este lugar:
Se você é em uma posição onde você não possa suprimir do fornecedor, a seguir você pode suprimir da entrada no registro e reiniciar o serviço SCVMM.
Note o lugar para o módulo na entrada de registro. A biblioteca Loadable dinâmica do fornecedor (DLL) deve ser instalada em c:\Program Files\Cisco\Nexus1000V, junto com um script do powershell que é usada a fim instalar o fornecedor. Assegure-se de que o DLL este presente.
Um desinstalar do fornecedor é terminado através de um desinstalar do programa do Control Panel hyper-v do server 2012. A fim reinstalar o fornecedor, fazer duplo clique o instalador do fornecedor.
Assegure-se de que a extensão do fornecedor esteja ativa e complacente em SCVMM. Navegue aos ajustes > aos fornecedores da configuração. Verifique que a extensão do nexo 1000V do Cisco Systems é ativa. Isto significa que a extensão está usada por SCVMM.
SCVMM fala ao VS, assim que você deve pesquisar defeitos do host SCVMM.
Verifique se:
Se você não pode sibilar o VS, a seguir verifique os Windows Firewall e verifique-os para ver se há questões de conectividade de rede. Não há nenhuma exigência que o VS e o SCVMM devem ser na mesma sub-rede.
A fim verificar o API, use o internet explorer (IE) e consulte ao RESTO API VS com esta corda: http://<vsm-ip>/api/n1kv.
Você deve receber esta saída:
Se você não pode alcançar o API, a seguir verifique isso:
N1KV no controle hyper-v dos usos L3 somente. Não há nenhuma maneira de controlar hyper-v com com controle L2. O controle da configuração L3 em hyper-v é muito mais fácil do que uma configuração similar em VMware. Não há nenhuma necessidade de dedicar um NIC ao VEM; o VS fala diretamente ao Gerenciamento hyper-v NIC do server 2012. Não há nenhuma exigência que o Gerenciamento NIC deve ser anexado ao módulo VEM, assim que significa que você não precisa um porta-perfil especial do veth para o controle L3.
A instalação do VEM é igualmente muito mais fácil. Não há nenhum componente do gerente da atualização de VMware (VUM) com SCVMM. A capacidade para instalar componentes da extensão é construída diretamente em SCVMM. Se o VEM não é instalado no host hyper-v, a seguir SCVMM copia e instala o VEM no host hyper-v do alvo automaticamente. Se você quer instalar manualmente o VEM, é um clique duas vezes simples do aplicativo de instalador VEM no host. O desinstalar é igualmente um programa simples remove do Control Panel.
Um erro comum que você pôde encontrar é que um host hyper-v não está adicionado ao N1KV com SCVMM. Há as verificações múltiplas que devem ser feitas a fim pesquisar defeitos esta edição.
Está aqui um erro típico que você pôde ver em SCVMM quando os VEM instalam falham:
Verifique para ver se há equipes velhas de rede no host hyper-v
Pôde haver uma equipe velha de um outro N1KV no host hyper-v. Em caso afirmativo, você deve suprimir da equipe velha antes que você adicione o host ao N1KV. No host hyper-v, execute Powershell e incorpore o comando GET-NetSwitchTeam. Se uma equipe velha aparece, a seguir você deve removê-la com o comando da remoção-NetSwitchTeam.
PS C:\> Get-NetSwitchTeam
Name: HPV7b9901d8-70b8-4063-b60e-bcd6679384f7 <<<< Logical Switch name is ?HPV?
Members: Ethernet
PS C:\> Remove-NetSwitchTeam -Name HPV7b9901d8-70b8-4063-b60e-bcd6679384f7
A unidade de transmissão máxima (MTU) dos NIC e os N1KV não combinam
As configurações MTU em hyper-v são ajustadas pelo NIC através dos ajustes NIC. Quando você cria uma equipe, o MS encarrega-se de que as configurações MTU de todos os NIC na equipe são idênticas.
Há duas maneiras a fim ajustar e verificar configurações MTU. O primeiro é através dos ajustes do adaptador de rede. A segunda maneira é usar Powershell. Está aqui um exemplo que ilustre o uso de Powershell a fim obter ao mesmo tempo e ajustar a configuração MTU:
PS C:\Program Files (x86)\cisco\Nexus1000V>
Get-NetAdapterAdvancedProperty -RegistryKeyword
*jumbo* -Name ? <adapter name>" | Set-NetAdapterAdvancedProperty
-RegistryValue <mtu value>
A configuração nova não trabalha devido configuração velha/velha N1KV
Você pôde encontrar uma edição onde houvesse uma configuração velha N1KV no host hyper-v que não permite que seja adicionada à configuração nova. Geralmente quando você suprime do N1KV velho de SCVMM ou do gerente hyper-v, limpa a configuração. Contudo, pôde haver um caso onde você devesse verificar e suprimir da configuração velha N1KV do registro hyper-v do host.
Inscreva o comando regedit, e suprima da configuração N1KV neste lugar:
HKEY_LOCAL_MACHINE\SYSTEM > CurrentControlSet > Services > VMSMP >
Parameters >SwitchList
Depois que você suprime da entrada de registro, limpe através do gerente hyper-v e recarregue.
Os direcionadores exigidos não são erro encontrado
Você pôde receber um erro que os direcionadores ou o MSI exigido não fossem encontrados quando você tenta adicionar um host hyper-v ao N1KV. Está aqui uma amostra do erro do indicador dos trabalhos:
Isto significa geralmente que o código N1KV VEM não existe no server SCVMM. O server SCVMM deve verificar a extensão que é instalada no host hyper-v. Mesmo se o código VEM é instalado já no host hyper-v, o instalador N1KV VEM deve ser copiado a um diretório no server SCVMM.
Verifique que o instalador N1KV VEM está copiado aos direcionadores da extensão de C:\ProgramData\Switch no server SCVMM. Se não existe, a seguir copia o arquivo ao diretório, e adiciona o host hyper-v ao N1KV.
Neste caso, tudo parece trabalhar em SCVMM, mas o módulo nunca aparece no VS. É raro que este acontece com hyper-v, desde que a configuração é tão simples. Quando acontece, há poucas coisas simples a tentar.
Reinicie o processo N1KV no host hyper-v
Use o gerenciador de tarefa ou os serviços a fim reiniciar o processo N1KV no host hyper-v que apresenta o problema.
Está aqui um tiro de tela do serviço N1KV no gerenciador de tarefa - clicar-lo com o botão direito, e selecione-o o reinício:
A equipe VEM não é criada corretamente
Quando você cria o interruptor lógico em SCVMM, você pode não escolher nenhuma equipe ou equipe. Com o N1KV, você deve sempre escolher a equipe, mesmo se você tem somente um NIC anexado.
Está aqui um tiro de tela que ilustre onde ajustar o ajuste da equipe para o interruptor lógico:
Hyper-v é muito capaz a este respeito; se vê que os VM estão ligados, e que a administração emitiu uma repartição, pausa o estado dos VM e das repartições. Quando o sistema volta em linha, tenta trazer para trás os VM em linha o mais cedo possível. Isto supõe que você vivo-não migrou todos os VM fora do host antes da repartição.
O problema é que hyper-v traz aos VM para trás em linha antes que o processo VEM comece realmente. A ação alternativa é ajustar os VM com um atraso do arranque automático. A engenharia recomenda que um trigésimo segundo atraso está usado a fim permitir que o VEM e o VS se comuniquem antes que as tentativas hyper-v a recomeçar/liguem todos os VM.
Quando você tenta criar ou mover um VM para o N1KV, ou vivo-migrar um VM de um host a outro, você pôde receber este erro:
Este é um mensagem de advertência mais do que e erro. Mesmo que apareça como um erro na tela do trabalho, não indica que algo é severamente quebrado. A edição é que SCVMM tenta manter um estado complacente entre se, o VS, e o VEM. Por qualquer motivo, SCVMM pensa ocasionalmente que o estado é fora da sincronização, e determina que hospeda com certeza o N1KV é NON-complacente. A conformidade dos host individuais é monitorada sob a tela > switch> lógico lógico do <your N1KV do switches>.
Clique os anfitriões abotoam-se na fita na parte superior da tela:
Se o host é NON-complacente, a seguir você deve tentar ao remediate o host. Selecione o host que é fora da conformidade, e clique sobre o botão de Remediate na parte superior da tela. Isto provoca SCVMM à sincronização os dados entre se, o VS, e o módulo VEM. Após alguns minutos, as mudanças de estado a complacente, e você não consideram nenhuns erros.
Esta seção descreve diversos edições e comandos úteis variados para N1KV em hyper-v.
Você não pode atualmente executado o VS em um host hyper-v aninhado. Ao contrário de ESXi, por qualquer motivo o VS não pode ser executado em um host hyper-v virtual. A engenharia está ciente da edição, mas é de baixa prioridade neste momento, esteja assim ciente dessa limitação. Contudo, você pode executar o VS em um host aninhado de ESXi, de modo que seja uma alternativa possível.
VMQ é quase idêntico à fila do dispositivo da máquina virtual de VMware (VMDQ). VMQ exige que o NIC físico apoia VMQ. O NIC cria uma fila da rede para cada VM no sistema, que permite que o tráfego de rede flua diretamente do hypervisor ao VM. Isto melhora o desempenho da rede para os VM.
Comandos de Powershell usados para verificar VMQ
Há dois comandos úteis usados a fim verificar para ver se há a informação VMQ com Powershell no host hyper-v:
Uso de comandos de Vemcmd a fim verificar VMQ
Este é o Exibir informação usado comando primary sobre VETHs para que as filas foram atribuídas:
>vemcmd show vmq allocation
LTL VSM Port Phy LTL Queue id Team queue id
49 Veth13 17 1 49
18 2 49
50 Veth14 17 2 50
18 3 50
51 Veth16 19 1 51
20 1 51
Este comando indica a informação sobre NIC físicos VMQ-permitidos:
>vemcmd show vmq resources
LTL VSM Port Max queues Free queues
17 Eth3/1 16 10
18 Eth3/2 16 10
19 Eth3/3 8 7
Há diversos comandos de Powershell que puxam ou introduzem dados no VS. Isto permite que você passe pelo processo de script a instalação e a orquestração dos VM ao N1KV. Igualmente permite que você puxe mais informação detalhada que mostra relacionamentos entre objetos SCVMM e N1KV.
Use Powershell de SCVMM
Você deve assegurar-se de que você use um Powershell que tenha os encaixes SCVMM. A maneira a mais fácil de realizar isto é lançar Powershell do console SCVMM:
O comando GET-SCPortClassification
Este comando é usado a fim ver o link entre uma porta-classificação SCVMM e o porta-perfil N1KV a que é ligado:
PS C:\Users\Administrator.HYPERV> Get-SCPortClassification
Name : NexusNoRestrict-2
Description :
ServerConnection : Microsoft.SystemCenter.VirtualMachineManager.
Remoting.ServerConnection
ID : 9f8819c1-8b53-42bd-a6fd-0173804e3194
IsViewOnly : False
ObjectType : PortClassification
MarkedForDeletion : False
IsFullyCached : True
O comando GET-SCVirtualNetworkAdapterExtensionPortProfile
Este comando é usado a fim ver a informação sobre o porta-perfil do uplink:
PS C:\Users\Administrator.HYPERV> Get-SCVirtualNetworkAdapterExtensionPortProfile
Name : NoRest-unicast-norest
ExternalId : 308ad66b-7c42-4067-90af-13f7a6e59afe
NetworkEntityAccessType : ExternallyManaged
VirtualSwitchExtension : n1kv-test
Tags : {}
AllowedVNicType : Both
MaxNumberOfPorts : 32
MaxNumberOfPortsPerHost : 216
ProfileData : 0
ServerConnection : Microsoft.SystemCenter.VirtualMachineManager.
Remoting.ServerConnection
ID : 8934a01c-0cb7-4ee2-ae9d-21ff5b26568f
IsViewOnly : False
ObjectType : VirtualSwitchExtensionVirtualPortProfile
MarkedForDeletion : False
IsFullyCached : True
O comando GET-SCConfigurationProvider
Este comando é usado a fim ver a informação sobre os Ramais do fornecedor carregados no server SCVMM:
PS C:\Users\Administrator.HYPERV> Get-SCConfigurationProvider
Name : Cisco Systems Nexus 1000V
Type : VirtualSwitchExtensionManager
Description : Provider for Cisco Systems Nexus 1000V
Virtual Switch Extension Manager
LatestVersion : 1.0
PublishDate :
Publisher : Cisco Systems, Inc.
Manufacturer : Cisco Systems, Inc.
Model : {Nexus 1000V}
Error :
ServerConnection : Microsoft.SystemCenter.VirtualMachineManager.
Remoting.ServerConnection
ID : 22a8f431-b5fe-4ee8-a0f5-9b5a99f723f2
IsViewOnly : False
ObjectType : ConfigurationProvider
MarkedForDeletion : False
IsFullyCached : True
Os comandos VEM estão disponíveis no C: > arquivos de programa (x86) > Cisco > Nexus1000V.
A fim verificar a Conectividade física do adatper ao N1KV no registro, alcance este lugar do registro:
Você pôde encontrar esta edição se você executou moldes e construiu VM com o aplicativo do molde do serviço SCVMM, e usuários permitidos do autosserviço para criar seus próprios VM. Este molde provisório não é um objeto do visualizável com SCVMM. Você deve usar o SCVMM Powershell a fim suprimir do molde provisório com este comando:
Get-SCVMTemplate | where {$_.Name -like "Temporary*"} | Remove-SCVMTemplate
Às vezes os erros da conformidade são apenas uma função da maneira que SCVMM se opera. O N1KV pôde ser inteiramente complacente em SCVMM, mas você ainda recebe erros da conformidade.
Você pôde igualmente receber esta mensagem, onde não é permitido você escolher ou alterar nenhuma configurações de rede para um VM:
Isto ocorre quando um dos Nós do conjunto MS tem problemas. SCVMM descobre que todos os Nós não estão na conformidade, e não permite que você faça mudanças até que você remova ou fixe o nó com o problema. Este é comportamento esperado em SCVMM.
A fim determinar que nó tem os problemas, use SCVMM ou aglomere o gerente do Failover, e fixe o nó do problema. Se você não pode fixar o nó, a seguir você deve remover ou pausar ele do conjunto. Uma vez que isso está completo, você tem a capacidade para adicionar e alterar VM ao N1KV.