Чому випадково втрачається зв’язок мого HyperV VM?

У мене є дивна переривчаста проблема з підключенням, яка виникає приблизно раз на два тижні.

По-перше, моя конфігурація: я запускаю кластер HyperV з відмовою від двох фізичних хостів (node01 і node02). Хости обидва запускають сервер HyperV Windows Server 2008 R2 (безкоштовний) з SP1. На цих хостах я запускаю два VM, кожен з яких працює з веб-виданням Windows Server 2008 R2 із SP1. Мій сервер зберігання - це Windows Storage Server 2008, підключений через iSCSI. І хости, і сервер пам’яті працюють із останніми мережевими драйверами, завантаженими безпосередньо з веб-сайту Intel.

Ось проблема: у 99,99% часу все працює ідеально. Приблизно один раз кожні два - три тижні VM одночасно втрачають мережевий зв’язок, як вхідний, так і вихідний. Коли це відбувається,

1. Я не можу RDP ні в одній машині.
2. Я можу RDP на будь-який хост.
3. Я можу підключитися до VM від диспетчера відказоустойчивости, клацнувши правою кнопкою миші на вузолі та вибравши "Підключитися до віртуальної машини"
4. Після підключення до ВМ, як описано у №3 вище, я не можу потрапити на будь-які веб-сайти чи машини в локальній мережі. Відключення та повторне включення віртуального мережевого з'єднання всередині VM не усуває проблеми.
5. Якщо я переміщу VM на інший вузол, це вирішить проблему (протягом наступних двох тижнів).
6. Якщо я перезавантажую хост і переміщую VM назад на нього, це вирішує проблему (протягом наступних двох тижнів).
7. Коли це відбувається, кластер відмови НЕ автоматично відмовляється від VM.
8. Немає незвичних записів журналу подій на жодному з хостів або віртуальних машин.

Це траплялося приблизно в 5 разів з тими ж симптомами, що описані вище. Я підозрюю, що виникає проблема з драйвером мережі або мережевим обладнанням, але оскільки я вже працюю з останніми драйверами, я не знаю, що з цим робити.

Це справжня шевелюра ... якісь ідеї?

Оновлення

Тут я виявив дуже схожий випадок: Virutal Machine втрачає мережеве підключення на кластері Hyper V

Оновлення 29.07.2011

Після встановлення виправлень та оновлення мережевих драйверів я все ще відчуваю ту саму проблему. У відповідь на коментар, який запитує деталі обладнання, сервер - це Intel SR1670HV, який є шасі 1U, що містить дві незалежні материнські плати S5500HV. Зв'язок здійснюється за допомогою інтегрованих NIC-систем материнських плат, які є Intel 82574L. Мережевим драйвером є версія 16.2.49.0.

У нас раніше така проблема була там, де я перебуваю. Точних деталей я не пам’ятаю, але остаточне рішення стосувалося конфліктуючої mac-адреси, яка динамічно присвоюється адаптеру віртуальної мережі. Прив’язання тих, хто не був динамічним, дуже допомогло. Зазвичай ви не хочете цього робити, оскільки це може ускладнити переміщення віртуальної машини на інший хост, але це допомогло нам у цьому випадку.

Інша частина полягає в тому, що фізичні nics були зроблені broadcom, і ми також мали помилку конфігурації там, коли попередній адміністратор намагався неправильно використовувати утиліту broadcom для обрізання двох мікросхем разом на хості для покращення пропускної здатності / пропускної здатності. Ми видалили цю програму і налаштували одну з мікросхем, щоб вона взагалі не мала IP-адреси на хост-машині, але все ще може бути використана для проходження віртуальних гостей. Тоді ми встановлюємо кожну віртуальну машину використовувати лише одну ні та іншу, врівноважуючи навантаження на основі історичного трафіку. Звичайно, це означає відсутність відмови, якщо адаптер або з'єднання виходять з ладу, і ми не простежили, щоб переконатися, що з часом баланс трафіку був збалансований, але з тих пір він стабільно стабільний.

Я знаю, що це давнє питання, але я зіткнувся з тим самим питанням і витратив стільки часу, щоб вирішити його, що думав, що поділюсь рішенням, яке працювало на мене. Тут я знайшов рішення своєї проблеми:

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

У моїй ситуації було рішенням відключити TCP Offloading на VM. Я цитую відповідний розділ за посиланням:

Для того, щоб відключити TCP Offloading, мені довелося створити та встановити нове значення реєстру в кожному VM, підключеному до Broadcom 8507 Nextreme II NIC.

Для відключення TCP Offloading я використав таку зміну реєстру:

Ключ: HKLM \ SYSTEM \ CurrentControlSet \ Services \ Tcpip \ Параметри

Значення (DWORD): DisableTaskOffload = 1

Після відключення TCP-завантаження на кожному VM таким чином всі проблеми закінчилися, і я зміг підключити кілька VM до одного порту NIC Broadcom 5708 Nextreme II NIC.

Мій сервер має Broadcom NetExtremeNIC, тому мені здається, що причина цієї проблеми була, безумовно, пов'язана з драйверами, але налаштування DisableTaskOffload= 1 вирішило проблему повністю для мене. Сподіваємось, що ця інформація заощадить чужі години пошуків!

Я натрапив на щось подібне у набагато простішому середовищі Hyper-V і наткнувся на цю статтю в Microsoft. Здається, що відповідає вашій ситуації, якщо веб-сервери активно використовуються.

http://support.microsoft.com/kb/974909 - Мережеве підключення працюючої віртуальної машини Hyper-V втрачається під великим вихідним мережевим трафіком на комп'ютері під керуванням Windows Server 2008 R2.

У нас була ця сама проблема, хоча в нашому випадку це було кожні 24-48 годин. Я б ще раз перевірив, чи ваш антивірусний / брандмауер спеціально підтримує Server 2008 з Hyper-V, якщо ні, спробуйте інший (або тимчасово видалити, якщо можливо) ваш антивірусний / брандмауер продукт як тест, щоб побачити, чи не усунеться проблема. .

Після дзвінка до Microsoft та декількох завантажень файлів дампа / журналу пізніше вони визначили, що TrendMicro OfficeScan був винуватцем у нашому випадку. Ми використовували версію, яка виявилася, що явно не підтримується в Hyper-V, як тільки ми оновили до останнього випуску, проблема усунулася.

Це виявилося апаратним питанням - я виділив цю проблему на керований комутатор Netgear GSM7224v2, замінив її D-Link DGS-1024D, і з тих пір все працює нормально.

Як "урок, засвоєний", в цьому випадку я, ймовірно, витратив 99% своїх діагностичних зусиль на усунення неполадок програмного забезпечення на те, що виявилося проблемою з обладнанням. Я навіть заплатив за підтримку Microsoft $ 259 (і витратив чимало часу на телефон з ними), щоб допомогти мені розібратися, розібравшись в налаштуваннях програмного забезпечення. Я думаю, мораль цієї історії полягає в тому, щоб підозрювати ваше обладнання так само, як і ваше програмне забезпечення.

Що стосується властивостей мережевого адаптера для гостя VM, ви відключили пакети Jumbo і велике відправлення відправки? Виходячи з мого досвіду з цими налаштуваннями, я б неодмінно спробував це.

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

Відомо питання з мережевими адаптерами широкоспроможного 1-гігабайтного типу Broadcom.