Guide de dépannage de Nexus 1000V sur Hyper-V
Contenu
Introduction
Ce document décrit les procédures utilisées pour dépanner les commutateurs Cisco Nexus 1000V (N1KV) sur les serveurs Microsoft (MS) Hyper-V. La mise en oeuvre de Hyper-V est très différente de celle d'ESXi. Il y aura donc des problèmes fréquemment rencontrés ; ce document a donc été créé.
La plupart des informations décrites dans ce document proviennent directement de l'Introduction de nouveaux produits d'ingénierie (INP) et des problèmes rencontrés lors des tests bêta. Ce document est dynamique et sera mis à jour en conséquence.
Conditions préalables
Conditions requises
Cisco vous recommande de prendre connaissance des rubriques suivantes :
- Commutateurs de la gamme N1KV
- Serveurs MS Hyper-V
Components Used
Ce document n'est pas limité à des versions de matériel et de logiciel spécifiques.
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.
Problèmes d'application du programme d'installation
L'application Installer présente de nombreux problèmes et cette section décrit les problèmes les plus courants.
Utiliser l'application d'installation avec prudence
Voici quelques raisons pour lesquelles vous devriez utiliser cette application avec prudence :
- Il n'attend pas assez longtemps pour que le module VSM (Virtual Supervisor Module) démarre sur de nombreuses plates-formes, et échoue souvent.
- Il déplace l'interface de gestion (mgmt) vers un commutateur logique MS et ne vous informe pas, même si vous ne souhaitez pas déplacer l'interface de gestion.
- Le commutateur logique créé ne peut pas utiliser une interface associée. Cela signifie qu'il n'y a pas de redondance pour le commutateur ou l'interface de gestion.
- Vous ne pouvez pas simplement ajouter une autre carte d'interface réseau (NIC) au commutateur logique afin de le faire coexister ; vous devez créer un nouveau commutateur avec une interface associée et tout déplacer pour disposer d'une redondance.
- L'application ne reconnaît pas si les hôtes sur lesquels vous installez les VSM font partie d'un cluster. Cela signifie que les disques virtuels sont installés dans le stockage local et non dans le stockage en cluster.
- L'application crée une liaison ascendante réseau avec un ensemble de réseau système. Chaque segment de réseau doit avoir un réseau système défini. C'est un bogue majeur, alors soyez conscient.
Emplacement du journal des applications du programme d'installation
L'application Installer ne doit fonctionner que dans des environnements de terrain vert. N'essayez pas d'utiliser l'application dans une configuration précédemment établie. Afin de vérifier si les erreurs du programme d'installation se sont produites, accédez à C : > Utilisateurs > <nom d'utilisateur> > AppData > Local > Temp > 2 > Nexus1000vInstaller_xxxxxxxx.txt, et consultez le journal.
L'application d'installation migre la carte réseau de gestion
Le comportement par défaut (et uniquement) de l'application Installer consiste à afficher et à utiliser la carte réseau physique à laquelle l'interface de gestion est connectée. Lorsque vous exécutez l'application Installer, vous ne pouvez choisir qu'une seule carte réseau : la carte réseau de gestion.
L'application Installer :
- Crée un commutateur logique MS
- Ajoute les deux hôtes qui ont les VSM au commutateur logique
- Fait migrer la carte réseau de gestion vers une carte réseau virtuelle sur le commutateur logique
- Ajoute les connexions réseau VSM à ce commutateur logique
Cette image illustre comment un des hôtes a maintenant un commutateur logique MS attribué et une carte réseau virtuelle qui transporte le trafic de gestion :
Vous pouvez voir que la liaison ascendante est définie avec Aucune équipe de liaison ascendante lorsque vous affichez le commutateur logique créé. Ce problème est dû au fait que vous ne pouvez pas ajouter une autre carte réseau ou une carte réseau associée à ce commutateur. Vous n'êtes pas autorisé à modifier le type d'équipe une fois le commutateur créé. En outre, l'application Installer ne vous permet pas d'ajouter une interface associée.
Pour que le commutateur soit associé, vous devez le supprimer et l'ajouter à nouveau avec un jeu d'association. C'est possible, mais fastidieux. Vous voulez la redondance, donc si elle n'est pas associée, alors il y a un problème potentiel.
Le commutateur logique pour la gestion et le VSM n'est pas créé sur tous les commutateurs
Il s’agit d’un autre problème, car les VSM sont liés à ces deux hôtes uniquement. Ainsi, la migration en direct et Cisco Home-Agent (HA) sont limités à deux hôtes. Vous avez la possibilité de migrer les autres hôtes Hyper-V vers le commutateur logique MS créé, mais il n'est pas terminé automatiquement par l'application Installer.
L'application d'installation n'utilise pas le stockage basé sur le cluster
Lorsque les paramètres de la machine virtuelle (VM) VSM sont créés, la disponibilité a une valeur Faible. MS autorise uniquement les machines virtuelles avec des valeurs de disponibilité élevées à être incluses dans le stockage basé sur le cluster. Les informations VSM Virtual Disk (VD) et VM sont placées sur le stockage local de l'hôte Hyper-V. De nouveau, cela limite la migration en direct et la haute disponibilité des machines virtuelles VSM.
Problèmes liés à la configuration VSM créée par l'application d'installation
L'application Installer crée une configuration de base sur le VSM et importe une partie de cette configuration dans System Center Virtual Machine Manager (SCVMM).
L'application exécute ces actions du côté N1KV :
- Crée un réseau logique par défaut
- Crée un pool de segments de réseau par défaut
- Crée un réseau de liaison ascendante par défaut
- Crée un profil de port eth par défaut avec l'épinglage mac du groupe de canaux
- Crée un profil de port veth par défaut pour no-restriction
- Crée un modèle de pool d'adresses IP par défaut
- Crée le commutateur logique N1KV dans SCVMM
Non seulement l'application crée ces paramètres sur le VSM, mais elle remplit ces informations dans SCVMM lorsqu'elle crée le commutateur logique.
L'application fonctionne bien dans l'aspect de configuration, mais a des problèmes avec le réseau de liaison ascendante. Voici comment la liaison ascendante du réseau est créée :
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
Il existe une liaison ascendante du réseau système, ce qui pose un problème. Si vous avez une liaison ascendante avec une liaison ascendante du réseau système définie, tous les segments réseau et les profils de port qui utilisent cette liaison ascendante doivent être également système. Cela signifie que vous êtes limité à 32 segments de réseau qui peuvent utiliser cette liaison ascendante.
Il n'est pas clair qu'il s'agit d'un problème, mais montrons un exemple de ce qui se passe si vous créez un nouveau segment de réseau et un nouveau modèle de pool d'adresses IP pour 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)#
Actualisez l'extension SCVMM N1KV et ajoutez le réseau de machines virtuelles pour le segment de réseau que vous avez créé. Lorsque vous essayez d'affecter une machine virtuelle au nouveau réseau de machines virtuelles, vous obtenez les erreurs suivantes :
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
Ces erreurs sont dues au fait que la liaison ascendante du réseau transporte un réseau système et que le segment de réseau ne le transporte pas. Vous avez deux options : créez une nouvelle liaison ascendante réseau sans réseau système ou ajoutez un réseau système à votre nouveau segment de réseau.
SCVMM ne peut pas se connecter au VSM
La connectivité entre le module VSM et SCVMM est différente avec Hyper-V et ESXi. Dans la solution Hyper-V, SCVMM parle à notre API (Nexus 1000V). Cela signifie que la connexion est établie et maintenue à partir de l’hôte SCVMM. Lorsque la commande show svs connection est utilisée sur le VSM, elle n'affiche rien ; cette solution ne contient aucune connexion SVS.
SCVMM interroge également le VSM une fois toutes les trente minutes. Cela signifie que vous devez forcer une actualisation si vous voulez que les modifications du VSM apparaissent immédiatement sur SCVMM.
Vérifier que le fournisseur est installé
Le fournisseur de Hyper-V est similaire au plug-in de N1KV sur ESXi. La différence est qu'il n'y a pas de fournisseur unique pour chaque VSM. Vous n'avez besoin d'exécuter l'installation du fournisseur qu'une seule fois. Cela remplit SCVMM avec les informations nécessaires pour comprendre comment parler au VSM.
Le fournisseur n'est pas spécifique à chaque VSM. Le fournisseur est enregistré dans le Registre Windows. Vous pouvez rechercher VSEM dans le Registre ou accéder à cet emplacement :
Si vous ne pouvez pas supprimer le fournisseur, vous pouvez supprimer l'entrée dans le Registre et redémarrer le service SCVMM.
Notez l'emplacement du module dans l'entrée de Registre. La bibliothèque DLL (Dynamic Loadable Library) du fournisseur doit être installée dans c:\Program Files\Cisco\Nexus1000V, avec un script powershell utilisé pour installer le fournisseur. Assurez-vous que la DLL est présente.
Désinstaller/réinstaller le fournisseur à l'aide du Panneau de configuration
Une désinstallation du fournisseur est effectuée via un programme désinstallé à partir du panneau de configuration Hyper-V Server 2012. Pour réinstaller le fournisseur, double-cliquez sur le programme d'installation du fournisseur.
Vérifier la conformité de l'extension
Assurez-vous que l'extension du fournisseur est active et conforme dans SCVMM. Accédez à Paramètres > Fournisseurs de configuration. Vérifiez que l'extension Cisco Systems Nexus 1000V est active. Cela signifie que l'extension est utilisée par SCVMM.
Vérification de la connectivité entre VSM et SCVMM
SCVMM communique avec le VSM, vous devez donc effectuer un dépannage à partir de l'hôte SCVMM.
Vérifiez que :
- Vous pouvez envoyer une requête ping au VSM à partir de l'hôte SCVMM.
- Vous pouvez naviguer via un navigateur Web vers l'interface de programmation d'applications (API) N1KV.
Si vous ne pouvez pas envoyer de requête ping au VSM, vérifiez les pare-feu Windows et vérifiez les problèmes de connectivité réseau. Il n'est pas obligatoire que le VSM et le SCVMM soient sur le même sous-réseau.
Afin de vérifier l'API, utilisez Internet Explorer (IE) et accédez à l'API REST VSM avec cette chaîne : http://<vsm-ip>/api/n1kv.
Vous devez recevoir cette sortie :
Si vous ne parvenez pas à atteindre l'API, vérifiez que :
- Aucun proxy Internet n'est configuré sur l'hôte SCVMM. SCVMM hérite des proxys s'ils sont définis dans IE. Vérifiez les paramètres Internet dans IE afin de vérifier qu'un proxy est défini. Vous devrez peut-être ajouter une exception pour le VSM.
- Le serveur Web et l'API sont accessibles sur le VSM. Vérifiez que le serveur http est activé sur le VSM et si des pare-feu sont activés pour bloquer le trafic du port 80.
Problèmes liés au module Virtual Ethernet (VEM)
N1KV sur Hyper-V utilise le contrôle de couche 3 uniquement. Il n'y a aucun moyen de contrôler Hyper-V avec le contrôle L2. Le contrôle de configuration L3 sur Hyper-V est beaucoup plus facile qu'une configuration similaire sur VMware. Il n'est pas nécessaire de dédier une carte réseau au VEM ; le module VSM communique directement avec la carte réseau de gestion Hyper-V Server 2012. Il n'est pas nécessaire que la carte réseau de gestion soit connectée au module VEM, ce qui signifie que vous n'avez pas besoin d'un profil de port spécial pour le contrôle L3.
L'installation du VEM est également beaucoup plus facile. Il n'existe aucun composant VMware Update Manager (VUM) avec SCVMM. La possibilité d'installer des composants d'extension est directement intégrée à SCVMM. Si le VEM n'est pas installé sur l'hôte Hyper-V, SCVMM copie et installe automatiquement le VEM sur l'hôte Hyper-V cible. Si vous voulez installer manuellement le VEM, il s'agit d'un simple double-clic de l'application d'installation de VEM sur l'hôte. La désinstallation est également un programme simple à supprimer du Panneau de configuration.
L'hôte Hyper-V ne s'installe pas sur N1KV
Une erreur fréquente est qu'un hôte Hyper-V n'est pas ajouté à N1KV via SCVMM. Plusieurs vérifications doivent être effectuées pour résoudre ce problème.
Voici une erreur type que vous pouvez voir dans SCVMM lorsque l'installation de VEM échoue :
Rechercher les anciennes équipes réseau sur l'hôte Hyper-V
Il peut y avoir une ancienne équipe d'un autre N1KV sur l'hôte Hyper-V. Si c'est le cas, vous devez supprimer l'ancienne équipe avant d'ajouter l'hôte au N1KV. Sur l'hôte Hyper-V, exécutez Powershell et entrez la commande Get-NetSwitchTeam. Si une ancienne équipe apparaît, vous devez la supprimer à l'aide de la commande 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
L'unité de transmission maximale (MTU) des cartes réseau et du N1KV ne correspond pas
Les paramètres MTU dans Hyper-V sont définis par carte réseau via les paramètres de la carte réseau. Lorsque vous créez une équipe, MS exige que les paramètres MTU de toutes les cartes réseau de l'équipe soient identiques.
Il existe deux façons de définir et de vérifier les paramètres MTU. La première est via les paramètres de la carte réseau. La deuxième méthode consiste à utiliser Powershell. Voici un exemple qui illustre l'utilisation de Powershell afin d'obtenir et de définir le paramètre MTU en même temps :
PS C:\Program Files (x86)\cisco\Nexus1000V>
Get-NetAdapterAdvancedProperty -RegistryKeyword
*jumbo* -Name ?" | Set-NetAdapterAdvancedProperty
-RegistryValue
La nouvelle configuration ne fonctionne pas en raison d'une configuration N1KV obsolète/obsolète
Vous pouvez rencontrer un problème où il y a une configuration N1KV obsolète sur l'hôte Hyper-V qui ne permet pas de l'ajouter à la nouvelle configuration. Généralement, lorsque vous supprimez l'ancien N1KV de SCVMM ou de Hyper-V Manager, il nettoie la configuration. Cependant, il peut y avoir un cas où vous devez vérifier et supprimer l'ancienne configuration N1KV du Registre hôte Hyper-V.
Entrez la commande Regedit et supprimez la configuration N1KV à cet emplacement :
HKEY_LOCAL_MACHINE\SYSTEM > CurrentControlSet > Services > VMSMP >
Parameters >SwitchList
Après avoir supprimé l'entrée de Registre, nettoyez-la via le gestionnaire Hyper-V et redémarrez.
Erreur introuvable pour les pilotes requis
Il se peut que vous receviez une erreur indiquant que les pilotes ou MSI requis sont introuvables lorsque vous tentez d'ajouter un hôte Hyper-V au N1KV. Voici un exemple d'erreur dans la fenêtre Tâches :
Cela signifie généralement que le code VEM N1KV n'existe pas sur le serveur SCVMM. Le serveur SCVMM doit vérifier l'extension installée sur l'hôte Hyper-V. Même si le code VEM est déjà installé sur l'hôte Hyper-V, le programme d'installation VEM N1KV doit être copié dans un répertoire du serveur SCVMM.
Vérifiez que l'installateur VEM N1KV est copié sur C:\ProgramData\Switch Extension Drivers sur le serveur SCVMM. S'il n'existe pas, copiez le fichier dans le répertoire et ajoutez l'hôte Hyper-V au N1KV.
Le module VEM n'apparaît pas sur le module VSM
Dans ce cas, tout semble fonctionner dans SCVMM, mais le module n'apparaît jamais sur le VSM . Il est rare que cela se produise avec Hyper-V, car la configuration est si simple. Quand cela arrive, il y a peu de choses simples à essayer.
Redémarrer le processus N1KV sur l'hôte Hyper-V
Utilisez le Gestionnaire des tâches ou les Services afin de redémarrer le processus N1KV sur l'hôte Hyper-V qui présente le problème.
Voici une capture d'écran du service N1KV dans le Gestionnaire des tâches - cliquez dessus avec le bouton droit et sélectionnez Redémarrer :
L'équipe VEM n'est pas créée correctement
Lorsque vous créez le commutateur logique dans SCVMM, vous pouvez choisir Aucune équipe ou Équipe. Avec la N1KV, vous devez toujours choisir Team, même si une seule carte réseau est connectée.
Voici une capture d'écran qui montre où définir le paramètre Team pour le commutateur logique :
Tous les ports VETH sont arrêtés après un redémarrage de l'hôte
Hyper-V est très performant à cet égard ; s'il constate que les machines virtuelles sont sous tension et que l'administration a lancé un redémarrage, il met en pause l'état des machines virtuelles et redémarre. Lorsque le système revient en ligne, il tente de remettre les machines virtuelles en ligne dès que possible. Ceci suppose que vous n'avez pas effectué la migration dynamique de toutes les machines virtuelles hors de l'hôte avant le redémarrage.
Le problème est que Hyper-V remet les machines virtuelles en ligne avant le démarrage réel du processus VEM. La solution de contournement consiste à définir les machines virtuelles avec un délai de démarrage automatique. Engineering recommande l'utilisation d'un délai de trente secondes afin de permettre aux modules VEM et VSM de communiquer avant que Hyper-V tente de reprendre/de mettre sous tension toutes les machines virtuelles.
Erreur de commutateur conforme introuvable
Lorsque vous tentez de créer ou de déplacer une machine virtuelle vers N1KV, ou de migrer en direct une machine virtuelle d'un hôte à un autre, vous pouvez recevoir cette erreur :
Il s'agit d'un message d'avertissement plus que d'une erreur. Même s'il s'agit d'une erreur dans l'écran du travail, il n'indique pas qu'une erreur est grave. Le problème est que SCVMM tente de maintenir un état de conformité entre lui-même, le VSM et le VEM. Pour une raison quelconque, SCVMM pense occasionnellement que l'état est désynchronisé et détermine que pour certains hôtes, la N1KV n'est pas conforme. La conformité des hôtes individuels est contrôlée sous Fabric > Logical switches> <your N1KV logic switch>.
Cliquez sur le bouton Hôtes du ruban en haut de l'écran :
Si l'hôte n'est pas conforme, vous devez tenter de corriger l'hôte. Sélectionnez l'hôte non conforme, puis cliquez sur le bouton Remediate en haut de l'écran. Cela déclenche SCVMM pour synchroniser les données entre lui-même, le VSM et le module VEM. Au bout de quelques minutes, l'état devient Conforme, et aucune erreur ne s'affiche.
Autres problèmes et commandes utiles
Cette section décrit plusieurs problèmes divers et commandes utiles pour N1KV sur Hyper-V.
VSM ne peut pas être imbriqué sur Hyper-V
Vous ne pouvez pas exécuter le VSM sur un hôte Hyper-V imbriqué actuellement. Contrairement à ESXi, pour une raison quelconque, le VSM ne peut pas s'exécuter sur un hôte Hyper-V virtuel. L'ingénierie est consciente de la question, mais elle n'est pas prioritaire pour le moment, alors soyez conscient de cette restriction. Cependant, vous pouvez exécuter le VSM sur un hôte ESXi imbriqué, ce qui constitue une solution de contournement possible.
Mise en file d'attente des machines virtuelles (VMQ)
VMQ est presque identique à VMware Virtual Machine Device Queue (VMDQ). VMQ nécessite que la carte réseau physique prenne en charge VMQ. La carte réseau crée une file d'attente réseau pour chaque machine virtuelle du système, ce qui permet au trafic réseau de circuler directement de l'hyperviseur vers la machine virtuelle. Cela améliore les performances réseau des machines virtuelles.
Commandes Powershell utilisées pour vérifier VMQ
Deux commandes utiles sont utilisées pour vérifier les informations VMQ via Powershell sur l'hôte Hyper-V :
- Get-NetAdapterVmq
- Get-NetAdapterVmqQueue
Utilisation des commandes Vemcmd pour vérifier VMQ
Il s'agit de la commande principale utilisée afin d'afficher des informations sur les VETH pour lesquelles des files d'attente ont été allouées :
>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
Utilisation de Vemcmd pour afficher les ressources VMQ
Cette commande affiche des informations sur les cartes réseau physiques VMQ activées :
>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
Commandes PowerShell utiles
Il existe plusieurs commandes Powershell qui extraient ou poussent des données dans le VSM. Cela vous permet de script de l'installation et de l'orchestration des machines virtuelles sur N1KV. Il vous permet également d'extraire des informations plus détaillées qui montrent les relations entre les objets SCVMM et N1KV.
Utiliser Powershell à partir de SCVMM
Vous devez vous assurer que vous utilisez un Powershell qui possède les modules d'extension SCVMM. La façon la plus simple d'y parvenir est de lancer Powershell à partir de la console SCVMM :
Get-SCPortClassification Commande
Cette commande est utilisée afin d'afficher la liaison entre une classification de port SCVMM et le profil de port N1KV auquel elle est liée :
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
Get-SCVirtualNetworkAdapterExtensionPortProfile Commande
Cette commande est utilisée afin d'afficher des informations sur le profil de port de liaison ascendante :
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
Commande Get-SCConfigurationProvider
Cette commande est utilisée afin d'afficher des informations sur les extensions de fournisseur chargées sur le serveur 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
Emplacements Vemcmd et Vemlog
Les commandes VEM sont disponibles à C : > Fichiers programme (x86) > Cisco > Nexus1000V.
Vérification de l'inventaire des adaptateurs physiques via le Registre
Afin de vérifier la connectivité de l'adaptateur physique au N1KV dans le Registre, accédez à cet emplacement de Registre :
- Ruche du Registre : HKEY_LOCAL_MACHINE > SYSTEM > CurrentControlSet
- Clé de Registre : Services > Nexus1000V > Paramètres > HostPhyAdapters
Impossible de supprimer les objets N1KV en raison d'un modèle temporaire
Vous pourriez rencontrer ce problème si vous avez mis en oeuvre des modèles et des machines virtuelles construites via l'application Modèle de service SCVMM et autorisé les utilisateurs en libre-service à créer leurs propres machines virtuelles. Ce modèle temporaire n'est pas un objet visible via SCVMM. Vous devez utiliser SCVMM Powershell afin de supprimer le modèle temporaire avec cette commande :
Get-SCVMTemplate | where {$_.Name -like "Temporary*"} | Remove-SCVMTemplate
Erreurs de conformité des commutateurs logiques de réception des machines virtuelles affectées à N1KV
Parfois, les erreurs de conformité ne sont qu'une fonction du fonctionnement de SCVMM. Le N1KV peut être entièrement conforme dans SCVMM, mais vous recevez toujours des erreurs de conformité.
Vous pouvez également recevoir ce message, dans lequel vous n'êtes pas autorisé à choisir ou modifier les paramètres réseau d'une machine virtuelle :
Cela se produit lorsqu'un des noeuds du cluster MS a des problèmes. SCVMM détecte que tous les noeuds ne sont pas conformes et ne vous permet pas d'apporter des modifications tant que vous n'avez pas supprimé ou résolu le noeud avec le problème. Ce comportement est attendu dans SCVMM.
Afin de déterminer quel noeud présente les problèmes, utilisez SCVMM ou Cluster Failover Manager et corrigez le noeud de problème. Si vous ne pouvez pas réparer le noeud, vous devez le supprimer ou le suspendre du cluster. Une fois cette opération terminée, vous pouvez ajouter et modifier des machines virtuelles au N1KV.
Historique de révision
| Révision | Date de publication | Commentaires |
|---|---|---|
1.0 |
01-Oct-2013 |
Première publication |
CommentairesContacter Cisco
- Ouvrir un dossier d’assistance
- (Un contrat de service de Cisco est requis)