Виртуальная машина Hyper-V не ответит по сети
В 99% случаев предпоследний транзитный участок traceroute не будет шлюзом по умолчанию узла назначения. Это из-за способа, которым работает traceroute.
Все пакеты IP имеют - несколько неверно названный - поле времени жизни (TTL). Это поле постепенно уменьшается одним каждым маршрутизатором, который передает пакет. Если маршрутизатор постепенно уменьшает TTL к 0, он отбрасывает пакет и генерирует TTL ICMP, превысил пакет ошибок и передает его обратно человеку, который отправил исходный пакет. Пакет ошибок будет иметь целевой IP источника исходного пакета (в этом случае, хост, который инициировал traceroute). Исходный IP пакета ошибок обычно будет IP-адресом исходящего интерфейса, т.е. направлением того к остальной части сети.
Traceroute использует в своих интересах этот факт; это отправляет пакеты с последовательным увеличением TTLs; это заставляет каждый маршрутизатор в пути между источником и местом назначения передавать сообщения о недостижимости ICMP обратно хосту, выполняющему traceroute. Каждая ошибка будет иметь исходный IP заключительного маршрутизатора тестовым пакетом достигнутый прежде чем быть отброшенным. Это позволяет traceroute создавать изображение пути между источником и местом назначения.
Рассмотрите схему ниже (игнорирование возможности разнообразных путей):
________ 1.1____1.2 2.1____2.2 ________
|Host A|-----|Router 1|--- Internet ---|Router 2|-----|Host B|
-------- ---------- ---------- --------
Если хост A выполнит traceroute для хостинга B, то предпоследний транзитный участок будет маршрутизатором 2, который получит тестовый пакет следующим образом:
SrcIP: A | DstIP: B | TTL: 1
Маршрутизатор 2 постепенно уменьшит TTL к 0; который вызовет, это для генерации TTL ICMP истекло:
SrcIP: 2.1 | DstIP: A | TTL
Следовательно, когда traceroute получает это сообщение об ошибке, IP-адрес, это будет видеть предпоследний транзитный участок, будет интернет-интерфейсом направления маршрутизатора 2, а не одно направление размещает B.
Это кажется, что существует проблема с виртуальным NIC и/или взаимодействием части программного обеспечения с виртуальным NIC. Вот несколько вещей, которые можно попробовать, но мои деньги находятся, вероятно, на антивирусе/продукте брандмауэра.
Весь Ваш VM's имеет тот же антивирусный продукт? Проверьте, что Ваш антивирус/продукт брандмауэра spcefically поддерживает Сервер 2008 с Hyper-V, в противном случае попробуйте другое (или временно удаление если выполнимый) Ваш антивирус/продукт брандмауэра как тест, чтобы видеть, уходит ли проблема. Это было преступником в наших системах, каждые 24-48 часов на вид случайный VM будет терять возможность соединения, пока это не было перезагружено.
Проверьте, что Ваш антивирусный продукт в управлении/родителе ОС имеет соответствующую папку и исключения процесса (идентификатор Статьи MS: 961804)
Попытка отключить NIC разгружает функции такой, когда Большой Отправляют, Разгружаются, и CheckSum Разгружаются в сетевом адаптере VM, им включают по умолчанию в Windows, но ее возможное Ваши аппаратные средства NIC не поддерживает его (или не взаимодействует хорошо с Hyper-V), который может вызвать проблемы производительности и сетевые ошибки. Существует много способов сделать это, но самое быстрое для тестирования к (в VM), открывают свойства адаптера NIC, перейдите к вкладке "Дополнительно", и отключите разгружать функции в списке, затем перезагрузите VM. (Идентификатор Статьи MS: 951037), Этот, кажется, довольно распространенная проблема. Вы будете, вероятно, также видеть ошибки на своих сетевых коммутаторах на связанных портах, если это будет проблема.
Есть ли шанс конфликта IP-адреса? Если сервер имеет статический адрес, он накладывается с какими-либо пулами DHCP? Помните, что Ваш пул DHCP Windows не может быть единственным в Вашей среде, особенно если у Вас есть устройства как устройства VPN или контроллеры WLAN.
Там другие VMs совместно используют тот же физический сетевой интерфейс? У них все есть сетевое соединение, когда этот не делает?
Я запустил бы с основного поиска и устранения неисправностей.
- Там какие-либо другие гости работают на хосте, куда проблематичная машина работает? Если так, они испытывают какие-либо проблемы, или это изолируется к этой машине?
- В то время, когда эта машина безразлична, там что-либо еще продолжающееся в Вашей среде, которая использует много пропускной способности?
- Вам настраивали виртуальный коммутатор правильно для той гостевой машины?
- Есть ли какие-либо события, которые последовательно обнаруживаются перед Вашей ошибкой Сетевого входа в систему, которая могла бы указать на то, что продолжается?
Я heve эта та же проблема на виртуальной машине, работающей на кластере 3 серверов HV.
Один из наших виртуализированных win2003SP2 стандартных серверов останавливается для ответа через сеть, я ввожу сервер через MS SC VMM или через консоль Hyper-V на узле, где VM, и кажется, что это проиграло, это - сетевой интерфейс..., если я пытаюсь перейти к свойствам сетевого интерфейса, я не получаю окна, таким образом, я не могу сделать, Отключают/Разрешают, чтобы видеть если мужская рубашка соединения назад. У меня есть использование другого VM того же Виртуального коммутатора на сервере, и они продолжают работать без любой проблемы.
Для восстановления ситуации, я просто должен перезапустить VM или Перемещать его в другой узел Hyper-V кластера.
Я видел Журнал Системного события, и я имею, учреждают несколько мероприятий как ниже:
Тип: информация
Источник: netvsc
Категория:ничего
Идентификатор события: 4
Мини-порт 'Microsoft Virtual Machine Bus Network Adapter' сбрасывается.
Для получения дополнительной информации посмотрите Справочный центр и Центр поддержки в
.
или
Тип: предупреждение
Источник: netvsc
Категория:ничего
Идентификатор события: 5
Мини-порт 'Microsoft Virtual Machine Bus Network Adapter' подвешивается.
Для получения дополнительной информации посмотрите Справочный центр и Центр поддержки в
Но я действительно не понимаю, почему они происходят.
С наилучшими пожеланиями, Miguel Branco da Silva Лиссабон - Португалия
The following article may or may not be related....it was supposedly fixed in 2008 R2, then broken in SP1, then fixed again post-SP1 in this hotfix.
http://support.microsoft.com/kb/2263829
In my experience, this problem still exists, even after applying the hotfix.
To date, I am unable to find a way to resolve this problem. I reckon I have burned more than a week of my time turning off TCP offload and many similar settings; nothing stops the Hyper-V networking stack from failing. I’m not so sure that it is purely network load related as I can make this fail when using ARCserve to backup my Exchange 2010 VM. But it only fails part way through backing up the C: Drive. If I remove the ‘Client Agent for Windows’ and leave the Exchange agent only on the VM, then I can backup the Exchange DB over and over, without a problem. And the rate of data transfer over the (virtual) network when backing up the Exchange DB is much greater than when you backup the C: drive with thousands of little files.
So, this makes me think that it is maybe some sort of file i/o problem with the VHD? Perhaps, an SMB (does ARCserve Backup use SMB?) problem? A combination of both the high file i/o and network load? Maybe a bug in the Hyper-V Integration Services? Something is not right and I can’t believe that there isn’t more noise out there about this. I have 2 servers, at different locations that both experience this problem, albeit the symptoms and recovery are a bit different.
The other server loses the networking stack in the VM, but you have to reboot the host to recover as the VM crashes and becomes unresponsive during the reboot. So, this is more serious insofar that the whole host needs a reboot to correct the failed network on a single VM. This is the symptom reported by jwerwie in the original post.
Mucking around with MAC addresses, TCP Offload settings and so on, would appear to be a colossal waste of time.
У меня была точно такая же проблема с некоторыми моими виртуальными машинами. Особенно с виртуализацией Exchange. Проблема заключалась в "тяжелом исходящем трафике", из-за которого наша виртуальная машина теряла соединение с сетью, но в остальном выглядела нормально.
Я исправил проблему с помощью этого патча: http://support.microsoft.com/kb/ 2263829
И вдруг одна из моих виртуальных машин перестала отвечать. Любые другие виртуальные машины, находящиеся на том же хосте Hyper-V, могут пинговать сервер, но любой, кто находится за пределами VMHost, будет получать очень прерывистый ответ.
Оказывается, мой коллега запустил старый сервер, который мы использовали P2V некоторое время. тому назад. Виртуальная машина по-прежнему имела тот же MAC-адрес, что и физический сервер. В моем случае это оказалось проблемой с MAC-адресом.
Сказав это, когда я создавал свою среду Hyper-V, я отключил все функции разгрузки на сервере Broadcom nics, которые использовались Hyper-V. До этого у меня не было ни одной проблемы с сетью.