Bonjour,

Pareil ici, VMQ pose souci (sur carte Intel). Par contre il faut bien le
désactiver sur toute la chaine, carte réseau et VM.

Nicolas.


Le 22 nov. 2017 7:24 AM, "Julien Becker" <jul...@bckr.fr> a écrit :

Bonjour,
Exactement le même problème chez certains clients. Le fait de désactiver
les VMQ avait solutionné le problème.

Envoyé de mon iPhone

Le 22 nov. 2017 à 07:12, Guillaume DESNOUES <Guillaume.DESNOUES@cabinet-
rostan.fr> a écrit :

Bonjour,



On a eu un problème sur une conf équivalente (sauf carte réseau en Team):



Un problème connu sur les cartes broadcom qui arrive de façon aléatoire :

Il faut *désactiver *les VMQ sur les cartes réseau physique : « file
d’attentes machine virtuelles »

Attention ça coupe le réseau quelques secondes..

https://support.microsoft.com/en-us/kb/2986895

Il faut le faire sur toutes les cartes physiques de l’hyper V..





<image001.png>







Si ça peut aider



Guillaume



*De :* FRsAG [mailto:frsag-boun...@frsag.org <frsag-boun...@frsag.org>] *De
la part de* Olivier Vailleau
*Envoyé :* mardi 21 novembre 2017 22:08
*À :* French SysAdmin Group <frsag@frsag.org>
*Objet :* [FRsAG] [TECH][HyperV] Plantage de VM sous hyperV 2012R2 - lié au
network



Bonjour à toute la liste,

Nous faisons face à un souci aléatoire mais fréquent de plantage de
machines virtuelles hyperV chez plusieurs de nos clients et j'aurais voulu
savoir si quelqu'un avait déjà rencontré ce cas.



Voici le contexte :
- sur des serveurs HP Gen8 ou 9 , avec des cartes LAN Broadcom, Hyperviseur
Win2012 R2.
- très peu de machines par hyperviseur : typiquement 4 ou 5, même si cela
arrive sur des hyperviseurs (un peu) plus chargés et aussi sur d'autre
glandeurs où l'on a que 2 vm.

- les VM ont chacune une carte physique dédiée, RAM et CPU oversizés (AMHA)

- les VM sont toutes en Windows 2008 R2 ou 2012 R2.

- peu importe l'uptime de l'hyperv ou des vm (on a rencontré des cas de
plantages avec un uptime à 5mn et d'autres à 200 jours)

- ce sont des petites infra de PME (genre 15 pc, 2 laser, 1 serveur, 3-4vm)
: pas de quoi pourrir un réseau en broadcast



Quand le "plantage" intervient, la vm est injoignable sur le réseau : toute
la couche réseau est inopérante, alors que la vm voit bien le lien UP. L'os
à l'intérieur de la VM continue de bien tourner (on le sait grâce à la
console hyperV). Du coté hyperV, la vm est incontrôlable : l'arrêt ET
l'extinction sont inopérants.

Si on demande à l'OS invité de s'arrêter, il fait bien son arrêt logiciel,
mais le hardware virtuel ne s'éteint pas.



La seule solution que nous avons dans ce cas est de débrancher physiquement
le câble réseau dédié à la vm (ou bien couper le switch au cul de
l'hyperV). A partir de là, tout se débloque.



Ma première piste a été d'écarter les switchs bas-de-gamme (genre Dlink 5
ports autoalimenté) que nos commerciaux facturent à prix d'or. Mais même
avec un hp procurve récent le problème s'est reproduit.



Nous avons évidement tenté les maj :

- Maj Windows des hôtes et des invités

- Upgrade firmware des switchs qui peuvent être upgradés, modif des
autonégociations, vitesse, etc

- Maj des pilotes et des firmware des cartes réseau

- Mise à jour des agent d'intégration.



Nous sommes bien embêtés car nos clients subissent ces pannes, nous leur
rajoutons des downtime le temps d'appliquer les MAJ et la situation ne
s'arrange pas.



Est-ce que parmi la liste, quelqu'un aurai déjà rencontré ce souci ?

Sans vous demander de résoudre notre problème, J'apprécierai de connaitre
vos propositions d'axes de recherche, vos idées, etc.. A plusieurs
cerveaux, on balaye plus large et y'en a toujours un qui pense à un truc
que nos esprits avaient écarté de prime abord.



Merci d'avance pour ceux qui m'ont lu et qui auront peut être une idée de
génie.



Olivier Vailleau.



_______________________________________________
Liste de diffusion du FRsAG
http://www.frsag.org/


_______________________________________________
Liste de diffusion du FRsAG
http://www.frsag.org/
_______________________________________________
Liste de diffusion du FRsAG
http://www.frsag.org/

Répondre à