Mengapa konektivitas HyperV VM saya kehilangan secara acak?


10

Saya memiliki masalah konektivitas intermiten yang aneh terjadi setiap dua minggu sekali.

Pertama konfigurasi saya: Saya menjalankan kluster failover HyperV dengan dua host fisik (node01 dan node02). Host sama-sama menjalankan server Windows Server 2008 R2 HyperV (yang gratis) dengan SP1. Pada host tersebut saya menjalankan dua VM masing-masing menjalankan Windows Server 2008 R2 Web edition dengan SP1. Server penyimpanan saya adalah Windows Storage Server 2008 yang terhubung melalui iSCSI. Host dan server penyimpanan menjalankan driver jaringan terbaru yang diunduh langsung dari situs web Intel.

Inilah masalahnya: 99,99% dari waktu, semuanya bekerja dengan sempurna. Kira-kira sekali setiap dua - tiga minggu, kedua VM akan secara bersamaan kehilangan konektivitas jaringan, baik yang masuk maupun yang keluar. Ketika ini terjadi,

  1. Saya tidak bisa RDP ke VM baik.
  2. Saya dapat RDP ke host mana pun.
  3. Saya dapat terhubung ke salah satu VM dari Failover Cluster Manager dengan mengklik kanan pada node dan memilih 'Connect to Virtual Machine'
  4. Setelah saya terhubung ke VM seperti yang dijelaskan dalam # 3 di atas, saya tidak bisa mendapatkan situs web atau mesin apa pun di LAN. Menonaktifkan dan mengaktifkan kembali koneksi jaringan virtual di dalam VM tidak memperbaiki masalah.
  5. Jika saya memindahkan VM ke node yang berbeda, itu memperbaiki masalah (untuk dua minggu ke depan).
  6. Jika saya me-reboot host dan memindahkan VM kembali ke sana, itu memperbaiki masalah (untuk dua minggu ke depan).
  7. Ketika ini terjadi, kluster failover TIDAK secara otomatis failover VM.
  8. Tidak ada entri log peristiwa yang tidak biasa pada host atau VM mana pun.

Ini telah terjadi sekitar 5 kali dengan gejala yang sama seperti yang dijelaskan di atas. Saya mencurigai ada masalah driver jaringan atau perangkat keras jaringan, tetapi karena saya sudah menjalankan driver terbaru, saya tidak yakin apa yang harus saya lakukan.

Ini adalah pencakar kepala yang nyata ... ada ide?

Memperbarui

Saya menemukan kasus yang sangat mirip di sini: Mesin Virutal kehilangan konektivitas jaringan pada Hyper V Cluster

Pembaruan 7/29/2011

Setelah menginstal perbaikan terbaru dan memperbarui driver jaringan, saya masih mengalami masalah yang sama. Menanggapi komentar yang meminta detail perangkat keras, server adalah Intel SR1670HV, yang merupakan sasis 1U yang berisi dua motherboard S5500HV independen. Komunikasi dilakukan melalui NIC terintegrasi motherboard yang merupakan Intel 82574L. Driver jaringan adalah versi 16.2.49.0.


dapatkah Anda menambahkan detial tentang perangkat keras Anda (jumlah nics)
Jim B

Merek / model NIC apa yang Anda miliki di server?
Chris S

Informasi tentang perangkat keras dan NIC ditambahkan di atas.
Mike

Sakelar merek / model apa yang Anda hubungkan?
ErnieTheGeek

Saya memiliki masalah simular dengan gambar CentOS pada server MS hyperV. Apakah Anda memiliki NIC khusus untuk setiap mesin atau NIC bersama? Setelah kami beralih ke nics khusus masalah ini hilang ... itu bukan perbaikan yang benar ...
n8whnp

Jawaban:


7

Kami dulu punya masalah seperti ini di mana saya berada. Saya tidak ingat detail pastinya, tetapi solusi terakhir berkaitan dengan alamat mac yang saling bertentangan yang ditetapkan secara dinamis ke adaptor jaringan virtual. Menjepit mereka agar tidak dinamis sangat membantu. Anda biasanya tidak ingin melakukan itu karena dapat membuat lebih sulit untuk memindahkan mesin virtual ke host yang berbeda, tetapi itu membantu kami dalam hal ini.

Bagian lainnya adalah bahwa nics fisik dibuat oleh broadcom dan kami juga memiliki kesalahan konfigurasi di sana, di mana admin sebelumnya telah mencoba secara salah untuk menggunakan utilitas broadcom untuk menyambungkan dua NIC bersama-sama pada host untuk meningkatkan bandwidth / throughput. Kami menghapus pengaturan itu dan mengonfigurasi salah satu Nics sehingga tidak memiliki IP sama sekali pada mesin host, tetapi masih dapat digunakan untuk passthrough kepada tamu virtual. Lalu kami mengatur setiap mesin virtual untuk hanya menggunakan satu nic atau yang lain, menyeimbangkan beban berdasarkan lalu lintas historis. Tentu saja itu berarti tidak ada kegagalan jika adaptor atau koneksi turun, dan kami belum mengikuti dengan baik untuk melihat apakah lalu lintas tetap seimbang dari waktu ke waktu, tetapi sejak saat itu stabil.


5

Saya sadar bahwa ini adalah pertanyaan lama, tetapi saya mengalami masalah yang sama dan menghabiskan banyak waktu untuk menyelesaikannya sehingga saya pikir saya akan membagikan solusi yang bekerja untuk saya. Saya menemukan solusi untuk masalah saya di sini:

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

Solusi dalam situasi saya adalah menonaktifkan TCP Offloading di VM. Saya akan mengutip bagian yang relevan dari tautan:

Untuk menonaktifkan TCP Offloading, saya harus membuat dan menetapkan nilai registri baru di setiap VM yang terhubung ke Broadcom 8507 Nextreme II NIC.

Saya menggunakan perubahan registri berikut untuk menonaktifkan TCP Offloading:

Kunci: HKLM \ SYSTEM \ CurrentControlSet \ Services \ Tcpip \ Parameter

Nilai (DWORD): DisableTaskOffload = 1

Setelah menonaktifkan TCP offload pada setiap VM dengan cara ini semua masalah telah selesai dan saya dapat menghubungkan beberapa VM ke satu port NIC dari Broadcom 5708 Nextreme II NIC.

Server saya memiliki Broadcom NetExtremeNIC, jadi bagi saya penyebab masalah ini jelas terkait driver, tetapi pengaturan DisableTaskOffload= 1 menyelesaikan masalah sepenuhnya untuk saya. Semoga informasi ini menghemat waktu pencarian orang lain!


1
+1, terima kasih atas tip ini, saya telah berjalan selama beberapa hari tanpa masalah.
m0dest0

1
Tidak masalah, m0dest0. Senang mendengar bahwa itu membantu Anda. :)
BruceHill

3

Saya telah mengalami sesuatu yang serupa di lingkungan Hyper-V yang lebih sederhana, dan menemukan artikel ini di Microsoft. Tampaknya sesuai dengan situasi Anda jika server web banyak digunakan.

http://support.microsoft.com/kb/974909 - Koneksi jaringan dari mesin virtual Hyper-V yang hilang hilang di bawah lalu lintas jaringan keluar yang berat pada komputer berbasis Windows Server 2008 R2


Artikel KB yang Anda referensikan adalah pra-SP1, tapi saya melakukan post-SP1 serupa yang terlihat menjanjikan: support.microsoft.com/kb/2263829
Mike

1
Saya menghapus ini sebagai jawabannya karena saya menginstal perbaikan terbaru tetapi masalahnya masih terjadi. Karenanya, pertanyaan ini tetap tidak terjawab ...
Mike

2

Kami memiliki masalah yang sama, meskipun dalam kasus kami setiap 24-48 jam. Saya akan memeriksa ulang apakah produk antivirus / firewall Anda mendukung Server 2008 dengan Hyper-V, jika tidak, coba yang lain (atau hapus sementara jika memungkinkan) produk anti-virus / firewall Anda sebagai ujian untuk melihat apakah masalah tersebut hilang. .

Setelah panggilan ke Microsoft dan beberapa upload file dump / log kemudian, mereka menentukan bahwa TrendMicro OfficeScan adalah penyebab dalam kasus kami. Kami menggunakan versi yang ternyata tidak didukung secara eksplisit di Hyper-V, setelah kami memutakhirkan ke rilis terbaru, masalahnya hilang.


2

Ini ternyata menjadi masalah perangkat keras - Saya mengisolasi masalah ke switch dikelola Netgear GSM7224v2, menggantinya dengan D-Link DGS-1024D, dan semuanya telah bekerja dengan baik sejak saat itu.

Sebagai "pelajaran," dalam hal ini saya mungkin menghabiskan 99% dari pengaturan perangkat lunak pemecahan masalah upaya diagnostik saya untuk apa yang ternyata menjadi masalah perangkat keras. Saya bahkan membayar Dukungan Microsoft $ 259 (dan menghabiskan banyak waktu di telepon dengan mereka) untuk membantu saya mengetahuinya dengan melihat-lihat pengaturan perangkat lunak. Saya kira moral ceritanya adalah mencurigai perangkat keras Anda seperti halnya perangkat lunak Anda.


1

Pada properti adaptor jaringan untuk tamu VM, sudahkah Anda menonaktifkan Paket Jumbo dan Pembongkaran Kirim Besar? Berdasarkan pengalaman saya dengan pengaturan ini, saya pasti akan mencobanya.


Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.