Commutateurs : Cisco Nexus 1000V Switch for Microsoft Hyper-V

Le Nexus 1000V sur hyper-v dépannent le guide

18 octobre 2016 - Traduction automatique
Autres versions: PDFpdf | Anglais (22 août 2015) | Commentaires

Introduction

Ce document décrit les procédures utilisées afin de dépanner des Commutateurs de gamme de Cisco Nexus 1000V (N1KV) sur les serveurs hyper-v de Microsoft (MS). L'implémentation sur hyper-v est beaucoup différente que sur ESXi, tellement il y en aura les questions fréquent-rencontrées ; ainsi, ce document a été créé.

Une grande partie des informations décrites dans ce document est livré directement de l'introduction de produit nouveau d'ingénierie (NPI), et des questions produites pendant l'essai pilote. Ce document est dynamique en nature, et sera mis à jour en conséquence.

Contribué par Louis Watta et Matthew Wronkowski, ingénieurs TAC Cisco.

Conditions préalables

Conditions requises

Cisco vous recommande de prendre connaissance des rubriques suivantes :

  • Commutateurs de gamme N1KV
  • Serveurs hyper-v de MS

Composants utilisés

Ce document n'est pas limité à des versions de matériel et de logiciel spécifiques. 

Les informations contenues dans ce document ont été créées à partir des périphériques d'un environnement de laboratoire spécifique. Tous les périphériques utilisés dans ce document ont démarré avec une configuration effacée (par défaut). Si votre réseau est opérationnel, assurez-vous que vous comprenez l'effet potentiel de toute commande.

Questions d'application d'installateur

Il y a beaucoup de questions avec l'applicaton d'installateur, et cette section décrit les plus communs.

Utilisez l'application d'installateur avec prudence

Voici quelques raisons pour lesquelles vous devriez utiliser cette application avec prudence :

  • Il n'attend pas assez longtemps le module virtuel de superviseur (VSM) pour commencer sur beaucoup de Plateformes, et échoue souvent.
  • Il déplace l'interface de Gestion (mgmt) à un commutateur logique de MS et ne vous informe pas, quoique vous ne pourriez pas vouloir l'interface de mgmt déplacée.
  • Le commutateur logique qui est créé ne peut pas utiliser une interface teamed. Ceci signifie qu'il n'y a aucune Redondance pour le commutateur ou l'interface de mgmt.
  • Vous ne pouvez pas simplement ajouter un autre network interface card (NIC) au commutateur logique afin de le faire teamed ; vous devez créer un nouveau commutateur avec une interface teamed, et le mouvement tout plus d'afin d'avoir la Redondance.
  • L'application n'identifie pas si les hôtes que vous installez le VSMs en fonction font partie d'une batterie. Ceci signifie que les disques virtuels sont installés dans la mémoire locale, pas mémoire de batterie.
  • L'application crée une liaison ascendante de réseau avec un positionnement de réseau de système. Chaque segment de réseau doit avoir un réseau de système réglé. C'est une bogue importante, se rende ainsi compte de lui.

Emplacement de journal d'application d'installateur

L'applicaton d'installateur est seulement censé pour fonctionner dans des environnements de prairie. Ne tentez pas d'utiliser l'application dans une configuration précédent-établie. Afin de vérifier si les erreurs- d'installateur, naviguent vers le C : > les utilisateurs > le <username> > l'AppData > les gens du pays > le Temp > 2 > Nexus1000vInstaller_xxxxxxxx.txt, et vérifient le log.

L'application d'installateur migre gestion le NIC

(Et seulement) le comportement par défaut de l'application d'installateur est d'afficher et utiliser le NIC physique auquel l'interface de mgmt est connectée. Quand vous exécutez l'application d'installateur, vous pouvez seulement choisir un NIC - le NIC de mgmt.

L'application d'installateur :

  1. Crée un commutateur logique de MS
  2. Ajoute les deux hôtes qui ont le VSMs au commutateur logique
  3. Migre le NIC de mgmt vers un nNIC virtuel sur le commutateur logique
  4. Ajoute les connexions réseau VSM à ce commutateur logique

Cette image illustre comment un des hôtes a maintenant un commutateur logique de MS assigné, et un NIC virtuel qui porte le trafic de mgmt :

Vous pouvez voir que la liaison ascendante est définie sans l'équipe de liaison ascendante quand vous visualisez le commutateur logique qui est créé. C'est un problème parce que vous ne pouvez pas ajouter un autre NIC ou un NIC teamed à ce commutateur. On ne te permet pas pour changer le type d'équipe une fois que le commutateur est créé. En outre, l'application d'installateur ne te permet pas pour ajouter une interface teamed.

Afin de changer le commutateur à teamed, vous devez le retirer et l'ajouter de retour avec un positionnement teaming. C'est possible, mais pénible. Vous voulez la Redondance, ainsi si elle pas teamed, alors il y avez un problème potentiel. 

Le commutateur logique pour gestion et VSM n'est pas créé sur tous les Commutateurs

C'est un autre problème parce que le VSMs sont attachés seulement à ces deux hôtes. Ainsi, le transfert et le home-agent vivants de Cisco (ha) sont limités à deux hôtes. Vous avez l'option de migrer les autres hôtes hyper-v vers le commutateur logique de MS qui est créé, mais il n'est pas terminé automatiquement par l'application d'installateur.

L'application d'installateur n'utilise pas la mémoire batterie Batterie

Quand les configurations du virtual machine VSM (VM) sont créées, la Disponibilité a une valeur de bas. Le MS permet seulement des VMs avec la Disponibilité de valeurs de la haute à inclure sur la mémoire batterie Batterie. Ceci place le disque virtuel VSM (VD) et les informations VM sur la mémoire locale de l'hôte hyper-v. De nouveau, ceci limite le vivant-transfert et l'ha pour les VMs VSM.


Remarque: Malheureusement, aucune procédure n'a été découverte pour changer la Disponibilité de configurations pour le VSM une fois qu'il est créé.  

Questions avec la configuration VSM que l'application d'installateur crée

L'application d'installateur crée très une configuration de base sur le VSM, et importe une partie de cette configuration au gestionnaire de virtual machine de System Center (SCVMM).

L'application exécute ces actions du côté N1KV :

  • Crée un réseau logique par défaut
  • Crée un groupe par défaut de segment de réseau
  • Crée un réseau par défaut de liaison ascendante
  • Crée un port-profil par défaut d'eth avec goupiller de MAC de groupe de canaux
  • Crée un port-profil par défaut de veth pour la NO--restriction
  • Crée un modèle de groupe d'IP par défaut
  • Crée le commutateur logique N1KV dans SCVMM

L'application crée non seulement ces configurations sur le VSM, mais elle remplit ces informations dans SCVMM quand elle crée le commutateur logique.

L'application fait bien dans l'aspect de configuration, mais a des problèmes avec le réseau de liaison ascendante. C'est comment la liaison ascendante de 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 y a une liaison ascendante de réseau de système, qui entraîne une question. Si vous avez une liaison ascendante avec la liaison ascendante de réseau de système réglée, alors tous les segments et port-profils de réseau qui utilisent cette liaison ascendante doivent être système aussi bien. Ceci signifie que vous êtes limité à 32 segments de réseau qui peuvent utiliser cette liaison ascendante.

Il n'est pas clair que ce soit un problème, mais nous a permis d'afficher un exemple de ce qui se produit si vous établissez un nouveaux segment de réseau et modèle de pool d'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)#

Régénérez l'extension SCVMM N1KV, et ajoutez le réseau VM pour le segment de réseau que vous avez créé. Quand vous tentez d'assigner une VM au nouveau réseau VM, vous obtenez ces erreurs :

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 provoqué par parce que la liaison ascendante de réseau porte un réseau de système et le segment de réseau ne fait pas. Vous avez deux options : créez une nouvelle liaison ascendante de réseau sans réseau de système, ou ajoutez un réseau de système à votre nouveau segment de réseau. 

SCVMM ne peut pas se connecter au VSM

La Connectivité entre le VSM et le SCVMM est différente avec hyper-v qu'avec ESXi. Dans la solution hyper-v, SCVMM parle à notre (Nexus 1000V) API. Ceci signifie que la connexion est établie et mise à jour de l'hôte SCVMM. Quand la commande de connexion SVS d'exposition est utilisée sur le VSM, elle n'affiche rien ; il n'y a aucune connexion SVS dans cette solution.

SCVMM vote également le VSM une fois toutes les trente minutes. Ceci signifie que vous devez forcer une régénération si vous voulez voir les modifications du VSM apparaître sur SCVMM immédiatement.  

Vérifiez que le fournisseur est installé

Le fournisseur pour hyper-v est semblable au module d'extension pour N1KV sur ESXi. La différence est qu'il n'y a aucun seul fournisseur pour chaque VSM. Vous devez seulement exécuter le fournisseur installez une fois. Ceci remplit SCVMM avec les informations qui sont nécessaires afin de comprendre comment parler au VSM.

Le fournisseur n'est pas spécifique à chaque VSM. Le fournisseur est enregistré dans le registre de Windows. Vous pouvez rechercher VSEM dans le registre, ou naviguez vers cet emplacement :


Si vous êtes en position où vous ne pouvez pas supprimer le fournisseur, alors vous pouvez supprimer l'entrée dans le registre et redémarrer le service SCVMM.

Notez l'emplacement pour le module dans l'entrée dans le registre. La bibliothèque chargeable dynamique de fournisseur (DLL) devrait être installée dans c:\Program Files\Cisco\Nexus1000V, avec un script de powershell qui est utilisé afin d'installer le fournisseur. Assurez-vous que le DLL est présent.

Remarque: Si le DLL est corrompu, vous devez le retirer et le réinstaller. 

Désinstallez/réinstallez le fournisseur avec le panneau de configuration

Un désinstaller du fournisseur est terminé par l'intermédiaire d'un programme désinstallent du panneau de configuration hyper-v du serveur 2012. Afin de réinstaller le fournisseur, double-cliquer l'installateur de fournisseur. 

Vérifiez la conformité d'extension

Assurez-vous que l'extension de fournisseur est en activité et conforme dans SCVMM. Naviguez vers des configurations > des fournisseurs de configuration. Vérifiez que l'extension du Nexus 1000V de Cisco Systems est en activité. Ceci signifie que l'extension est utilisée par SCVMM.

  

Vérifiez la Connectivité entre VSM et SCVMM

SCVMM parle au VSM, ainsi vous devez dépanner de l'hôte SCVMM.

Vérifiez cela :

  • Vous pouvez cingler le VSM de l'hôte SCVMM.
  • Vous pouvez parcourir par l'intermédiaire d'un navigateur Web à l'interface de programmation N1KV (API).

Si vous ne pouvez pas cingler le VSM, alors vérifiez les pare-feu Windows et vérifiez les questions de connexion réseau. Il n'y a aucune condition que le VSM et le SCVMM doivent être sur le même sous-réseau.

Afin de vérifier l'API, l'Internet Explorer d'utilisation (IE) et parcourir au REPOS API VSM avec cette chaîne : http://<vsm-ip>/api/n1kv.

Vous devriez recevoir cette sortie :

Si vous ne pouvez pas atteindre l'API, alors vérifiez cela :

  • Il n'y a aucun proxy d'Internet configuré sur l'hôte SCVMM. SCVMM hérite des proxys s'ils sont définis dans l'IE. Vérifiez les Paramètres Internet dans l'IE afin de vérifier qu'un proxy est défini. Vous pourriez être requis d'ajouter une exception pour le VSM.
  • Le web server et l'API est accessible sur le VSM. Vérifiez que le HTTP-serveur est activé sur le VSM, et si des Pare-feu sont activés qui bloquent le trafic du port 80.

Remarque: Actuellement le VSM traite des appels API pour le HTTP ou le HTTPS, mais SCVMM est limité au HTTP seulement.

Questions virtuelles du module d'Ethernets (VEM)

N1KV sur le contrôle hyper-v des utilisations L3 seulement. Il n'y a aucune manière de contrôler hyper-v avec avec le contrôle L2. Le contrôle de la configuration L3 sur hyper-v est beaucoup plus facile qu'une configuration semblable sur le VMware. Il n'y a aucun besoin de dédier un NIC au VEM ; le VSM parle directement au NIC hyper-v de Gestion du serveur 2012. Il n'y a aucune condition que le NIC de Gestion doit être relié au module VEM, ainsi il signifie que vous n'avez pas besoin d'un port-profil spécial de veth pour le contrôle L3.

L'installation du VEM est également beaucoup plus facile. Il n'y a aucun composant du gestionnaire de mise à jour de VMware (VUM) avec SCVMM. La capacité d'installer des composants d'extension est établie directement dans SCVMM. Si le VEM n'est pas installé sur l'hôte hyper-v, alors SCVMM copie et installe le VEM sur l'hôte hyper-v de cible automatiquement. Si vous voulez installer manuellement le VEM, c'est un double clic simple de l'application d'installateur VEM sur l'hôte. Uninstall est également un programme simple retirent du panneau de configuration. 

L'hôte hyper-v n'installe pas sur N1KV

Une erreur commune que vous pourriez rencontrer est qu'un hôte hyper-v n'est pas ajouté au N1KV par SCVMM. Il y a de plusieurs vérifications qui doivent être faites afin de dépanner cette question.

Voici une erreur typique que vous pourriez voir dans SCVMM quand les VEM installent échouent :

Vérifiez les vieilles équipes de réseau sur l'hôte hyper-v

Il pourrait y a une vieille équipe d'un autre N1KV sur l'hôte hyper-v. Si oui, vous devez supprimer la vieille équipe avant que vous ajoutiez l'hôte au N1KV. Sur l'hôte hyper-v, exécutez Powershell et sélectionnez la commande d'obtenir-NetSwitchTeam. Si une vieille équipe apparaît, alors vous devez la retirer avec la commande de retirer-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

 

Le Maximum Transmission Unit (MTU) des NIC et les N1KV ne s'assortissent pas

Des configurations de MTU dans hyper-v sont placées par NIC par les configurations NIC. Quand vous créez une équipe, des mandats de MS que les configurations de MTU de tous les NIC dans l'équipe sont identiques. 

Il y a deux manières afin de placer et vérifier des configurations de MTU. Le premier est par les configurations d'adaptateur réseau. La deuxième manière est d'utiliser Powershell. Voici un exemple qui montre l'utilisation de Powershell afin d'obtenir et placer le MTU plaçant en même temps :

PS C:\Program Files (x86)\cisco\Nexus1000V>
 Get-NetAdapterAdvancedProperty -RegistryKeyword
 *jumbo* -Name ? <adapter name>"
| Set-NetAdapterAdvancedProperty
 -RegistryValue <mtu value>

La nouvelle configuration ne fonctionne pas en raison de configuration éventée/vieille N1KV

Vous pourriez rencontrer une question où il y a une configuration éventée N1KV sur l'hôte hyper-v qui ne la permet pas à ajouter à la nouvelle configuration. Habituellement quand vous supprimez le vieux N1KV de SCVMM ou de gestionnaire hyper-v, il nettoie la configuration. Cependant, il pourrait y a un cas où vous devez vérifier et supprimer la vieille configuration N1KV du registre hyper-v d'hôte.

Sélectionnez la commande de Regedit, et supprimez la configuration N1KV à cet emplacement :

HKEY_LOCAL_MACHINE\SYSTEM > CurrentControlSet > Services > VMSMP >
  Parameters >SwitchList

Après que vous supprimiez l'entrée dans le registre, nettoyez par l'intermédiaire du gestionnaire hyper-v et redémarrez. 

Les gestionnaires exigés ne sont pas erreur trouvée

Vous pourriez recevoir une erreur que les gestionnaires ou les MSI exigés ne sont pas trouvé quand vous tentez d'ajouter un hôte hyper-v au N1KV. Voici un échantillon de l'erreur de la fenêtre des travaux :

Ceci signifie habituellement que le code N1KV VEM n'existe pas sur le serveur SCVMM. Le serveur SCVMM doit vérifier l'extension qui est installée sur l'hôte hyper-v. Même si le code VEM est déjà installé sur l'hôte hyper-v, l'installateur N1KV VEM doit être copié sur un répertoire sur le serveur SCVMM.

Vérifiez que l'installateur N1KV VEM est copié sur des gestionnaires d'extension de C:\ProgramData\Switch sur le serveur SCVMM. S'il n'existe pas, alors copie le fichier sur le répertoire, et ajoutent l'hôte hyper-v au N1KV.

Le module VEM n'apparaît pas sur le VSM

Dans ce cas, tout semble fonctionner dans SCVMM, mais le module n'apparaît jamais sur le VSM. Il est rare que ceci se produise avec hyper-v, puisque la configuration est si simple. Quand il se produit, il y a peu de choses simples à essayer.

Redémarrez le processus N1KV sur l'hôte hyper-v

Employez le gestionnaire de 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 un tir d'écran du service N1KV dans le gestionnaire de tâches - cliquez avec le bouton droit-le, et sélectionnez la reprise :


L'équipe VEM n'est pas créée correctement

Quand vous créez le commutateur logique dans SCVMM, vous ne pouvez choisir aucune équipe ou équipe. Avec le N1KV, vous devez toujours choisir l'équipe, même si vous faites relier seulement un NIC.

Voici un tir d'écran qui illustre où placer la configuration d'équipe pour le commutateur logique :

Tous les ports VETH sont vers le bas après une Hôte-réinitialisation

Hyper-v est très capable à cet égard ; s'il voit que des VMs sont mises sous tension, et que la gestion a émis une réinitialisation, elle fait une pause l'état des VMs et des réinitialisations. Quand le système revient en ligne, il tente de rapporter les VMs en ligne dès que possible. Ceci suppose que vous vivant-n'avez pas migré toutes les VMs outre de l'hôte avant la réinitialisation.

Le problème est qu'hyper-v rapporte aux VMs en ligne avant que le processus VEM commence réellement. Le contournement est de placer les VMs avec un retard de démarrage automatique. L'ingénierie recommande qu'un trente-deuxième retard soit utilisé afin de permettre au VEM et au VSM pour communiquer avant que les essais hyper-v à reprendre/mettent sous tension toutes les VMs.

 

Incapable de trouver l'erreur conforme de commutateur

Quand vous tentez de créer ou déplacer une VM au N1KV, ou vivant-de migrer une VM d'un hôte à l'autre, vous pourriez recevoir cette erreur :

C'est un message d'avertissement davantage qu'et erreur. Quoiqu'il apparaisse comme erreur dans l'écran du travail, il n'indique pas que quelque chose est sévèrement cassée. La question est que des essais SCVMM pour garder un état conforme entre elle-même, le VSM, et le VEM. Pour quelque raison, SCVMM pense de temps en temps que l'état est hors de sync, et détermine cela pour certain héberge le N1KV est non-conforme. La conformité des différents hôtes est surveillée sous la matrice > switch> logique logique du <your N1KV de switches>.

Cliquez sur les hôtes se boutonnent sur le ruban en haut de l'écran :

Si l'hôte est non-conforme, alors vous devez tenter au remediate l'hôte. Sélectionnez l'hôte qui est hors de conformité, et cliquez sur en fonction le bouton de Remediate en haut de l'écran. Ceci déclenche SCVMM au sync les données entre lui-même, le VSM, et le module VEM. Après quelques minutes, les modifications d'état à conforme, et vous ne voyez aucune erreur.

Remarque: L'état de conformité ne met pas à jour toujours immédiatement à conforme. Attendez une minute ou deux et les essayez de nouveau si cela ne fonctionne pas.

D'autres questions et commandes utiles

Cette section décrit plusieurs questions diverses et commandes utiles pour N1KV sur hyper-v. 

VSM ne peut pas être imbriqué sur hyper-v

Vous ne pouvez pas actuellement exécuté le VSM sur un hôte hyper-v imbriqué. À la différence d'ESXi, pour quelque raison le VSM ne peut pas fonctionner sur un hôte hyper-v virtuel. L'ingénierie se rend compte de la question, mais c'est faible priorité à l'heure actuelle, se rende ainsi compte de cette restriction. Cependant, vous pouvez exécuter le VSM sur un hôte imbriqué d'ESXi, de sorte que soit un contournement possible.  

Queue de virtual machine (VMQ)

VMQ est presque identique à la file d'attente de périphérique de virtual machine de VMware (VMDQ). VMQ exige que le NIC physique prend en charge VMQ. Le NIC crée une file d'attente de réseau pour chaque VM sur le système, qui permet au trafic réseau pour circuler directement du hypervisor à la VM. Ceci améliore des performances du réseau pour les VMs.

Remarque: Afin d'utiliser VMQ, le NIC physique sur le système doit prendre en charge VMQ/VMDQ. Les adaptateurs en cours de carte d'interface virtuelle de Cisco ne prennent en charge pas VMQ/VMDQ.

Commandes de Powershell utilisées pour vérifier VMQ

Il y a deux commandes utiles utilisées afin de vérifier les informations VMQ par Powershell sur l'hôte hyper-v :

  • Obtenez-NetAdapterVmq
  • Obtenez-NetAdapterVmqQueue

Utilisation des commandes de Vemcmd afin de vérifier VMQ

C'est la commande principale utilisée afin d'afficher des informations sur VETHs pour lequel 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 afin de visualiser des ressources VMQ

Cette affiche des informations de commande sur les NIC physiques VMQ-activés :

>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 utiles de PowerShell

Il y a plusieurs commandes de Powershell qui tirent ou poussent des données dans le VSM. Ceci vous permet à l'installation de script et à l'orchestration des VMs au N1KV. Il te permet également pour tirer plus d'informations détaillées qui affichent des relations entre les objets SCVMM et N1KV.

Utilisation Powershell de SCVMM

Vous devez s'assurer que vous utilisez un Powershell qui a les modules d'extension SCVMM. Le moyen le plus simple d'accomplir ceci est de lancer Powershell de la console SCVMM :

La commande d'obtenir-SCPortClassification

Cette commande est utilisée afin de visualiser le lien entre une port-classification SCVMM et le port-profil N1KV auxquels il est lié :

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

La commande d'obtenir-SCVirtualNetworkAdapterExtensionPortProfile

Cette commande est utilisée afin de visualiser des informations sur le port-profil 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

La commande d'obtenir-SCConfigurationProvider

Cette commande est utilisée afin de visualiser 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 de Vemcmd et de Vemlog

Les commandes VEM sont disponibles au C : > fichiers de programme (x86) > Cisco > Nexus1000V.

Vérifiez l'inventaire physique d'adaptateur par le registre

Afin de vérifier la Connectivité physique d'adatper au N1KV dans le registre, accédez à cet emplacement de registre :

  • Ruche de registre : HKEY_LOCAL_MACHINE > SYSTÈME > CurrentControlSet
  • Clé de registre : Services > Nexus1000V > paramètres > HostPhyAdapters

Ne peut pas supprimer des objets N1KV dus au modèle provisoire

Vous pourriez rencontrer cette question si vous mettiez en application des modèles et construisiez des VMs par l'application de modèle de service SCVMM, et utilisateurs permis de libre-service pour créer leurs propres VMs. Ce modèle provisoire n'est pas un objet visualisable par SCVMM. Vous devez employer le SCVMM Powershell afin de supprimer le modèle provisoire avec cette commande :

 Get-SCVMTemplate | where {$_.Name -like "Temporary*"} | Remove-SCVMTemplate 

Les VMs assignées à N1KV reçoivent des erreurs logiques de conformité de commutateur

Parfois les erreurs de conformité sont juste une fonction de la manière que SCVMM fonctionne. Le N1KV pourrait être entièrement conforme dans SCVMM, mais vous recevez toujours des erreurs de conformité.

Vous pourriez également recevoir ce message, où on ne te permet pas pour ne choisir ou modifier aucun paramètre réseau pour une VM :

Ceci se produit quand un des Noeuds de la batterie de MS a des problèmes. SCVMM vous découvre que tous les Noeuds ne sont pas dans la conformité, et ne permet pas pour apporter des modifications jusqu'à ce que vous retiriez ou répariez le noeud avec le problème. C'est comportement prévu dans SCVMM.

Afin de déterminer quel noeud a les problèmes, utilisez SCVMM ou groupez le gestionnaire de Basculement, et réparez le noeud de problème. Si vous ne pouvez pas réparer le noeud, alors vous devez retirer ou faire une pause il de la batterie. Une fois que c'est complet, vous avez la capacité d'ajouter et modifier des VMs au N1KV.



Document ID: 116402