Nicira Virtualization Platform. NVP Manager

В третьей части мы обратим всё свое внимание на NVP Manager, который позволит провести дальнейшую настройку NVP.

Роль NVP Manager
NVP была разработана так чтобы интегрироваться с самыми разнообразными платформами управления облаком (CMP) с помощью набора «северных» API. Фактически эти REST API реализованы в контроллерах NVP, а не NVP Manager. Менеджер предоставляет вэб интерфейс, используемый для следующих задач:

Добавление гипервизоров
Добавление транспортных нод (шлюзы и сервисные ноды)
Настройку транспортных зон
Сбор информации и отладка

NVP Manager ориентирован на настройку, а не обеспечение работоспособности NVP. Другими словами – данный компонент вы будете использовать для управления компонентами платформы NVP – шлюзами, гипервизорами, но фактическое использование возможностей NVP, создание логических сетей, логических маршрутизаторов и тому подобное, будет происходить из CMP через вызовы к REST API к контроллерам. Таким образом, я буду использовать NVP Manager для выполнения некоторых задач, которые должны выполняться в CMP, но просто потому что под рукой у меня нету CMP.

Итак, разобравшись с ролью данного компонента перед к процессу установки и настройки.

Nicira Virtualization Platrform. Контроллеры NVP

Во второй части цикла о платформе виртуализации сети от VMware я расскажу о контроллерах. Напомню, что они нужны для расчёта сетевой топологии, распространения настроек и создания логических сетей и логики распространения трафика внутри неё. Для этого контроллеры на «южную» сторону, Open vSwitch (OVS) устройства, распространяют необходимую информацию, полученную с «северного» NVP API, чем обеспечивают соответствие между логическими сетями, согласно данным полученным NVP API и транспортной сетью, обеспечиваемой программируемыми виртуальными пограничными устройствами.

Детальнее это выглядит так:

Если в транспортной сети происходит изменение – например, запускается или выключается ВМ, мигрирует на другой хост – контроллер обновляет необходимые правила маршрутизации, и состояние транспортной сети, чтобы состояние подключения ВМ соответствовало подключению ВМ к логическим сетям. К примеру, включается новая виртуальная машина, которая должна быть подключена к определённой логической сети – кластер контроллеров обновляет необходимые правила маршрутизации, чтобы включённая ВМ была подключена к требуемой виртуальной сети.

Точно так же если запрос с API вносит изменения в конфигурацию логической сети, используемой ВМ, контроллер меняет правила маршрутизации всех соответствующих устройств в сети для выполнения запроса к API.

NVP нужно три контроллера для создания кластера – что обеспечивает возможность балансировки задач между разными контроллерами, а также предоставляет отказоустойчивость необходимую для функционала, предоставляемого контроллерами.

Итак, разобравшись с ролью контроллеров перейдём к процессу сборки контроллеров.

В каких случаях трафик vMotion пойдёт по сети управления вместо vMotion

Сценарий 1: Миграция между хостами и без общего хранилища
В версии vSphere 5.1 появилась возможность одновременной миграции ВМ между хостами и датасторами. Если ВМ хранится на локальном или не общем для хостов хранилище, то vMotion использует сеть vMotion для миграции ВМ на целевое хранилище. При мониторинге сетевых интерфейсов VMkernel можно увидеть, что трафик идёт по интерфейсу управления вместо vMotion.

При миграции виртуальной машины vMotion определяет горячие и холодные данные. Активно используемые виртуальные диски и снэпшоты считаются горячими данными, тогда как нижестоящие снэпшоты и базовый диск считаются холодными данными. К примеру, представим, что у нас есть ВМ с пятью снэпшотами. Последний снэпшот считается горячими данными, и пересылается по vMotion сети, а остальные 4 снэпшота и базовый диск – холодными, и передаются по VMkernel NIC (vmk0) с помощью network file copy (NFC).

Причина того, что vMotion используется разные сети в том, что сеть vMotion зарезервирована для миграции данных для которых критична производительность. Если сеть vMotion использовать для копирования холодных данных, то вся ширина пропускания может быть занята передачей некритичных данных, что негативно повлияет на данные, которым производительность критична. Не забывайте, что всё что передается по vMotion сети напрямую влияет на производительность мигрируемой ВМ.

Во время миграции VMkernel зеркалирует все команды ввода-вывода для источника и целевого хоста. Если же процесс vMotion будет перегонять всю иерархию дисков по своей сети, то этим он отберёт канал у процесса зеркалирования запросов, что снизит производительность ВМ.

Если же у ВМ нету снэпшотов, то её диск считается горячими данными, и передаётся по сети vMotion, тогда как все остальные файлы из директории – по VMkernel сети.

Сценарий 2: Сеть управления и vMotion используют одну подсеть
Если управляющая сеть (если быть точным то первый интерфейс VMkernel) и vMotion используют одну и ту же подсеть, то vMotion будет отправлять трафик через первый интерфейс VMkernel даже если вы создадите выделенную сеть vMotion на отдельном стандартном или распределённом свитче с отдельным физическим интерфейсом. В любом случае vMotion будет обращаться к первому интерфейсу VMkernel если обнаружит совпадение подсети.

Отдельно хочу отметить, что на целевом хосте конечным интерфейсом будет интерфейс vMotion.

Я проводил онлайн исследование по результатам которого оказалось, что больше 95% респондентов используют выделенный диапазон IP адресов для vMotion сети. Тем не менее я бы хотел напомнить, что рекомендуется использовать отдельную сеть для vMotion. Сеть управления считается небезопасной сетью, и поэтому не рекомендуется использовать её для vMotion.

В случае если хост использует Multi-NIC vMotion то даже в случае использования одной подсети vMotion учитывает настройки, и использует для передачи трафика VMkernel только с активированной опцией использования для vMotion.

Если в вашем окружении используется один диапазон адресов для обоих типов сети, то я бы рекомендовал создание Multi-NIC vMotion. В случае ограниченного количества физических интерфейсов, вы можете использовать одни и тот же сетевой интерфейс для обоих VMkernel, в таком случае хоть балансировка нагрузки и не будет доступна, но VMkernel будет использовать сеть vMotion по назначению.

Источник: Frank Denneman

Nicira Virtualization Platform. Высокоуровневая архитектура

Это первая из цикла статей, описывающих более глубокое изучение мной Nicira Network Virtualization Platform (NVP). Как по мне NVP это прекрасный продукт, но о котором доступно очень мало информации: как он работает, как он настраивается и т.д - именно эту проблему я и собираюсь решить данным циклом статей. И начнём с высокоуровнего описания архитектуры.

Перед тем как начать хотелось бы прояснить взаимосвязь между NVP и NSX. Данный цикл будет акцентироваться на NVP - продукте который уже доступен, и используется некоторыми компаниями. Архитектура которую я тут буду описывать также будет применима и к стеку NSX, который VMware анонсировала в марте, так как NSX будет использовать архитектуру NVP, так что изучение NVP сейчас поможет с NSX в будущем.

Начнём с картинки - схема внизу показывает высокоуровневую архитектуру NVP:

Ключевыми компонентами являются:

• Горизонтально масштабируемый кластер контроллеров - NVP контроллеры обрабатывают расчёты сетевой топологии, предоставляют конфигурацию и распространяют настройки требуемые для создания логических сетей. Для повышения уровня доступности и масштабируемости контроллеры поддерживают возможность горизонтального масштабирования. Контроллеры поддерживают "северный" REST API, который может быть использован системами управления облаком типа OpenStack, CloudStack или же внутренними разработками каждой компании.
• Программируемый виртуальный свитч - для этой роли NVP использует Open vSwitch (OVS) - независимый проект с открытым исходным кодом, разрабатываемый самыми разными игроками рынка. OVS связывается с кластером контроллеров NVP для получения настроек и информации о логических сетях.
• "Южный" протокол коммутации - NVP использует два открытых протокола для связи между контроллерами и OVS. Для передачи настроек используется протокол OVSDB, а логических сетей - OpenFlow. Управляющий трафик протокола OVSDB между OSV и контроллерами зашифрован с помощью SSL.
• Шлюзы: шлюзы являются входом и выходом в\для логических сетей в NVP. Шлюзы могу быть как L2 (свитчинг логических сетей в NVP в физические) так и L3 (маршрутизация между логическими сетями в NVP и физическими сетями). В любом случае шлюзы поддерживают горизонтальное масштабирование для обеспечения отказоустойчивости и повышения масштабируемости L2 и L3 шлюзов, работающих на хосте.
• Протоколы инкапсуляции: для обеспечения полной независимости и изоляции логических сетей от подлежащих физических сетей NVP использует протоколы инкапсуляции для транспортировки трафика логических сетей поверх физических сетей. На данный момент NVP поддерживает Generic Routing Encapsulation (GRE) и Stateless Transport Tunneling (STT), а в будущих версиях этот список будет расширен.
• Ноды обслуживания- для разгрузки BUM трафика (Broadcast, Unknown Unicast, и Multicast) NVP опционально может использовать несколько нод обслуживания. На схеме выше они не отображены. Если не использовать ноды обслуживания BUM трафик будет обрабатываться каждым гипервизором локально.

Оригинал: Scott Lowe

VMware Metro Stretched Cluster: вопросы из зала

Задали мне вопрос, а точнее даже два, насчет механизмов работы растянутых кластеров. Ну и соотв. как их проектировать.
Предварительное условие: растянутый метрокластер поверх EMC VPLEX.

1) Нужно ли 2 vCenter?

Ответ: нет. В метрокластере работает HA, и при падении одного из сайтов vCenter будет перезапущен на оставшемся. Разумеется, vCenter должен находиться на LUN, защищенном VPLEX.

2) Что произойдет с dvSwitch, если упадет vCenter.

Ответ: ничего. Проблема может возникнуть только, если происходит полное падение инфраструктуры, и все без исключения хосты стартуют при остановленном vCenter. В случае с падением 1 сайта все иначе - все хосты на сайте 2 уже загружены, сконфигурированы и работают без проблем. Поэтому vCenter будет просто перезапущен на сайте 2 посредством HA, и вся инфраструктура продолжит свою работу.

Пример использования NetIO Control

Network I/O Control (NetIOC, NIOC) позволяет контролировать разделение сетевых ресурсов в случае борьбы за ресурсы. NIOC предоставляет дополнительный уровень контроля использования пропускной способности сети в виде лимитов и изоляции. Операции vMotion создают кратковременный скачок трафика, который пытается использовать максимум доступной пропускной способности сети. В конвергентной сети операция vMotion иметь деструктивный эффект на другие типы трафика. Принцип работы NetIOC позволяет каждому типу трафика предоставить гарантированную полосу пропускания учитывая, что все они борются за одну полосу пропускания. Данная статья относится к vSphere 5.1.

Виртуализация сетей в Software Defined Datacenter

VMware давно известна как компания, которая изменила компьютерные вычисления благодаря технологиям виртуализации серверов. Мы в Nicira решили для себя, что с помощью виртуализации хотим изменить сети так же, как VMware - компьютерные вычисления. Аналогия между серверной и сетевой виртуализацией может быть полезной, но всё же это только аналогия. Цель данного поста в том, чтобы углубиться в виртуализацию сетей – рассказать, что это такое, что это значит для индустрии, и как VMware, после покупки Nicira, собирается изменить сети.

BPDU фильтр в vSphere 5.1

BPDU (Bridged Packet Data Unit) - пакеты которыми обмениваются физические свитчи в рамках протокола Spanning Tree, который блокирует возможные петли в сети. При подключении порта на свитче STP начинает рассылать BPDU пакеты, чтобы определить должен ли данный порт пересылать данные или быть в заблокированном состоянии. Обмен пакетами происходит между всеми свитчами в сети для определения корневого свитча и построения древовидной структуры сети. Виртуальные свитчи не принимают участия в STP, и потому не отсылают BPDU, а при получении такого пакета просто его отбрасывают.

Процесс определения корневого свитча и требуемого состояния порта занимает от 30 до 50 секунд, в течение которых через данных порт данные пересылаться не могут. Если какое-либо приложение будет пытаться достучаться до данных, находящихся на данном порту, то, в итоге, столкнётся таймаутом. Для нивелирования таких задержек рекомендуется включать на свитчах Port Fast - в таком случае порт сразу будет активным, а в случае обнаружения петли будет блокирован.

Также на портах используемых для vSphere рекомендуется включать функцию BPDU Guard, которая позволяет не позволяет указанным портам вносить изменения в структуру данных STP. Изображение ниже приводит является наглядным примером того на каком уровне сети начинает работать BPDU Guard.

Что лучше: Etherchannel и IP Hash или Load Based Teaming?

Споры что лучше - Etherchannel или LBT ведутся с тех пор, как последний механизм балансировки нагрузки появился в vSphere 4.1. Основная причина споров состоит в том, что администраторы или не знают о существовании LBT, или же думают, что сетевой стек у vSphere работает как и у физических серверов - один интерфейс активен, а все остальные простаивают до момент выхода активного из строя.

Варианты тиминга сетевых интерфейсов в vSphere

С самого начала хочу отметить, что vNetwork Distributed Switch (vDS) поддерживает пять разных режимов тиминга, но не поддерживает  LACP (802.3ad) или же Dynamic Etherchannel, поддерживается только Static Etherchannel. Для использования LACP необходимо использовать Cisco Nexus 1000V или какой-либо другой сторонний vDS.

Итак, vSphere поддерживает следующие режимы работы:

IBM выпустила distributed virtual switch для vSphere 5

Буквально на днях компания объявила о выпуске собственного распределённого виртуального свитча для vSphere 5 под названием IBM System Networking Distributed Virtual Switch 5000V конкурирующего с аналогом от Cisco – Nexus 1000V.

IBM DVS 5000 заменяет собой встроенный в vSphere 5 виртуальный распределённый свитч и эмулирует аналог физического свитча от IBM.

Основными преимуществами IBM DVS 5000V являются поддержка большого количества протоколов для управления (Telnet, SSH, SNMP, TACACS+, RADIUS, и локальная командная строка), широкий набор функций (L2-L4 ACL, статическая и динамическая агрегация каналов, PVLAN, QoS и EVB) и возможность отладки с помощью протоколов SPAN, ERSPAN, sFlow, Syslog, а также мониторинг статистики ВМ.

Подробности на официальном сайте IBM.

Работа с multicast трафиком в vSphere 5

 С выходом vSphere 5 VMware также выпустила отличный документ Multicast Performance on vSphere 5.0, рассказывающий об увеличении производительности обработки multicast трафика, но при этом никак не раскрывая техническую сторону вопроса.

Когда виртуальная машина настроена на получение трафика из какой-либо multicast группы она публикует соответствующий MAC адрес через свой сетевой интерфейс, и отправляет пакет на запрашивающий добавление её в группу. Виртуальный свитч (как vSS, так и vDS) никак не изменяя пакет отправляет его на физический свитч, который на основе, и благодаря, настройкам IGMP snooping`а на уровне физического хоста определяет через какой порт отправлять какую multicast группу, а vSwitch, в свою очередь, добавляет этот MAC адрес в свою таблицу переадресации.

Когда виртуальный свитч получает multicast трафик, то он переадресовывает его виртуальным машинам, входящим в эту multicast группу. Переадресация работает, как и в случае с unicast трафиком - на основе MAC адреса получателя. Так как vSwitch отслеживает,какие именно ВМ входят в какие именно multicast группы, то трафик переадресовывается не всем ВМ и всем интерфейсам, а только необходимым.

Если виртуальная машина отправляет запрос на удаление себя из multicast группы, её MAC адрес будет удалён из таблицы переадресации, после того как неизменённый пакет будет отослан на физический свитч. Если же данная виртуальная машина была последней на данном ESXi хосте, которая получала multicast трафик, то физический свитч также удалит этот хост из списка своих интерфейсов, через которые необходимо рассылать multicast трафик.

Если виртуальная машина переезжает на другой хост с помощью vMotion, то её настройки переедут вместе с ней. Целевой хост обновит свои таблицы переадресации согласно настройкам интерфейса виртуальной машины. Чтобы избежать возможной потери трафика из-за vMotion, виртуальный свитч целевого хоста отправляет IGMP запрос в ВМ, используя её unicast MAC адрес, чтобы физический свитч сразу получил информацию о новом местоположении ВМ. Это позволяет избежать потери трафика в ожидании следующего IGMP запроса от IGMP маршрутизатора.

Обычно IGMP маршрутизатором является какой-либо роутер в сети, и требуется для работы IGMP snooping на физических свитчах, которые, в свою очередь, используют эту информацию в своих таблицах переадресации IGMP трафика, и без которой не могут обеспечить работу IGMP snooping. Маршрутизатор отправляет запрос на адрес 224.0.0.1, общую multicast группу, а все ВМ в ответ отправляют информацию о том в какие-именно multicast группы они входят. Физический свитч, получая эту информацию, обновляет свои таблицы переадресации, и начинает пересылку трафика.
NIC Teaming физических интерфейсов также поддерживается, но механизм его работы зависит от используемого способа балансировки нагрузки.

Если активны все сетевые интерфейсы, а механизм балансировки нагрузки virtual source port ID или MAC hash based, то IGMP запрос на добавление будет выслан настроенным интерфейсом, и физический свитч обновит свою таблицу переадресации, и будет отсылать multicast трафик через соответствующий порт.

Если же один или несколько интерфейсов находятся в режиме ожидания, и начинают пересылать трафик только в случае выхода из строя активного интерфейса, то vSwitch вставит в поток IGMP запрос как в случае с vMotion.

В случае использования IP hash, физический свитч видит все физические интерфейсы как один интерфейс, и не сможет отправлять multicast трафик на разные интерфейсы, так как все физические интерфейсы являются членами всех групп. Физический интерфейс, используемый для передачи трафика в vSwitch, будет выбран согласно правилам балансировки нагрузки физического свитча.

Необходимо отметить, что для правильно работы агрегации каналов с несколькими физическими свитчами они должны быть объединены в стек, чтобы ESXi их воспринимал как один.

Оригинал: Kamau Wanguhu

Standard vSwitch - часть 2

Продолжаем знакомиться с вирутальной сетевой инфраструктурой VMware vSphere. В этом посте мы рассмотрим расширенный функционал, предлагаемый VMware для vSwitch.

Начнем с функций обеспечения безопасности:

• Security
  
  • Promiscuous mode enable/disable
  • MAC Address Change enable/disable
  • Forged Transmit enable/disable

Promiscuous Mode

Wikipedia описывает Promiscuous mode как «неразборчивый» режим, в котором сетевая плата позволяет принимать все пакеты независимо от того, кому они адресованы. Этот режим используется в анализаторах сетевого трафика. Однако у нас не конкретная машина и сетевой адаптер, а vSwitch - L2 коммутатор. Хотя в целом режим похож, но он куда ближе к Port mirroring, пересылке всего трафика с указанного порта на выделенный, к которому подключают анализатор. При включении Promiscuous Mode на уровне vSwitch (портгруппы) vNIC (сетевой интерфейс ВМ) получает все пакеты, проходящие через vSwitch (портгруппу). Попробую это проиллюстрировать.

Standard vSwitch - часть 1

Существует много статей о том, как сконфигурировать сеть на VMware ESX, но они по большей части на английском, либо затрагивают возможности тонкой настройки сети. Судя по вопросам, чаще всего задаваемым мне, у многих российских администраторов не хватает как раз базовых знаний и понимания, как все работает. Постараюсь в нескольких постах раскрыть тему сетей в VMware vSphere.

Ключевой компонент виртуальной сетевой инфраструктуры vSphere - vSwitch, виртуальный L2 коммутатор. vSwitch бывает двух типов - Standard vSwitch, и c выходом vSphere 4.0 появился vNetwork Distributed vSwitch (vDS). Мы будем рассматривать Standard vSwitch, присутствующий в любой редакции vSphere, в том числе и бесплатной.

vSwitch работает под управлением гипервизора (vmkernel) и отвечает за все сетевые операции хоста, в том числе он обеспечивает прохождение управляющего трафика. Все сетевые компоненты ESX(i) хоста подключаются к vSwitch через "портгруппы", о которых мы поговорим позже. Также обращаю ваше внимание, что по умолчанию разговор пойдет об устройстве сети в ESX, на 95% совпадающем с ESXi.

vNetwork: Массовое переключение ВМ в другую портгруппу

Предположим, у вас меняется сетевая политика для виртуальных машин и вы создаете новые портгруппы. Или вы решили мигрировать на Distributed vSwitch. Соотв. есть много (поэтому вручную не вариант, или просто лень) ВМ, подключенных в одну портгруппу, и их надо переключить в другую.

Решение - PowerShell! :)

Как это сделал я для своего тестового кластера. Сначала создал Distributed vSwitch с одним аплинком (с каждого хоста) и на нем новую портгруппу для ВМ. Затем переключил пару включенных машин вручную, проверив, что они остались доступны. И оставшиеся N-цать выключенных переключил уже скриптом:

Get-Cluster "Cluster" | Get-VM | Where-Object {$_.PowerState -eq "PoweredOff"} | Get-NetworkAdapter | where { $_.Name -eq "Network Adapter 1" } | Set-NetworkAdapter -NetworkName "dv VM Network" -Confirm:$false

Строго говоря, можно переключать и включенные машины, проблем с ними не возникает.

Security: сеть для VMotion / Fault Tolerance / IP Storage

Как построить безопасную сеть и как распределить VLAN'ы и физические адаптеры?

Прежде всего нужно подчеркнуть особенности VMotion, Fault Tolerance и IP Storage трафика - он нешифрованный и передается в прямом виде. Что из этого следует?

Все три типа трафика должны быть изолированы от общей сети, в которую входит VM Network. Кстати, это и к вопросу о выборе между ESX Software iSCSI и Guest Software iSCSI. При прослушке трафика можно получить в прямом виде состояние оперативной памяти (VMotion) вместе с ключами и паролями/хэшами паролей, и дисковый ввод/вывод вместе с ценными данными.

Отделение всех трех типов трафика от общей сети является ключевым моментом в предотвращении атаки. Хорошо, но нужно ли разделять их между собой? Строго говоря, рекомендуется. Проведу простую аналогию - стоит ли хранить патроны и оружие в одном сейфе или в разных, чтобы обезопасить детей? Будет значительно труднее собрать оружие и выстрелить при разных сейфах.
С другой стороны, ответ на этот вопрос сильно зависит от степени ценности данных. В общем случае особого беспокойства нет, и все три типа трафика можно комбинировать на одном физическом коммутаторе или даже в одном VLAN. Более того, подобная конфигурация может сохранить нам порты и упростить конфигурацию. При полном отделении трафика на физическом уровне требуется как минимум три физических порта, но их ведь нужно еще и резервировать -> уже 6 портов. Пожертвовав полным физическим отделением, можно обойтись всего 3мя - поставив их по кругу для всех 3-х VMkernel в active / standby.

Про vSwitch'и. Разъяснение.

Как в конечном итоге удалось выяснить, ESX отрабатывает ситуацию нормально. А вот vCenter получает незачет.

Что же все-таки происходит, когда vSwitch уже забит по всем портам? ESX честно пишет в лог диагностическое сообщение и отключает у всех новых машин сетевые интерфейсы.

Jan 27 15:47:36 esx2.*** vmkernel: 45:06:41:21.758 cpu1:1462)Net: 1027: can't connect device: Virtual Machine Network 2: Out of resources
Jan 27 15:47:36 esx2.*** vmkernel: 45:06:41:21.782 cpu2:1462)Net: 1027: can't connect device: Virtual Machine Network 2: Out of resources
Jan 27 15:47:37 esx2.*** vmkernel: 45:06:41:22.628 cpu2:1462)Net: 1027: can't connect device: Virtual Machine Network 2: Out of resources
Jan 27 15:47:37 esx2.*** vmkernel: 45:06:41:22.638 cpu2:1462)Net: 1027: can't connect device: Virtual Machine Network 2: Out of resources

vCenter молчит. Точнее не совсем молчит, там появляется запись уровня info в Events. Но и всего только. А вы можете сколько угодно проверять физические линки и таблицы роутинга.

Интересный парадокс

Все, наверное, помнят, что у ESX есть внутренние виртуальные коммутаторы (vSwitch). И у них есть емкость портов, определяемая при создании. По дефолту, при создании из VI клиента создается 56-портовые коммутаторы (64-8). А теперь немножко магии.

Создаем 8-портовый коммутатор.



Создаем пустую виртуальную машину с 4 интерфейсами, смотрящими в данный коммутатор. Размножаем ее в количестве 6 штук (итого 24 интерфейса на 8-портовый свитч) и все включаем. О чудо! Все включились!

Пруфпики.

Грабли с ESXi Embedded

Есть ESXi на флэшке - был воткнут в один сервер, а потом в другой. А серверы соотв. воткнуты в разные коммутаторы. И начались проблемы. Сеть на том сервере, в который была флэшка воткнута сначала - не работает. И точка.
Проверяем с Cisco-водом - MAC адреса первого сервера каким-то образом оказались на втором по отчету коммутатора. А такое просто невозможно, поскольку там сетевые карты даже разных производителей. Гашу второй сервер - на первом сеть появляется и ходят пинги. Поднимаю - пропадает. В настройках сети на втором сервере MAC показываются правильные.

Резюме проблемы: при первом запуске ESXi съедает MAC адреса сервера и больше не интересуется железом, соотв. физические адаптеры он использует в качестве дырок в сеть, а вот пакеты и все остальное, формирует сам - со старыми MAC'ами. В итоге коммутаторам сносит крышу. Если требуется перенести ESXi на другой сервер, то производится страшное колдунство: сетевые интерфейсы в management network поочередно гасятся и поднимаются с сохранением настроек. Тогда ESXi съест новые адреса и будет жить долго и счастливо.

ВМ и резервирование IP по DHCP

Иногда хочется, чтобы виртуальная машина получала один и тот же IP, а статически его прописывать на машине нет желания. Тогда приходит на помощь резервирование IP на DHCP сервере, чтобы этот адрес доставался всегда только это конкретной машине. Но DHCP требует MAC адрес для данной процедуры.
В VI клиенте у включенной машины MAC нельзя скопировать из соотв. поля - оно просто заблокировано только для чтения. Вместо ползания по VI клиенту, кликания мышкой и переписывания вручную можно вытащить MAC прямо из конфига виртуальной машины. Особенно это критично для десятков машин разом - стоит лишь набросать простой скриптик.

Открываем ssh сессию на ESX сервер

#cat /vmfs/volumes/DataStore/VirtualMachine/VirtualMachine.vmx | grep Address

ethernet0.generatedAddress = "00:50:56:b7:53:29"

Если сетевых карт несколько, то выведутся MAC адреса для всех карт