Os nexos 1000V em hyper-v pesquisam defeitos o guia
Índice
Introdução
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.
Pré-requisitos
Requisitos
A Cisco recomenda que você tenha conhecimento destes tópicos:
- Series Switch N1KV
- Server hyper-v MS
Componentes Utilizados
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.
Edições do aplicativo de instalador
Há muitas edições com o applicaton do instalador, e esta seção descreve as mais comuns.
Use o aplicativo de instalador com cuidado
Estão aqui os alguns motivos pelas quais você deve usar este aplicativo com cuidado:
- Não espera o suficiente pelo módulo do supervisor virtual (VS) para começar em muitas Plataformas, e falha frequentemente.
- Move a relação do Gerenciamento (mgmt) para um interruptor lógico MS e não o informa, mesmo que você não possa querer a relação do mgmt movida.
- O interruptor lógico que é criado não pode usar uma relação teamed. Isto significa que não há nenhuma Redundância para o interruptor ou a relação do mgmt.
- Você não pode simplesmente adicionar um outro Network Interface Cards (NIC) ao interruptor lógico a fim fazê-lo teamed; você deve criar um interruptor novo com uma relação teamed, e o movimento tudo sobre a fim ter a Redundância.
- O aplicativo não reconhece se os anfitriões que você instala os VS sobre são parte de um conjunto. Isto significa que os discos virtuais estão instalados no armazenamento local, não armazenamento do conjunto.
- O aplicativo cria um uplink da rede com um grupo da rede de sistema. Cada segmento de rede deve ter uma rede de sistema ajustada. Este é um erro principal, esteja assim ciente dele.
Lugar do log do aplicativo de instalador
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 aplicativo de instalador migra Mgmt NIC
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:
- Cria um interruptor lógico MS
- Adiciona os dois anfitriões que têm os VS ao interruptor lógico
- Migra o mgmt NIC a um nNIC virtual no interruptor lógico
- Adiciona as conexões de rede VS a esse interruptor lógico
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.
O interruptor lógico para Mgmt e o VS não é criado em todo o Switches
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.
O aplicativo de instalador não utiliza o armazenamento Conjunto-baseado
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.
Edições com a configuração VS que o aplicativo de instalador cria
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:
- Cria uma rede lógica do padrão
- Cria um pool do segmento da rede padrão
- Cria uma rede do uplink do padrão
- Cria um porta-perfil do eth do padrão com fixar do Mac do grupo de canais
- Cria um porta-perfil do veth do padrão para a nenhum-limitação
- Cria um molde do pool do IP padrão
- Cria o interruptor lógico N1KV em SCVMM
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.
SCVMM não pode conectar ao VS
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.
Verifique que o fornecedor está instalado
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.
Desinstale/reinstale o fornecedor com o Control Panel
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.
Verifique a conformidade da extensão
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.
Verifique a Conectividade entre o VS e o SCVMM
SCVMM fala ao VS, assim que você deve pesquisar defeitos do host SCVMM.
Verifique se:
- Você pode sibilar o VS do host SCVMM.
- Você pode consultar através de um navegador da Web à interface de programação de aplicativo N1KV (API).
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:
- Não há nenhum proxy do Internet configurado no host SCVMM. SCVMM herda proxys se é definido no IE. Verifique os ajustes do Internet no IE a fim verificar que um proxy está definido. Você pôde ser exigido adicionar uma exceção para o VS.
- O web server e o API são acessíveis no VS. Verifique que o HTTP-server está permitido no VS, e se algum Firewall é permitido que obstruir o tráfego da porta 80.
Edições virtuais do módulo de Ethernet (VEM)
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.
O host hyper-v não instala a N1KV
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.
O módulo VEM não aparece no VS
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:
Todas as portas VETH são para baixo após uma Host-repartição
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.
Incapaz de encontrar o erro complacente do interruptor
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.
Outros edições e comandos úteis
Esta seção descreve diversos edições e comandos úteis variados para N1KV em hyper-v.
O VS não pode ser aninhado 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.
Enfileiramento da máquina virtual (VMQ)
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:
- GET-NetAdapterVmq
- GET-NetAdapterVmqQueue
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
Uso de Vemcmd a fim ver recursos VMQ
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
Comandos úteis de PowerShell
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
Lugar de Vemcmd e de Vemlog
Os comandos VEM estão disponíveis no C: > arquivos de programa (x86) > Cisco > Nexus1000V.
Verifique o inventário do adaptador físico com o registro
A fim verificar a Conectividade física do adatper ao N1KV no registro, alcance este lugar do registro:
- Seção de registro: HKEY_LOCAL_MACHINE > SISTEMA > CurrentControlSet
- Chave de registro: Serviços > Nexus1000V > parâmetros > HostPhyAdapters
Não pode suprimir dos objetos N1KV devido ao molde provisório
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
Os VM atribuídos a N1KV recebem erros lógicos da conformidade do interruptor
À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.
FeedbackDeixe-nos ajudar
- Abrir um caso de suporte
- (É necessário um Contrato de Serviço da Cisco)