Este documento describe los procedimientos utilizados para resolver problemas de switches Nexus de Cisco serie 1000V (N1KV) en servidores Microsoft (MS) Hyper-V. La implementación en Hyper-V es muy diferente a la de ESXi, por lo que habrá algunos problemas frecuentes; así, se creó este documento.
Gran parte de la información descrita en este documento proviene directamente de la Introducción de nuevos productos de ingeniería (NPI, Engineering New Product Introduction) y de problemas encontrados durante las pruebas beta. Este documento es de naturaleza dinámica y se actualizará en consecuencia.
Cisco recomienda que tenga conocimiento sobre estos temas:
Este documento no tiene restricciones específicas en cuanto a versiones de software y de hardware.
The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.
Hay muchos problemas con la aplicación Installer, y en esta sección se describen los más comunes.
Estas son algunas de las razones por las que debe utilizar esta aplicación con precaución:
La aplicación Installer sólo está diseñada para funcionar en entornos de campo nuevo. No intente utilizar la aplicación en una configuración previamente establecida. Para verificar si el instalador falla, navegue a C: > Usuarios > <username> > AppData > Local > Temp > 2 > Nexus1000vInstaller_xxxxxxx.txt, y verifique el registro.
El comportamiento predeterminado (y único) de la aplicación Installer es mostrar y utilizar la NIC física a la que está conectada la interfaz de administración. Cuando ejecuta la aplicación Installer, sólo puede elegir una NIC: la NIC de administración.
La aplicación Instalador:
Esta imagen ilustra cómo uno de los hosts ahora tiene asignado un switch lógico MS y una NIC virtual que transporta el tráfico de administración:
Puede ver que el link ascendente se define con No Uplink Team cuando ve el switch lógico que se crea. Este es un problema porque no puede agregar otra NIC o una NIC agrupada a este switch. No se le permite cambiar el tipo de Equipo una vez que se crea el switch. Además, la Aplicación del instalador no permite agregar una interfaz de equipo.
Para cambiar el switch al equipo, debe quitarlo y agregarlo de nuevo con un conjunto de equipos. Esto es posible, pero tedioso. Desea redundancia, por lo que si no se agrupa, existe un problema potencial.
Este es otro problema porque los VSM están vinculados a estos dos hosts solamente. Por lo tanto, la migración en directo y Cisco Home-Agent (HA) se limitan a dos hosts. Tiene la opción de migrar los otros hosts Hyper-V al switch lógico MS que se crea, pero la aplicación Installer no lo completa automáticamente.
Cuando se crea la configuración de la máquina virtual VSM (VM), la disponibilidad tiene un valor de Baja. MS sólo permite que las VM con valores de disponibilidad de High se incluyan en el almacenamiento basado en clúster. Esto coloca la información de VSM Virtual Disk (VD) y VM en el almacenamiento local del host Hyper-V. De nuevo, esto limita la migración en tiempo real y la HA para las VM VSM.
La aplicación Installer crea una configuración muy básica en el VSM e importa parte de esa configuración a System Center Virtual Machine Manager (SCVMM).
La aplicación realiza estas acciones desde el lado N1KV:
La aplicación no solo crea estos ajustes en el VSM, sino que rellena esta información en SCVMM cuando crea el switch lógico.
La aplicación funciona bien en el aspecto de la configuración, pero tiene problemas con la red de enlace ascendente. Así es como se crea el link ascendente de la red:
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
Hay un link ascendente de la red del sistema, que causa un problema. Si tiene un link ascendente con el conjunto de link ascendente de red del sistema, entonces todos los segmentos de red y perfiles de puerto que utilizan ese link ascendente deben ser también del sistema. Esto significa que está limitado a 32 segmentos de red que pueden utilizar ese enlace ascendente.
No está claro que esto sea un problema, pero mostremos un ejemplo de lo que sucede si crea un nuevo segmento de red y una plantilla de grupo IP 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)#
Actualice la extensión SCVMM N1KV y agregue la red VM para el segmento de red que creó. Cuando intenta asignar una VM a la nueva red VM, se obtienen estos errores:
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
Estos errores se deben a que el link ascendente de la red transporta una red del sistema y el segmento de red no. Tiene dos opciones: cree un nuevo enlace ascendente de red sin una red del sistema o agregue una red del sistema al nuevo segmento de red.
La conectividad entre VSM y SCVMM es diferente con Hyper-V que con ESXi. En la solución Hyper-V, SCVMM habla con nuestra API (Nexus 1000V). Esto significa que la conexión se establece y se mantiene desde el host SCVMM. Cuando el comando show svs connection se utiliza en el VSM, no muestra nada; no hay conexión SVS en esta solución.
SCVMM también sondea el VSM una vez cada treinta minutos. Esto significa que debe forzar una actualización si desea que los cambios del VSM aparezcan en SCVMM inmediatamente.
El proveedor para Hyper-V es similar al complemento para N1KV en ESXi. La diferencia es que no hay un proveedor único para cada VSM. Sólo necesita ejecutar la instalación del proveedor una vez. Esto rellena SCVMM con la información necesaria para entender cómo comunicarse con el VSM.
El proveedor no es específico para cada VSM. El proveedor está registrado en el Registro de Windows. Puede buscar VSEM en el Registro o desplazarse a esta ubicación:
Si se encuentra en una posición en la que no puede eliminar el proveedor, puede eliminar la entrada en el Registro y reiniciar el servicio SCVMM.
Anote la ubicación del módulo en la entrada del Registro. El proveedor Dynamic Loadable Library (DLL) debe instalarse en c:\Program Files\Cisco\Nexus1000V, junto con un script powershell que se utiliza para instalar el proveedor. Asegúrese de que el archivo DLL esté presente.
La desinstalación del proveedor se realiza mediante la desinstalación del programa desde el panel de control Hyper-V Server 2012. Para reinstalar el proveedor, haga doble clic en el instalador del proveedor.
Asegúrese de que la extensión del proveedor está activa y cumple con la normativa en SCVMM. Vaya a Settings > Configuration Providers. Verifique que la extensión Cisco Systems Nexus 1000V esté activa. Esto significa que SCVMM utiliza la extensión.
SCVMM se comunica con el VSM, por lo que debe resolver problemas desde el host SCVMM.
Compruebe que:
Si no puede hacer ping al VSM, verifique los firewalls de Windows y verifique si hay problemas de conectividad de red. No se requiere que VSM y SCVMM estén en la misma subred.
Para verificar la API, utilice Internet Explorer (IE) y busque la API REST de VSM con esta cadena: http://<vsm-ip>/api/n1kv.
Debería recibir este resultado:
Si no puede alcanzar la API, verifique que:
N1KV en Hyper-V utiliza sólo el control L3. No hay forma de controlar Hyper-V con control L2. El control L3 de configuración en Hyper-V es mucho más fácil que una configuración similar en VMware. No hay necesidad de dedicar una NIC al VEM; el VSM se comunica directamente con la NIC de administración de Hyper-V Server 2012. No se requiere que la NIC de administración se conecte al módulo VEM, lo que significa que no necesita un veth port-profile especial para el control L3.
La instalación del VEM también es mucho más fácil. No hay ningún componente de VMware Update Manager (VUM) con SCVMM. La capacidad de instalar componentes de extensión está integrada directamente en SCVMM. Si el VEM no está instalado en el host Hyper-V, SCVMM copia e instala el VEM en el host Hyper-V de destino automáticamente. Si desea instalar manualmente el VEM, se trata de un simple doble clic de la aplicación del instalador VEM en el host. La desinstalación también es un programa sencillo que se quita del Panel de control.
Un error común que puede encontrar es que un host Hyper-V no se agrega al N1KV a través de SCVMM. Hay varias verificaciones que se deben realizar para resolver este problema.
Este es un error típico que puede ver en SCVMM cuando falla la instalación de VEM:
Compruebe si hay equipos de red antiguos en el host Hyper-V
Puede haber un equipo antiguo de otro N1KV en el host Hyper-V. Si es así, debe eliminar el equipo antiguo antes de agregar el host al N1KV. En el host Hyper-V, ejecute PowerShell e ingrese el comando Get-NetSwitchTeam. Si aparece un equipo antiguo, debe quitarlo con el comando Remove-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
La unidad máxima de transmisión (MTU) de las NIC y el N1KV no coinciden
La configuración de MTU en Hyper-V se establece por NIC a través de la configuración de NIC. Cuando crea un equipo, MS exige que la configuración de MTU de todas las NIC del equipo sea idéntica.
Hay dos maneras de configurar y verificar la configuración de MTU. La primera es a través de los parámetros del adaptador de red. La segunda forma es usar Powershell. Este es un ejemplo que ilustra el uso de Powershell para obtener y configurar la configuración de MTU al mismo tiempo:
PS C:\Program Files (x86)\cisco\Nexus1000V>
Get-NetAdapterAdvancedProperty -RegistryKeyword
*jumbo* -Name ?" | Set-NetAdapterAdvancedProperty
-RegistryValue
La nueva configuración no funciona debido a la configuración N1KV antigua/antigua
Es posible que se encuentre un problema en el que hay una configuración N1KV obsoleta en el host Hyper-V que no permite agregarla a la nueva configuración. Normalmente, cuando elimina el N1KV antiguo de SCVMM o Hyper-V Manager, limpia la configuración. Sin embargo, puede haber un caso en el que deba verificar y eliminar la configuración N1KV antigua del registro host de Hyper-V.
Ingrese el comando Regedit y elimine la configuración N1KV en esta ubicación:
HKEY_LOCAL_MACHINE\SYSTEM > CurrentControlSet > Services > VMSMP >
Parameters >SwitchList
Después de eliminar la entrada del Registro, limpie a través del Administrador de Hyper-V y reinicie.
Error No se han encontrado los controladores necesarios
Puede que reciba un error que indica que no se encuentran los controladores necesarios o MSI cuando intenta agregar un host Hyper-V al N1KV. A continuación se muestra un ejemplo del error de la ventana Trabajos:
Esto significa generalmente que el código VEM N1KV no existe en el servidor SCVMM. El servidor SCVMM debe verificar la extensión instalada en el host Hyper-V. Incluso si el código VEM ya está instalado en el host Hyper-V, el instalador VEM N1KV debe copiarse en un directorio del servidor SCVMM.
Verifique que el instalador de VEM N1KV se copie en C:\ProgramData\Switch Extension Drivers en el servidor SCVMM. Si no existe, copie el archivo en el directorio y agregue el host Hyper-V al N1KV.
En este caso, todo parece funcionar en SCVMM, pero el módulo nunca aparece en el VSM . Es raro que esto ocurra con Hyper-V, ya que la configuración es tan simple. Cuando ocurre, hay pocas cosas simples que intentar.
Reinicie el proceso N1KV en el host Hyper-V
Utilice el Administrador de tareas o Servicios para reiniciar el proceso N1KV en el host Hyper-V que presenta el problema.
Esta es una captura de pantalla del servicio N1KV en el Administrador de tareas: haga clic con el botón derecho del ratón y seleccione Reiniciar:
El equipo de VEM no se ha creado correctamente
Cuando crea el switch lógico en SCVMM, puede elegir No Team o Team. Con el N1KV, siempre debe elegir Team, incluso si sólo tiene una NIC conectada.
Esta es una captura de pantalla que ilustra dónde establecer la configuración de Equipo para el switch lógico:
Hyper-V es muy capaz en este sentido; si observa que las VM están encendidas y que Administration ha iniciado un reinicio, hace una pausa en el estado de las VM y se reinicia. Cuando el sistema vuelve a estar en línea, intenta volver a conectar las VM lo antes posible. Esto supone que no realizó la migración en vivo de todas las VM fuera del host antes del reinicio.
El problema es que Hyper-V vuelve a conectar las VM antes de que el proceso de VEM realmente comience. La solución alternativa es establecer las VM con un retardo de inicio automático. Engineering recomienda que se utilice un retardo de treinta segundos para permitir que VEM y VSM se comuniquen antes de que Hyper-V intente reanudar/encender todas las VM.
Cuando intente crear o mover una VM al N1KV o migrar en vivo una VM de un host a otro, es posible que reciba este error:
Este es un mensaje de advertencia más que y error. Aunque aparece como un error en la pantalla de trabajo, no indica que algo esté gravemente dañado. El problema es que SCVMM intenta mantener un estado de conformidad entre sí, el VSM y el VEM. Por alguna razón, SCVMM ocasionalmente piensa que el estado no está sincronizado y determina que para ciertos hosts el N1KV no cumple con la normativa. El cumplimiento de los hosts individuales se monitorea bajo Fabric > Logical switches> <su switch lógico N1KV>.
Haga clic en el botón Hosts en la cinta de la parte superior de la pantalla:
Si el host no cumple con la normativa, debe intentar remediar el host. Seleccione el host que se encuentra fuera de conformidad y haga clic en el botón Remediar de la parte superior de la pantalla. Esto hace que SCVMM sincronice los datos entre sí, el VSM y el módulo VEM. Después de unos minutos, el estado cambia a Conforme, y usted no ve ningún error.
Esta sección describe varios problemas varios y comandos útiles para N1KV en Hyper-V.
Actualmente no puede ejecutar el VSM en un host Hyper-V anidado. A diferencia de ESXi, por alguna razón el VSM no puede ejecutarse en un host virtual Hyper-V. La ingeniería es consciente del problema, pero en este momento es de baja prioridad, así que tenga en cuenta esa restricción. Sin embargo, puede ejecutar el VSM en un host ESXi anidado, por lo que es una solución alternativa posible.
VMQ es casi idéntico a la cola de dispositivos de máquina virtual VMware (VMDQ). VMQ requiere que la NIC física admita VMQ. La NIC crea una cola de red para cada VM del sistema, lo que permite que el tráfico de red fluya directamente desde el hipervisor a la VM. Esto mejora el rendimiento de la red para las VM.
Comandos Powershell Utilizados para Verificar VMQ
Hay dos comandos útiles usados para verificar la información VMQ a través de Powershell en el host Hyper-V:
Uso de Comandos Vemcmd para Verificar VMQ
Este es el comando primario utilizado para mostrar información sobre VETHs para los cuales se han asignado colas:
>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 muestra información sobre las NIC físicas habilitadas para VMQ:
>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
Hay varios comandos PowerShell que extraen o envían datos al VSM. Esto le permite secuenciar la instalación y orquestación de máquinas virtuales al N1KV. También le permite obtener información más detallada que muestra las relaciones entre los objetos SCVMM y N1KV.
Utilizar PowerShell de SCVMM
Debe asegurarse de utilizar un PowerShell que tenga los complementos SCVMM. La forma más sencilla de lograrlo es iniciar PowerShell desde la consola SCVMM:
Get-SCPortSort Comando
Este comando se utiliza para ver el link entre una clasificación de puerto SCVMM y el perfil de puerto N1KV al que está enlazado:
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
El Get-SCVirtualNetworkAdapterExtensionPortProfile Comando
Este comando se utiliza para ver información sobre el perfil de puerto de link ascendente:
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
El comando Get-SCConfigurationProvider
Este comando se utiliza para ver información sobre las Extensiones de Proveedor cargadas en el servidor 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
Los comandos VEM están disponibles en C: > Archivos de programa (x86) > Cisco > Nexus1000V.
Para verificar la conectividad del adaptador físico al N1KV en el registro, acceda a esta ubicación del registro:
Puede que se encuentre con este problema si implementa plantillas y genera VM a través de la aplicación Plantilla de servicio de SCVMM, y permite a los usuarios de autoservicio crear sus propias VM. Esta plantilla temporal no es un objeto visible a través de SCVMM. Debe utilizar el PowerShell de SCVMM para eliminar la plantilla temporal con este comando:
Get-SCVMTemplate | where {$_.Name -like "Temporary*"} | Remove-SCVMTemplate
A veces, los errores de conformidad son sólo una función del funcionamiento de SCVMM. Es posible que el N1KV sea totalmente compatible con SCVMM, pero aún así recibe errores de conformidad.
También puede recibir este mensaje, donde no se le permite elegir o modificar ninguna configuración de red para una VM:
Esto ocurre cuando uno de los nodos del clúster de MS tiene problemas. SCVMM descubre que todos los nodos no cumplen con la normativa y no le permite realizar cambios hasta que elimine o corrija el nodo con el problema. Este es el comportamiento esperado en SCVMM.
Para determinar qué nodo tiene los problemas, utilice SCVMM o Cluster Failover Manager y corrija el nodo de problema. Si no puede reparar el nodo, debe quitarlo o hacer una pausa en el clúster. Una vez que se haya completado, podrá agregar y modificar máquinas virtuales al N1KV.
Revisión | Fecha de publicación | Comentarios |
---|---|---|
1.0 |
01-Oct-2013 |
Versión inicial |