Недавно мы перенесли весь кластер VMware с ESX на ESXi. По большей части переход был плавным, и я не упустил доступ к SC. До нынешнего момента.
Мы пытаемся диагностировать какое-то странное поведение одноадресной лавинной рассылки, которое происходит во время vMotions, и подозреваем, что причина может быть связана с несоответствием между истечением срока действия кэша таблицы CAM коммутационного устройства и истечением срока действия таблицы ARP на каждом хосте ESXi. Таким образом, я пытался выяснить, как просмотреть и очистить таблицу ARP в ESXi.
На ESX (с полным SC) это было бы несложно - просто введите ssh и запустите arp -a. К сожалению, кастрированная оболочка в ESXi не включает команду ARP, и мне не удалось найти ни одной документации по этому поводу в базе знаний VMware.
У меня есть запрос в службу поддержки VMware по этому поводу (30 часов без ответа), но я решил сначала бросить его сюда, чтобы посмотреть, есть ли у кого-нибудь идеи. Спасибо!
Обсудив с VMware, я узнал, что нет возможности очистить или иным образом изменить таблицу ARP в ESXi 4.1. Я твердо убежден, что возможность выполнять эти действия может иметь решающее значение для устранения неполадок, и я очень надеюсь, что они добавят эту функцию в будущих версиях продукта.
Без сервисной консоли вам нужно использовать vCLI. Он работает с хостами ESX / ESXi.
Прямо сейчас я не могу найти задокументированный способ очистки таблиц ARP через RemoteCLI. Лучшее, что я могу найти, здесь: Пять лучших новых команд vCLI в vSphere 4.1
перечислить все активные соединения: esxcli network connection list
перечислить все записи таблицы ARP: esxcli network neighbor list
Надеюсь это поможет. Сообщите нам, что говорит служба поддержки.
ESXi 4.1 имеет Удаленный интерфейс командной строки вы можете использовать, или, если это не поддерживает то, что вам нужно, всегда есть неподдерживаемый путь. Однако самое приятное то, что вы используете последнюю и лучшую версию 4.1, которую вы действительно можете официально включить SSH.
Убедитесь, что у вас все порты vkernel в разных подсетях, например. отдельный vmotion / management / iscsi. Невыполнение этого требования может вызвать большое количество лавинных сообщений во время vmotion, так как физический коммутатор неправильно узнает MAC-адрес для порта vmotion. И постоянно транслирует, чтобы найти его.