Проблема с запрещением LRO в RHEL6.2

Вообщем, сегодня столкнулся с проблемой после обновления RHEL 6.1 -> 6.2. RHEL - виртуалка, хост - ESXi.

Собственно, вот что вылезло в /var/log/messages

Dec  8 10:30:18 vTestFW kernel: ------------[ cut here ]------------
Dec  8 10:30:18 vTestFW kernel: WARNING: at net/core/dev.c:1234 dev_disable_lro+0x7b/0x80() (Not tainted)
Dec  8 10:30:18 vTestFW kernel: Hardware name: VMware Virtual Platform
Dec  8 10:30:18 vTestFW kernel: Modules linked in: ppdev parport_pc parport microcode vmware_balloon i2c_piix4 i2c_core sg shpchp ext4 mbcache jbd2 sd_mod crc_t10dif sr_mod cdrom vmxnet3 vmw_pvscsi pata_acpi ata_generic ata_piix dm_mirror dm_region_hash dm_log dm_mod [last unloaded: scsi_wait_scan]
Dec  8 10:30:18 vTestFW kernel: Pid: 799, comm: sysctl Not tainted 2.6.32-220.el6.x86_64 #1
Dec  8 10:30:18 vTestFW kernel: Call Trace:
Dec  8 10:30:18 vTestFW kernel: [<ffffffff81069b77>] ? warn_slowpath_common+0x87/0xc0
Dec  8 10:30:18 vTestFW kernel: [<ffffffff81069bca>] ? warn_slowpath_null+0x1a/0x20
Dec  8 10:30:18 vTestFW kernel: [<ffffffff8142a10b>] ? dev_disable_lro+0x7b/0x80
Dec  8 10:30:18 vTestFW kernel: [<ffffffff8149118d>] ? devinet_sysctl_forward+0x14d/0x190
Dec  8 10:30:18 vTestFW kernel: [<ffffffff811e4ca7>] ? proc_sys_call_handler+0x97/0xd0
Dec  8 10:30:18 vTestFW kernel: [<ffffffff811e4cf4>] ? proc_sys_write+0x14/0x20
Dec  8 10:30:18 vTestFW kernel: [<ffffffff811765d8>] ? vfs_write+0xb8/0x1a0
Dec  8 10:30:18 vTestFW kernel: [<ffffffff810d46e2>] ? audit_syscall_entry+0x272/0x2a0
Dec  8 10:30:18 vTestFW kernel: [<ffffffff81176fe1>] ? sys_write+0x51/0x90
Dec  8 10:30:18 vTestFW kernel: [<ffffffff8100b0f2>] ? system_call_fastpath+0x16/0x1b
Dec  8 10:30:18 vTestFW kernel: ---[ end trace 38ebf833f6a2bfcc ]---
Dec  8 10:30:18 vTestFW kernel: ------------[ cut here ]------------


Недолгое гугление приводит к советам VMware отключить LRO (Large Receive Offload) на сетевых интерфейсах (http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1027511).
Пробую:

# ethtool -K eth1 lro off
Cannot set large receive offload settings: Operation not supported


Мда, забавно. Ищем в базе знаний RedHat - может чего такого уже есть - и таки да, решение найдено.
1 - Временно использовать драйвер e1000 вместо vmxnet3
2 - Запретить LRO на уровне хоста ESXi.

Я попробовал оба способа - особой разницы не заметил - оба работают. Ошибки в логах пропали, особой потери производительности нет.

PS: Как запретить LRO на уровне ESXi:

Перейти настройках Software->Advanced Settings->Net setting.
Найти параметр Net.VMxnet3SwLRO и поставить 1 вместо 0.

Дальнейший разбор полетов в RedHat продолжается, ждем нормального решения.

Литература:
RedHat KB.

VMware+RHEL6: BAR 13 can't allocate io resource

Имеется VMware ESXi 4.1u1, в нем запущена виртуалке с RHEL6.1. В лог-файле /var/log/messages заметил такие ошибки, штук 7-8
vRHEL kernel: pci 0000:00:15.7 BAR 13 can't allocate io resource.
Что же за устройства сидят на PCI-шине по такому адресу:
#lspci
00:11.0 PCI bridge: VMware PCI bridge (rev 02)
*****
00:15.5 PCI bridge: VMware PCI Express Root Port (rev 01)
00:15.6 PCI bridge: VMware PCI Express Root Port (rev 01)
00:15.7 PCI bridge: VMware PCI Express Root Port (rev 01)
*****
Слишком много, надо убрать минимум половину - меньше устройств - меньше грузиться будет, меньше памяти выделять и т.п.

Выключаем виртуалку.
Находим vmx-файл (конфигурационный файл) виртуалки vRHEL.vmx в моем случае.
ОБЯЗАТЕЛЬНО делаем резервную копию этого файла.
cp vRHEL.vmx vRHEL.vmx.good
Редактируем файл, убирая лишние записи
pciBridgeX.present = "TRUE" 
pciBridgeX.virtualDev = "pcieRootPort"
pciBridgeX.functions = "8"
pciBridgeX.pciSlotNumber = "YY" 
, где X=0..., я убрал сначала половину, потом все данные устройства.
Обязательно проверьте, что убрали ВСЕ строчки о  pciBridgeX, т.е. если убираете pciBridge1.present, то  убираете все строки с pciBridge1, иначе  может не запуститься виртуалка.
В моем случае после редактирования забыл удалить pciBridgeX.pciSlotNumber, после этого попытка запустить виртуалку закончилась ошибкой "Unable to allocate PCI sound adapter. Too many PCI devices already configured."

VMware: VM Console error "Unable to connect to the MKS"

Собственно, вот такую ошибку словил при открытии консоли виртуальной машины с VMware Client: “Unable to connect to the MKS: Failed to connect to the server shu:902”.
Shu - имя ESX-сервера, 902 - порт, по которому происходит взаимодействие между vCenter и ESX-хостами. В DNS хост внесен. оказалось это накладка с клиентом DNS локальной машины. Помогает обычный пинг, либо перезапуск службы DNS-клиента.