Nexo 1000V en la guía híper-v del Troubleshooting
Contenido
Introducción
Este documento describe los procedimientos usados para resolver problemas los switches de la serie del nexo 1000V (N1KV) de Cisco en los servidores híperes-v de Microsoft (MS). La implementación en híper-v es mucho diferente que en ESXi, tan habrá algo los problemas frecuente-encontrados; así, este documento fue creado.
Mucha de la información descrita en este documento viene directamente de la introducción de producto nuevo de la ingeniería (NPI), y de los problemas encontrados durante la prueba beta. Este documento es dinámico en la naturaleza, y será puesto al día por consiguiente.
Prerrequisitos
Requisitos
Cisco recomienda que tenga conocimiento sobre estos temas:
- Switches de la serie N1KV
- Servidores híperes-v MS
Componentes Utilizados
Este documento no tiene restricciones específicas en cuanto a versiones de software y de hardware.
La información que contiene este documento se creó a partir de los dispositivos en un ambiente de laboratorio específico. Todos los dispositivos que se utilizan en este documento se pusieron en funcionamiento con una configuración verificada (predeterminada). Si la red está funcionando, asegúrese de haber comprendido el impacto que puede tener cualquier comando.
Problemas de la aplicación de instalación
Hay muchos problemas con el applicaton del instalador, y esta sección describe los mas comunes.
Utilice la aplicación de instalación con cautela
Aquí están algunas razones por las que usted debe utilizar esta aplicación con cautela:
- No espera bastante tiempo el módulo de Supervisor virtual (VS) para comenzar en muchas Plataformas, y falla a menudo.
- Mueve la interfaz de la Administración (mgmt) a un Switch lógico MS y no le informa, aunque usted puede ser que no quiera la interfaz del mgmt movida.
- El Switch lógico se crea que no puede utilizar una interfaz combinada. Esto significa que no hay Redundancia para el Switch o la interfaz del mgmt.
- Usted no puede agregar simplemente otro Network Interface Cards (NIC) al Switch lógico para hacerlo combinado; usted debe crear un nuevo Switch con una interfaz combinada, y el movimiento todo encima para tener Redundancia.
- La aplicación no reconoce si los host que usted instala los VS encendido son parte de al cluster. Esto significa que los discos virtuales están instalados en el almacenamiento local, no almacenamiento del cluster.
- La aplicación crea un uplink de la red con un conjunto de la red del sistema. Cada segmento de red debe tener una red del sistema fijada. Esto es un bug importante, sea tan consciente de él.
Ubicación del registro de la aplicación de instalación
El applicaton del instalador se significa solamente para trabajar en los entornos de la pradera. No intente utilizar la aplicación en una configuración anterior-establecida. Para verificar si los errores-hacia fuera del instalador, navegan al C: > Users > el <username> > AppData > el Local > los temporeros > 2 > Nexus1000vInstaller_xxxxxxxx.txt, y marcan el registro.
La aplicación de instalación emigra el mgmt NIC
(Y solamente) el comportamiento predeterminado de la aplicación de instalación es visualizar y utilizar el NIC físico con el cual la interfaz del mgmt está conectada. Cuando usted ejecuta la aplicación de instalación, usted puede solamente elegir un NIC - el mgmt NIC.
La aplicación de instalación:
- Crea un Switch lógico MS
- Agrega los dos host que tienen los VS al Switch lógico
- Emigra el mgmt NIC a un nNIC virtual en el Switch lógico
- Agrega las conexiones de red VS a ese Switch lógico
Esta imagen ilustra cómo uno de los host ahora tiene un Switch lógico MS asignado, y un NIC virtual que lleve el tráfico del mgmt:
Usted puede ver que el uplink está definido sin el equipo del uplink cuando usted ve el Switch lógico se crea que. Esto es un problema porque usted no puede agregar otro NIC o un NIC combinado a este Switch. A le no se permite cambiar el tipo de equipo una vez que se crea el Switch. También, la aplicación de instalación no permite que usted agregue una interfaz combinada.
Para cambiar el Switch a combinado, usted debe quitarlo y agregarlo detrás con un teaming fijado. Esto es posible, pero aburrido. Usted quiere la Redundancia, así que si no se combina, después allí es un problema potencial.
El Switch lógico para el mgmt y el VS no se crea en todo el Switches
Éste es otro problema porque los VS se atan solamente a estos dos host. Así pues, la migración viva y el Home Agent de Cisco (HA) se limitan a dos host. Usted tiene la opción para emigrar los otros host híperes-v al Switch lógico MS se crea que, pero no es completado automáticamente por la aplicación de instalación.
La aplicación de instalación no utiliza el almacenamiento Cluster-basado
Cuando se crean las configuraciones de la máquina virtual VS (VM), la Disponibilidad tiene un valor del punto bajo. El MS permite solamente que los VM con la Disponibilidad de los valores del alto sean incluidos en el almacenamiento Cluster-Basar. Esto pone el disco virtual VS (VD) y la información VM en el almacenamiento local del host híper-v. Una vez más esto limita la vivo-migración y el HA para el VS VM.
Problemas con la configuración VS que la aplicación de instalación crea
La aplicación de instalación crea mismo una configuración básica en el VS, e importa algo de esa configuración al administrador de la máquina virtual de System Center (SCVMM).
La aplicación realiza estas acciones del lado N1KV:
- Crea una red lógica predeterminada
- Crea un pool del segmento de la red predeterminada
- Crea una red predeterminada del uplink
- Crea un puerto-perfil predeterminado del eth con la fijación del mac del grupo de canal
- Crea un puerto-perfil predeterminado del veth para la ninguno-restricción
- Crea una plantilla del pool del IP predeterminado
- Crea el Switch lógico N1KV en SCVMM
La aplicación no sólo crea estas configuraciones en el VS, pero puebla esta información en SCVMM cuando crea el Switch lógico.
La aplicación hace bien en la configuración de aspecto, pero tiene problemas con la red del uplink. Éste es cómo se crea el uplink 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 uplink de la red del sistema, que causa un problema. Si usted tiene un uplink con el uplink de la red del sistema fijado, después todos los segmentos de red y puerto-perfiles que utilizan ese uplink deben ser sistema también. Esto significa que le limitan a 32 segmentos de red que puedan utilizar ese uplink.
No está claro que esto es un problema, pero nos dejó mostrar un ejemplo de qué sucede si usted construye un nuevos segmento de red y plantilla de la agrupación IP para el VLA N 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)#
Restaure la extensión SCVMM N1KV, y agregue la red VM para el segmento de red que usted creó. Cuando usted intenta asignar un VM a la nueva red VM, usted consigue 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
Se causan estos errores porque el uplink de la red lleva una red del sistema y no lo hace el segmento de red. Usted tiene dos opciones: cree un nuevo uplink de la red sin una red del sistema, o agregue una red del sistema a su nuevo segmento de red.
SCVMM no puede conectar con el VS
La Conectividad entre el VS y el SCVMM es diferente con híper-v que con ESXi. En la solución híper-v, SCVMM habla con nuestro (nexo 1000V) API. Esto significa que la conexión está establecida y mantenida del host SCVMM. Cuando utilizan al comando connection SVS de la demostración en el VS, no muestra nada; no hay conexión SV en esta solución.
SCVMM también sondea el VS una vez cada treinta minutos. Esto significa que usted debe forzar una restauración si usted quiere ver los cambios del VS aparecer en SCVMM inmediatamente.
Verifique que el proveedor esté instalado
El proveedor para híper-v es similar al plug-in para N1KV en ESXi. La diferencia es que no hay proveedor único para cada VS. Usted necesita solamente funcionar con el proveedor instala una vez. Esto puebla SCVMM con la información que es necesaria para entender cómo hablar con el VS.
El proveedor no es específico a cada VS. El proveedor se registra en el registro de Windows. Usted puede buscar para VSEM en el registro, o navegue a esta ubicación:
Si usted es en una posición donde usted no puede borrar el proveedor, después usted puede borrar la entrada en el registro y recomenzar el servicio SCVMM.
Observe la ubicación para el módulo en la entrada de registro. La biblioteca cargable dinámica del proveedor (DLL) se debe instalar en c:\Program Files\Cisco\Nexus1000V, junto con un script del powershell que se utiliza para instalar el proveedor. Asegúrese de que el DLL esté presente.
Desinstale/reinstale el proveedor con el panel de control
Una desinstalación del proveedor se completa vía una desinstalación del programa del panel de control híper-v del servidor 2012. Para reinstalar el proveedor, haga doble clic el instalador del proveedor.
Marque la conformidad de la extensión
Asegúrese de que la extensión del proveedor sea activa y obediente en SCVMM. Navegue a las configuraciones > a los proveedores de la configuración. Verifique que la extensión del nexo 1000V de Cisco Systems sea activa. Esto significa que la extensión es utilizada por SCVMM.
Verifique la Conectividad entre el VS y SCVMM
SCVMM habla con el VS, así que usted debe resolver problemas del host SCVMM.
Compruebe que:
- Usted puede hacer ping el VS del host SCVMM.
- Usted puede hojear vía un buscador Web a la interfaz de programación de aplicaciones N1KV (API).
Si usted no puede hacer ping el VS, después verifique los Firewall de Windows y marque para saber si hay problemas de conectividad de red. No hay requisito que el VS y el SCVMM deben ser en la misma subred.
Para verificar el API, utilice el internet explorer (IE) y hojee al RESTO API VS con esta cadena: http://<vsm-ip>/api/n1kv.
Usted debe recibir esta salida:
Si usted no puede alcanzar el API, después verifique eso:
- No hay proxys de Internet configurados en el host SCVMM. SCVMM hereda los proxys si él se define en el IE. Marque las configuraciones de Internet en el IE para verificar que un proxy está definido. Usted puede ser que sea requerido agregar una excepción para el VS.
- El web server y el API es accesibles en el VS. Verifique que el HTTP-servidor esté habilitado en el VS, y si se habilitan algunos Firewall que bloqueen el tráfico del puerto 80.
Problemas virtuales del módulo Ethernet (VEM)
N1KV en el control híper-v de las aplicaciones L3 solamente. No hay manera de controlar híper-v con con el control L2. El control de la configuración L3 en híper-v es mucho más fácil que una configuración similar en VMware. No hay necesidad de dedicar un NIC al VEM; el VS habla directamente con la Administración híper-v NIC del servidor 2012. No hay requisito que la Administración NIC se debe asociar al módulo VEM, así que significa que usted no necesita un puerto-perfil especial del veth para el control L3.
La instalación del VEM es también mucho más fácil. No hay componente del administrador de la actualización de VMware (VUM) con SCVMM. La capacidad de instalar los componentes de la extensión se incorpora directamente a SCVMM. Si el VEM no está instalado en el host híper-v, después SCVMM copia y instala el VEM en el host híper-v de la blanco automáticamente. Si usted quiere instalar manualmente el VEM, es un clic doble simple de la aplicación de instalación VEM en el host. La desinstalación es también un programa simple quita del panel de control.
El host híper-v no instala a N1KV
Un error común que usted puede ser que encuentre es que un host híper-v no está agregado al N1KV con SCVMM. Hay las verificaciones múltiples que se deben hacer para resolver problemas este problema.
Aquí está un error frecuente que usted puede ser que vea en SCVMM cuando los VEM instalan fallan:
La comprobación para la vieja red combina en el host híper-v
Pudo haber un equipo viejo de otro N1KV en el host híper-v. Si es así usted debe borrar al viejo equipo antes de que usted agregue el host al N1KV. En el host híper-v, ejecute Powershell y ingrese el comando GET-NetSwitchTeam. Si aparece un viejo equipo, después usted debe quitarlo con el comando de la eliminación-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) (MTU) de los NIC y los N1KV no hacen juego
Las configuraciones de MTU en híper-v se fijan por el NIC a través de las configuraciones NIC. Cuando usted crea a un equipo, el MS asigna que por mandato las configuraciones de MTU de todos los NIC en el equipo son idénticas.
Hay dos maneras para fijar y verificar las configuraciones de MTU. El primer está a través de las configuraciones del adaptador de red. La segunda manera es utilizar Powershell. Aquí está un ejemplo que ilustra el uso de Powershell para conseguir y fijar la configuración de MTU al mismo tiempo:
PS C:\Program Files (x86)\cisco\Nexus1000V>
Get-NetAdapterAdvancedProperty -RegistryKeyword
*jumbo* -Name ? <adapter name>" | Set-NetAdapterAdvancedProperty
-RegistryValue <mtu value>
La nueva configuración no trabaja debido a la configuración añeja/vieja N1KV
Usted puede ser que encuentre un problema donde hay una configuración añeja N1KV en el host híper-v que no permite que sea agregada a la nueva configuración. Generalmente cuando usted borra el N1KV viejo de SCVMM o del administrador híper-v, limpia la configuración. Sin embargo, pudo haber un caso donde usted debe marcar y borrar la vieja configuración N1KV del registro híper-v del host.
Ingrese el comando regedit, y borre la configuración N1KV en esta ubicación:
HKEY_LOCAL_MACHINE\SYSTEM > CurrentControlSet > Services > VMSMP >
Parameters >SwitchList
Después de que usted borre la entrada de registro, limpie vía el administrador híper-v y reinicie.
Los drivers requeridos no son error encontrado
Usted puede ser que reciba un error que los drivers o el MSI requeridos no se encuentran cuando usted intenta agregar un host híper-v al N1KV. Aquí está una muestra del error de la ventana de los trabajos:
Esto significa generalmente que el código N1KV VEM no existe en el servidor SCVMM. El servidor SCVMM debe verificar la extensión que está instalada en el host híper-v. Incluso si el código VEM está instalado ya en el host híper-v, el instalador N1KV VEM se debe copiar a un directorio en el servidor SCVMM.
Verifique que el instalador N1KV VEM esté copiado a los drivers de la extensión de C:\ProgramData\Switch en el servidor SCVMM. Si no existe, después copia el archivo al directorio, y agrega el host híper-v al N1KV.
El módulo VEM no aparece en el VS
En este caso, todo aparece trabajar en SCVMM, pero el módulo nunca aparece en el VS. Es raro que éste sucede con híper-v, puesto que la configuración es tan simple. Cuando sucede, hay pocas cosas simples a intentar.
Recomience el proceso N1KV en el host híper-v
Utilice el administrador de tareas o los servicios para recomenzar el proceso N1KV en el host híper-v que presenta el problema.
Aquí está un tiro de pantalla del servicio N1KV en el administrador de tareas - hagalo clic con el botón derecho del ratón, y seleccione el reinicio:
No crean al equipo VEM correctamente
Cuando usted crea el Switch lógico en SCVMM, usted no puede elegir ningún equipo o al equipo. Con el N1KV, usted debe elegir siempre al equipo, incluso si usted tiene solamente un NIC asociado.
Aquí está un tiro de pantalla que ilustra donde fijar la configuración del equipo para el Switch lógico:
Todos los puertos VETH están abajo después de una Host-reinicialización
Híper-v es muy capaz a este respecto; si ve que los VM están accionar-en, y que la administración publicó una reinicialización, se detiene brevemente el estado de los VM y de las reinicializaciones. Cuando se vuelve el sistema en línea, intenta traer los VM detrás en línea cuanto antes. Esto asume que usted vivo-no emigró todos los VM del host antes de la reinicialización.
El problema es que híper-v trae a VM detrás en línea antes de que el proceso VEM comience realmente. La solución alternativa es fijar los VM con un retardo del autoempezado. La ingeniería recomienda que un trigésimo segundo retardo está utilizado para permitir que el VEM y el VS comuniquen antes de la reanudar híper-v/encendido de los intentos todos los VM.
Incapaz de encontrar el error obediente del Switch
Cuando usted intenta crear o mover un VM al N1KV, o vivo-emigrar un VM a partir de un host a otro, usted puede ser que reciba este error:
Esto es un mensaje de advertencia más que y error. Aunque aparece como error en la pantalla del trabajo, no indica que algo está seriamente quebrado. El problema es que SCVMM intenta guardar un estado obediente entre sí mismo, el VS, y el VEM. Por alguna razón, SCVMM piensa de vez en cuando que el estado está fuera de sincroniza, y determina eso para seguro recibe el N1KV es no obediente. La conformidad de los host individuales se monitorea bajo la tela > switch> lógico lógico del <your N1KV del switches>.
Haga clic los host abotonan en la cinta en la cima de la pantalla:
Si el host es no obediente, después usted debe intentar al remediate el host. Seleccione el host que está fuera de conformidad, y haga clic en el botón de Remediate en la cima de la pantalla. Esto acciona SCVMM para sincronizar los datos entre sí mismo, el VS, y el módulo VEM. Después de algunos minutos, los cambios de estado a obediente, y usted no consideran ninguna errores.
Otros problemas y comandos útiles
Esta sección describe varios problemas y comandos útiles diversos para N1KV en híper-v.
El VS no se puede jerarquizar en híper-v
Usted no puede actualmente ejecutado el VS en un host híper-v jerarquizado. A diferencia de ESXi, por alguna razón el VS no puede ejecutarse en un host híper-v virtual. La ingeniería es consciente del problema, pero es prioridad baja en el momento, sea tan consciente de esa restricción. Sin embargo, usted puede ejecutar el VS en un host jerarquizado de ESXi, de modo que sea una solución alternativa posible.
Datos en espera de la máquina virtual (VMQ)
VMQ es casi idéntico a la cola del dispositivo de la máquina virtual de VMware (VMDQ). VMQ requiere que el NIC físico soporte VMQ. El NIC crea una cola de la red para cada VM en el sistema, que permite que el tráfico de la red fluya directamente del hipervisor al VM. Esto mejora el rendimiento de la red para los VM.
Comandos de Powershell usados para marcar VMQ
Hay dos comandos útiles usados para marcar para saber si hay información VMQ con Powershell en el host híper-v:
- GET-NetAdapterVmq
- GET-NetAdapterVmqQueue
Uso de los comandos de Vemcmd para marcar VMQ
Éste es para el mostrar información usado comando primary sobre VETHs para el cual se han afectado un aparato las 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
Uso de Vemcmd para ver los recursos VMQ
Este comando visualiza la información sobre los NIC físicos VMQ-habilitados:
>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 útiles de PowerShell
Hay varios comandos de Powershell que tiran o avanzan de los datos en el VS. Esto le permite a la instalación del script y a la orquestación de los VM al N1KV. También permite que usted tire de más información detallada que muestre las relaciones entre los objetos SCVMM y N1KV.
Utilice Powershell de SCVMM
Usted debe asegurarse de que usted utilice un Powershell que tenga los plug-in SCVMM. La manera más fácil de lograr esto es iniciar Powershell de la consola SCVMM:
El comando GET-SCPortClassification
Este comando se utiliza para ver el link entre una puerto-clasificación SCVMM y el puerto-perfil N1KV a los cuales se conecte:
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 comando GET-SCVirtualNetworkAdapterExtensionPortProfile
Este comando se utiliza para ver la información sobre el puerto-perfil del 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
El comando GET-SCConfigurationProvider
Este comando se utiliza para ver la información sobre las Extensiones del 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
Ubicaciones de Vemcmd y de Vemlog
Los comandos VEM están disponibles en el C: > Program Files (Archivos de programa) (x86) > Cisco > Nexus1000V.
Verifique el inventario del adaptador físico con el registro
Para verificar la Conectividad física del adatper al N1KV en el registro, acceda esta ubicación del registro:
- Estructura del registro: HKEY_LOCAL_MACHINE > SISTEMA > CurrentControlSet
- Clave de registro: Servicios > Nexus1000V > parámetros > HostPhyAdapters
No puede borrar los objetos N1KV debido a la plantilla temporal
Usted puede ser que encuentre este problema si usted implementó las plantillas y construyó los VM con la aplicación de la plantilla del servicio SCVMM, y a los usuarios permitidos del autoservicio para crear sus propios VM. Esta plantilla temporal no es un objeto viewable con SCVMM. Usted debe utilizar el SCVMM Powershell para borrar la plantilla temporal con este comando:
Get-SCVMTemplate | where {$_.Name -like "Temporary*"} | Remove-SCVMTemplate
Los VM asignados a N1KV reciben los errores lógicos de la conformidad del Switch
Los errores de la conformidad son a veces apenas una función de la manera que SCVMM actúa. El N1KV pudo ser completamente obediente en SCVMM, pero usted todavía recibe los errores de la conformidad.
Usted puede ser que también reciba este mensaje, donde a le no se permite elegir o modificar ninguna configuraciones de red para un VM:
Esto ocurre cuando uno de los Nodos del cluster MS tiene problemas. SCVMM descubre que todos los Nodos no están en la conformidad, y no permite que usted realice los cambios hasta que usted quite o repare el nodo con el problema. Ésta es conducta esperada en SCVMM.
Para determinar qué nodo tiene los problemas, utilice SCVMM o agrupe al administrador de la Conmutación por falla, y repare el nodo del problema. Si usted no puede reparar el nodo, después usted debe quitar o detenerse brevemente él del cluster. Una vez que eso es completo, usted tiene la capacidad de agregar y de modificar los VM al N1KV.
ComentariosDéjenos ayudarlo
- Abrir un caso de soporte
- (Requiere un Cisco Service Contract)