Hyper-V R2 работал бы над рабочими станциями разработчика?

Я видел подобное явление.

Признаки звучат не слишком подобными на первый взгляд: Windows Explorer иногда зависает в течение нескольких секунд независимо, получают ли к локальному диску или сетевому ресурсу доступ.

Но после некоторого расследования я полагаю, что подвешивание вызывается подобной проблемой NetBIOS.

Некоторые системные детали:

• Windows XP Pro SP3
• VMware Server 1.0.9 установлен
• VMNet1 сетевой адаптер (только для хоста) и NetBOIS по TCP/IP включен
• VMNet8 (NAT) сетевой адаптер и NetBOIS по TCP/IP включен
• Статический IP-адрес единственного физического сетевого адаптера системы 192.168.10.111. Этот адаптер настроен для использования 192.168.10.192 в качестве его единственного сервера WINS. MAC-адрес: 00-16-17-FA-2C-D4
• На адаптере VMNet1 статический IP-адрес системы 192.168.137.1. Никакой сервер WINS не настроен. MAC-адрес: 00-50-56-C0-00-01
• На адаптере VMNet8 статический адрес системы 192.168.145.1. Никакой сервер WINS не настроен. MAC-адрес: 00-50-56-C0-00-08
• Все VMs настроены для использования NAT, но останавливаются так или иначе.

Я выполнял Wireshark, весь день осуществляющий сниффинг пакетов на физическом адаптере. Я заметил, что каждый раз, когда Проводник завис в течение нескольких секунд одновременно, пакет запроса службы имен NetBIOS был отправлен на сервер WINS. Эти пакеты содержали один из адреса адаптера VMNet как его исходный IP-адрес!

Вот один из подозрительных пакетов:

Frame 25475 (92 bytes on wire, 92 bytes captured)
Ethernet II, Src: 00:16:17:fa:2c:d4 (00:16:17:fa:2c:d4), Dst: 00:15:c5:87:4f:6a (00:15:c5:87:4f:6a)
Internet Protocol, Src: 192.168.145.1 (192.168.145.1), Dst: 192.168.10.192 (192.168.10.192)
User Datagram Protocol, Src Port: netbios-ns (137), Dst Port: netbios-ns (137)
NetBIOS Name Service
  Transaction ID: 0x82a5
  Flags: 0x0000 (Name query)
  Questions: 1
  Answer RRs: 0
  Authority RRs: 0
  Additional RRs: 0
  Queries
    *<00><00><00><00><00><00><00><00><00><00><00><00><00><00><00>: type NBSTAT, class IN

Я думаю, что это не корректно. Исходный IP-адрес пакета должен быть установлен на 192.168.10.111 вместо этого.

Я не осуществил сниффинг пакетов в интерфейсе сервера WINS. Но я ожидаю, что это отправит ответ на 192.168.145.1 через его шлюз по умолчанию, так как это не подключено к 192.168.145.0 сетям. Шлюз должен отклонить этот пакет с "недостижимой сетью".

Поскольку это - пакет UDP в состоянии SYN_SENT нет никакого соединения. Но пакет SYN TCP, который "повреждается" таким же образом, должен оставить соединение в состоянии SYN_SENT, пока тайм-аут не происходит.

Некоторые вещи я пытался работать вокруг этой проблемы:

1. Отключите обоих адаптеры VMNet: проблема решена. Никакие подозрительные пакеты.
2. Повторно включите VMnet1: Проводник начинает снова зависать иногда. Подозрительные пакеты с источником 192.168.137.1.
3. Отключите VMNet1 и повторно включите VMNet8: Проводник иногда зависает. Подозрительные пакеты с источником 192.168.145.1.
4. Включите обоим адаптеры VMNet, но отключите NetBIOS по TCP/IP для обоих: проблема решена. Никакие подозрительные пакеты.
5. Повторно включите NetBIOS по TCP/IP для VMNet1: Проводник начинает снова зависать иногда. Подозрительные пакеты с источником 192.168.137.1.
6. Отключите NetBIOS по TCP/IP для VMNet1 и повторно включите его для VMNet8: Проводник иногда зависает. Подозрительные пакеты с источником 192.168.145.1.
7. Метрики интерфейса изменения от автоматической метрики до статических значений для всех интерфейсов. Сетевой адаптер, имеющий наименьшую метрику: Проводник все еще иногда зависает и подозрительный полученный packtes.

Я проверил упорядочивание адаптера в Сетевые соединения-> Усовершенствованный->, Расширенные настройки, а также путем выполнения netsh соединяют интерфейсом с IP выставочной конфигурацией. Соединение Местности является первым соединением, перечисленным в обоих местах.

Дополнительно я заметил некоторые пакеты NTP с исходным, IP-адресом 192.168.137.1 а также 192.168.145.1, отправляемым в 192.168.10.192 (это - AD DC) через физический адаптер.