Netwerk adapter is niet geconfigureerd voor Hyper-V maar Windows denk van wel

nvspbind

Een leuke voor de vroege morgen, het Windows logboek roept eerst:

A protocol other than the Microsoft Virtual Network Switch Protocol has been bound to NIC ‘Broadcom BCM5709C NetXtreme II GigE (NDIS VBD Client) #11’ but the NIC is being used by a virtual switch.

Om vervolgens te roepen:

The virtual switch protocol is not bound to NIC ‘Broadcom BCM5709C NetXtreme II GigE (NDIS VBD Client) #11’ but the NIC is being used by a virtual switch.

Nu moet ik eerlijk bekennen dat ik er in eerste instantie overheen heb gelezen, maar eigenlijk word hier geroepen “Er is een virtual switch die deze adapter gebruikt maar er zijn ook andere protocollen gedefinieerd” om vervolgens te roepen “Een virtual switch is geconfigureerd met deze adapter, maar het virtual switch protocol is niet gebonden aan deze adapter”. Wat nu?

Omdat ik hem in eerste instantie verkeerd had gelezen heb ik eerst het virtual network van deze hyper-v host leeg gemaakt (en de host zelf leeg gemoved binnen het cluster) om vervolgens de virtual switch te verwijderen en opnieuw aan te maken. Dit mocht niet baten. Na wat verder speurwerk kwam ik de tool “nvspbind” en “nvspbind scrub” tegen. De laatste is nogal erg rigoureus “schonen” en daar waren we nog niet. Dus begonnen met nvspbind. Door de optie /n te gebruiken krijg je een redelijk schoon adapter overzicht. Zie hier een uitgezoomd stukje:

{E2943FB1-5676-492C-ACED-7F4D15AAAE0D}
“b06bdrv\l2nd&pci_163914e4”
“Broadcom BCM5709C NetXtreme II GigE (NDIS VBD Client) #11”
“HyperV-iSCSIB-iSCSI 172.20.10.x”:

 {60B09A58-B959-44A0-95BD-7A21AC86F112}
“b06bdrv\l2nd&pci_163914e4”
“Broadcom BCM5709C NetXtreme II GigE (NDIS VBD Client) #34”
“HyperV-CustomerVswitch1”:

En daar viel mij al vrij snel op: “vSwitch is adapter 34” en de iscsi is adapter “11”. Na het extra controleren blijkt dat adapter 34 helemaal niet in gebruik zou moeten zijn maar Hyper-V dit wel denkt. Na een gedetailleerd overzicht doormideel van puur nvspbind met de adapter guid (b.v.:  {E2943FB1-5676-492C-ACED-7F4D15AAAE0D}” zien we het volgende overzicht.

{E2943FB1-5676-492C-ACED-7F4D15AAAE0D}
“b06bdrv\l2nd&pci_163914e4”
“Broadcom BCM5709C NetXtreme II GigE (NDIS VBD Client) #11”
“HyperV-iSCSIB-iSCSI 172.20.10.x”:
   disabled: ms_netbios       (NetBIOS Interface)
   disabled: ms_server        (File and Printer Sharing for Microsoft Networks)
   disabled: ms_pacer         (QoS Packet Scheduler)
   disabled: ms_ndiscap       (NDIS Capture LightWeight Filter)
   disabled: ms_wfplwf        (WFP Lightweight Filter)
   disabled: ms_msclient      (Client for Microsoft Networks)
   disabled: ms_tcpip6        (Internet Protocol Version 6 (TCP/IPv6))
   disabled: ms_netbt         (WINS Client(TCP/IP) Protocol)
   disabled: ms_smb           (Microsoft NetbiosSmb)
   enabled:  ms_tcpip         (Internet Protocol Version 4 (TCP/IPv4))
   disabled: ms_lltdio        (Link-Layer Topology Discovery Mapper I/O Driver)
   disabled: ms_rspndr        (Link-Layer Topology Discovery Responder)
   disabled: ms_pppoe         (Point to Point Protocol Over Ethernet)
   disabled: ms_ndisuio       (NDIS Usermode I/O Protocol)
   disabled: vms_pp           (Microsoft Virtual Network Switch Protocol)
   disabled: brcm_blfp        (Broadcom Advanced Server Program Driver)

Kortom, het hele virtual switch protocol staat niet aan. Nu word die leuk. Met Powershell wilde ik kijken maar kon ik niet zo snel de Hyper-V modules importeren en ik wist even niet of ik daar nu SCVMM voor moest hebben dus eerst maar een andere kleine test gedaan en dat is met nvspbind het virtual switch protocol enabled en disabled op de host. Wat testen gedaan door vm’s te moven en de melding kwam niet meer, tevens nog de host een reboot gegeven en daar was die weer. Ach, dan kunnen we in ieder geval de nvspcrub tool testen ;). Deze tool getest maar het leek nog niet weg te zijn, zelfs niet met de /p (purge all virtual switches) maar dit konden ook meldingen zijn van enkele seconden voor het runnen van de tool. Omdat de tijd begon te dringen toch ook maar het virtual netwerk aan de adapter 11 gekoppeld en weer verwijderd. Nu de host weer een reboot.

Alles werkt weer zoals het zou moeten horen. Mijn persoonlijke mening is dat het opnieuw aanmaken van een virtual switch op de 11 adapter het probleem opgelost heeft, desalniettemin vind je in deze blog wel alle documentatie waarmee je dit probleem in iedere situatie mee op moet kunnen lossen.

0 antwoorden

Plaats een Reactie

Meepraten?
Draag gerust bij!

Geef een reactie

Het e-mailadres wordt niet gepubliceerd. Vereiste velden zijn gemarkeerd met *