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.desno...@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] 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/
