длинный выстрел, но решил, что попробую (на форуме сообщества VMware решения нет).
В гостевой системе Linux (CentOS 5.7 64-бит) с vmxnet3 vNIC мы получаем несколько сотен ошибок ядра в день на основном eth0, DMZ NIC, который обрабатывает большую часть сетевого трафика (eth1 и eth2 выполняют резервное копирование и другую нечастую сетевую активность. ).
Все 3 сетевых адаптера имеют vmxnet3 в качестве своего типа адаптера, но ошибки ядра возникают только на eth0, единственном сетевом адаптере с открытым доступом (через общедоступные IP-адреса Cisco ASA NAT).
Пример записи журнала:
Nov 2 17:49:40 localhost kernel: eth0: tq error 0x80000000
Nov 2 17:49:40 localhost kernel: eth0: resetting
Nov 2 17:49:40 localhost kernel: eth0: intr type 2, mode 0, 1 vectors allocated
Nov 2 17:49:40 localhost kernel: eth0: NIC Link is Up 10000 Mbps
Записи сбивают с толку, учитывая, что вчера eth0 отключился, и его пришлось обновить (хотя в противном случае новый сервер работал в течение 2 недель без проблем).
Собираюсь перейти на vmxnet2 в AM и посмотреть, решит ли это проблему, но ради себя и будущих людей, страдающих этой проблемой, я оставлю это там - у каждой проблемы в какой-то момент есть решение ;-)
Просто догадки.
Вы также можете попробовать использовать драйвер e1000 вместо vmxnet3. Его ограничение составляет 1 ГБ, но это может быть хорошим тестом для резервного копирования.
Просто подумайте, используете ли вы текущий уровень VMWare Tools в хост-системе? Возможно, вам придется переустановить VMWare Tools после обновления ядра.
Есть ли вероятность фактической ошибки Ethernet в самом хосте ESX?
Обновлены ли драйверы / ядра ОС?
Linux hostname 2.6.18-274.7.1.el5 #1 SMP Thu Oct 20 16:21:01 EDT 2011 x86_64 x86_64 x86_64 GNU/Linux
**** Обновление 2 ****
Патч KB для обновления 2 работает, но вам необходимо отключить TSO (в KB говорится, что это требуется только для esxi 4.1 update 1 или менее). Итак, хорошо, это работает, но нужно ли это на хосте с 4-х гигабитными сетевыми картами и локальными дисками SCSI? Возможно нет...
**** Обновление 1 ****
Обновление выпуска VMware 2 для ESXi 4.1, которое, по-видимому, решает эту проблему> esxi-update2
Только что нашел, и начало рабочего дня уже здесь; попробую завтра в ранние часы и отправлю результаты ...
**** Оригинал **** Как я уже упоминал, хост ESXi находится за Cisco ASA.
Уязвимая гость Linux использует панель управления, похожую на plesk, на которой включен программный брандмауэр APF. Я уже отключил APF и решил, что виноват не программный брандмауэр. Оказывается, завершение работы APF не сбрасывает наборы правил iptables.
Перезагрузил виртуальную машину с помощью chkconfig apf --off и вуаля, ошибки ядра eth0 исчезли ;-)
Было бы неплохо найти реальную причину (т.е. я бы действительно хотел, чтобы APF был включен, поскольку ASA не хватает аппаратных ресурсов [ограниченный процессор / память] для обработки больших списков запретов). Я проведу еще несколько тестов завтра рано утром и посмотрю, смогу ли я найти то, что APF не нравится во входящем трафике ASA NAT.
В любом случае, потратив 5 тысяч долларов на сервер виртуализации, использование новейших и лучших технологий помогает оправдать затраты (даже если в действительности, вероятно, нулевой прирост производительности между e1000 и vmxnet3 для этого умеренно загруженного хоста).
Подводя итог: vmxnet3 vNIC отлично работает на хосте Dell R610 с 64-разрядной гостевой ОС CentOS 5.7. Будет определено, почему ASA + ESXi + APF не работают вместе ...