Dlaczego moja maszyna wirtualna HyperV losowo traci łączność?


10

Mam dziwny sporadyczny problem z łącznością, który zdarza się raz na dwa tygodnie.

Pierwsza moja konfiguracja: korzystam z klastra pracy awaryjnej HyperV z dwoma fizycznymi hostami (node01 i node02). Na obu hostach działa serwer HyperV systemu Windows Server 2008 R2 (darmowy) z dodatkiem SP1. Na tych hostach korzystam z dwóch maszyn wirtualnych z systemem Windows Server 2008 R2 Web Edition z dodatkiem SP1. Mój serwer pamięci to Windows Storage Server 2008 podłączony przez iSCSI. Zarówno hosty, jak i serwer pamięci działają z najnowszymi sterownikami sieciowymi pobranymi bezpośrednio ze strony Intela.

Oto problem: 99,99% czasu, wszystko działa idealnie. Mniej więcej raz na dwa - trzy tygodnie maszyny wirtualne jednocześnie tracą połączenie sieciowe, zarówno przychodzące, jak i wychodzące. Kiedy to się stanie,

  1. Nie mogę RDP na żadnej maszynie wirtualnej.
  2. Mogę RDP na dowolnym hoście.
  3. Mogę połączyć się z dowolną maszyną wirtualną z Menedżera klastra pracy awaryjnej, klikając prawym przyciskiem myszy węzeł i wybierając opcję „Połącz z maszyną wirtualną”
  4. Po połączeniu się z maszyną wirtualną w sposób opisany w punkcie 3 powyżej nie mogę uzyskać dostępu do żadnych witryn ani maszyn w sieci LAN. Wyłączenie i ponowne włączenie wirtualnego połączenia sieciowego w maszynie wirtualnej nie rozwiązuje problemu.
  5. Jeśli przeniosę maszynę wirtualną do innego węzła, rozwiąże to problem (na następne dwa tygodnie).
  6. Jeśli zrestartuję hosta i przeniosę na niego maszynę wirtualną, to rozwiąże problem (przez następne dwa tygodnie).
  7. W takim przypadku klaster pracy awaryjnej NIE automatycznie przełącza maszyny wirtualnej w tryb failover.
  8. Na żadnym z hostów lub maszyn wirtualnych nie ma nietypowych wpisów w dzienniku zdarzeń.

Stało się to około 5 razy z tymi samymi objawami, jak opisano powyżej. Podejrzewam problem ze sterownikiem sieciowym lub sprzętem sieciowym, ale ponieważ już korzystam z najnowszych sterowników, nie jestem pewien, co z tym zrobić.

To prawdziwy drapak w głowie ... jakieś pomysły?

Aktualizacja

Znalazłem tutaj bardzo podobny przypadek: Virutal Machine traci łączność sieciową w klastrze Hyper V.

Aktualizacja 29.07.2011

Po zainstalowaniu poprawek i aktualizacji sterowników sieciowych wciąż mam ten sam problem. W odpowiedzi na komentarz z pytaniem o szczegóły sprzętowe, serwer to Intel SR1670HV, który jest obudową 1U zawierającą dwie niezależne płyty główne S5500HV. Komunikacja odbywa się za pośrednictwem zintegrowanych kart sieciowych na płytach głównych, którymi są Intel 82574L. Sterownik sieciowy to wersja 16.2.49.0.


czy możesz dodać dane szczegółowe na temat swojego sprzętu (liczba kart sieciowych)
Jim B

Jaką markę / model kart sieciowych masz na serwerze?
Chris S

Informacje o sprzęcie i kartach sieciowych dodane powyżej.
Mike

Jaką marką / modelem łączysz się?
ErnieTheGeek

Miałem podobny problem z obrazami CentOS na serwerze MS hyperV. Czy masz dedykowane karty sieciowe dla każdego komputera lub wspólną kartę sieciową? Po przejściu na dedykowane
karty sieciowe

Odpowiedzi:


7

Kiedyś miałem taki problem. Nie pamiętam dokładnych szczegółów, ale ostateczne rozwiązanie dotyczyło konfliktu adresu MAC przypisanego dynamicznie do wirtualnej karty sieciowej. Przypisanie ich do tego, że nie były dynamiczne, bardzo pomogło. Zwykle nie chcesz tego robić, ponieważ może to utrudnić przeniesienie maszyny wirtualnej na inny host, ale pomogło nam w tym przypadku.

Drugą częścią jest to, że fizyczne karty sieciowe zostały wykonane przez broadcom, a my również mieliśmy tam błąd konfiguracji, w którym poprzedni administrator próbował nieprawidłowo użyć narzędzia broadcom do połączenia dwóch kart sieciowych na hoście w celu zwiększenia przepustowości / przepustowości. Usunęliśmy tę konfigurację i skonfigurowaliśmy jedną z kart sieciowych, aby nie miała w ogóle adresu IP na maszynie hosta, ale nadal mogła być używana do przekazywania wirtualnych gości. Następnie ustawiamy każdą maszynę wirtualną, aby korzystała tylko z jednej lub drugiej nici, równoważąc obciążenie w oparciu o historyczny ruch. Oczywiście nie oznacza to przełączenia awaryjnego w przypadku awarii adaptera lub połączenia, a my nie sprawdziliśmy dobrze, czy ruch utrzymywał się z czasem w równowadze, ale od tego czasu jest stabilny.


5

Zdaję sobie sprawę, że to stare pytanie, ale napotkałem ten sam problem i zmarnowałem tyle czasu na jego rozwiązanie, że pomyślałem, że podzielę się rozwiązaniem, które dla mnie zadziałało. Tutaj znalazłem rozwiązanie mojego problemu:

http://invendows.wordpress.com/2008/03/06/network-issue-with-hyper-v/

Rozwiązaniem w mojej sytuacji było wyłączenie odciążania TCP na maszynach wirtualnych. Zacytuję odpowiednią sekcję z linku:

W celu wyłączenia odciążania TCP musiałem utworzyć i ustawić nową wartość rejestru w każdej maszynie wirtualnej podłączonej do karty sieciowej Broadcom 8507 Nextreme II.

Użyłem następującej zmiany rejestru, aby wyłączyć odciążanie TCP:

Klucz: HKLM \ SYSTEM \ CurrentControlSet \ Services \ Tcpip \ Parameters

Wartość (DWORD): DisableTaskOffload = 1

Po wyłączeniu odciążania TCP na każdej maszynie wirtualnej w ten sposób wszystkie problemy się skończyły i mogłem podłączyć wiele maszyn wirtualnych do jednego portu NIC Broadcom 5708 Nextreme II NIC.

Mój serwer ma Broadcom NetExtremekarty sieciowe, więc wydaje mi się, że przyczyna tego problemu była zdecydowanie związana ze sterownikami, ale ustawienie DisableTaskOffload= 1 całkowicie rozwiązało problem. Mam nadzieję, że ta informacja pozwoli zaoszczędzić komuś godziny wyszukiwania!


1
+1, dziękuję za tę wskazówkę, biegam od kilku dni bez żadnego problemu.
m0dest0

1
Nie ma problemu, m0dest0. Cieszę się, że to ci pomogło. :)
BruceHill

3

Natrafiłem na coś podobnego w znacznie prostszym środowisku Hyper-V i natknąłem się na ten artykuł w firmie Microsoft. Wydaje się, że pasuje do twojej sytuacji, jeśli serwery są intensywnie używane.

http://support.microsoft.com/kb/974909 - Połączenie sieciowe działającej maszyny wirtualnej Hyper-V zostało utracone w wyniku dużego wychodzącego ruchu sieciowego na komputerze z systemem Windows Server 2008 R2


Artykuł KB, do którego się odwołujesz, był wcześniejszy niż SP1, ale zrobiłem podobny po SP1, który wygląda obiecująco: support.microsoft.com/kb/2263829
Mike

1
Usunąłem to jako odpowiedź, ponieważ zainstalowałem poprawkę, ale problem nadal występuje. Dlatego na to pytanie pozostaje bez odpowiedzi ...
Mike,

2

Mieliśmy ten sam problem, chociaż w naszym przypadku było to co 24-48 godzin. Chciałbym dokładnie sprawdzić, czy Twój produkt antywirusowy / zapora ogniowa obsługuje spesfical Server 2008 z funkcją Hyper-V, jeśli nie, spróbuj innego (lub tymczasowo usunąć, jeśli to wykonalne) produktu antywirusowego / zapory ogniowej, aby sprawdzić, czy problem zniknie .

Po rozmowie z Microsoftem i kilku przesłanych plikach zrzutu / dziennika ustalili, że winowajcą jest w tym przypadku TrendMicro OfficeScan. Korzystaliśmy z wersji, która okazała się nie być wyraźnie obsługiwana w Hyper-V, po uaktualnieniu do najnowszej wersji problem zniknął.


2

Okazało się to problemem sprzętowym - odizolowałem problem do przełącznika zarządzanego Netgear GSM7224v2, zastąpiłem go D-Link DGS-1024D i od tej pory wszystko działa dobrze.

W ramach „wyciągniętej lekcji” w tym przypadku prawdopodobnie wydałem 99% moich wysiłków na diagnostykę oprogramowania, które okazało się być problemem sprzętowym. Zapłaciłem nawet za wsparcie techniczne firmy Microsoft w wysokości 259 USD (i spędziłem z nimi dużo czasu na telefonie), aby pomóc mi to rozgryźć, przeglądając ustawienia oprogramowania. Myślę, że morałem tej historii jest podejrzenie twojego sprzętu tak samo jak twojego oprogramowania.


1

Czy we właściwościach karty sieciowej dla gościa VM wyłączono duże pakiety i duże odciążenie wysyłania? Bazując na moim doświadczeniu z tymi ustawieniami, zdecydowanie bym tego spróbował.


Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.