Почему виртуальная машина не видит сеть?

Проверяйте путь последовательно: VM/vNIC → виртуальный коммутатор или bridge → uplink → физический коммутатор → L3-сеть. Сначала убедитесь, что виртуальный адаптер VM подключён и включён при запуске, а в гостевой ОС интерфейс находится в активном состоянии. Затем проверьте, что VM подключена к нужной Port Group, Hyper-V Virtual Switch или bridge и для неё указан правильный VLAN tag, если он используется. На хосте убедитесь, что физический NIC, используемый как uplink, виден гипервизору и имеет link. На физическом коммутаторе проверьте, что порт настроен по принятой схеме: access для одного нетегированного сегмента или trunk с разрешёнными VLAN для нескольких сегментов. Внутри VM проверьте получение IP-адреса, маску, шлюз и маршрут по умолчанию, после чего протестируйте доступность шлюза и только разрешённых схемой узлов. Если проблема сохраняется, возвращайтесь к VLAN, uplink и IP-параметрам, не затрагивая рабочий management-доступ.

Может ли Hyper-V External Switch отключить сеть у хоста?

Перед созданием External Switch определите, не является ли выбранный физический NIC единственным непроверенным путём управления хостом. Сверьте MAC-адрес адаптера, порт физического коммутатора и VLAN, которые разрешены на этом порту. Особенно опасно выполнять изменение удалённо без локальной консоли или out-of-band-управления. Если management OS должна сохранить связь через этот путь, при создании External Switch ей нужно предоставить доступ к адаптеру. После создания коммутатора Hyper-V использует для хоста виртуальный Ethernet-интерфейс, поэтому необходимо проверить его IP-параметры и доступность management-адреса. При потере связи используйте локальную либо out-of-band-консоль, чтобы вернуть прежнюю привязку или сетевые параметры. Такие работы следует выполнять в согласованное окно с подготовленным планом отката.

Что означает VLAN ID 4095 в Port Group ESXi?

Для vSphere Standard Switch VLAN ID назначается в Port Group. Значение 0 означает передачу кадров без VLAN-тега. Значения от 1 до 4094 применяют, когда ESXi добавляет и удаляет тег VLAN для подключённых к этой Port Group интерфейсов. Значение 4095 имеет специальное назначение — Virtual Guest Tagging. В этом режиме ESXi не назначает VM одному VLAN: гостевая ОС или виртуальное сетевое устройство само принимает и обрабатывает трафик нескольких VLAN с тегами. Такой режим нужен только если гость действительно должен работать с несколькими VLAN. Физический порт коммутатора и uplink должны пропускать все VLAN, предусмотренные схемой. Совпадения названия Port Group недостаточно: должны совпадать фактический VLAN и путь до нужной L3-сети.

Нужны ли отдельные NIC для management, VM и storage?

Не всегда. Логического разделения VLAN достаточно, если допустимы общий физический канал и общий отказовый домен, пропускной способности хватает, а политика безопасности и требования платформы это разрешают. Отдельные NIC, коммутаторы или независимые пути нужны для физической изоляции, предсказуемой полосы, независимой отказоустойчивости или совместимости.

Защищает ли VLAN management-сеть от пользовательского трафика?

Нет, VLAN сам по себе не является самостоятельной защитой. Он разделяет L2-широковещательные домены, но доступ между сегментами определяют маршрутизация, ACL, firewall и учётные записи управления. Не следует подключать management-интерфейс к пользовательскому VLAN только потому, что оба потока идут по одному кабелю.

Сети VM в ESXi, Hyper-V и Proxmox VE: vSwitch, VLAN и bridge

Сеть виртуальной машины строится по цепочке: VM/vNIC → виртуальный коммутатор или bridge → uplink → физический коммутатор. Сначала определяют сегменты и VLAN, затем согласуют порты физических коммутаторов, создают логические подключения на хосте и назначают их VM или служебным интерфейсам. Эта статья рассматривает виртуализацию сети на уровне ESXi, Hyper-V, Proxmox VE и KVM/libvirt; SDN, overlay-сети и сетевые функции здесь не разбираются.

Из чего состоит виртуальная сеть

У виртуальной машины есть один или несколько виртуальных сетевых адаптеров — vNIC. Каждый vNIC получает MAC-адрес и подключается к виртуальной сети так же, как физический адаптер подключается кабелем к физическому коммутатору. Виртуальный коммутатор передаёт кадры между VM на том же хосте и, если у него есть uplink, во внешнюю физическую сеть.

Уровни пути от гостевой ОС до физической сети

Элемент	Назначение	Пример
vNIC VM	Интерфейс гостевой ОС	Ethernet-адаптер `eth0` или `Ethernet` внутри VM
Виртуальная сеть	Соединяет vNIC, служебные интерфейсы хоста и правила VLAN	Port Group, Hyper-V Virtual Switch, Linux bridge
Физический uplink	Связывает сеть хоста с физическим коммутатором	Физический NIC сервера
Порт физического коммутатора	Принимает нетегированный трафик или несколько VLAN с тегами	Access- или trunk-порт по принятой схеме
L3-сеть	Определяет IP-подсеть; адрес и шлюз назначаются статически или через DHCP, а маршрутизатор обеспечивает обмен с другими сетями	DHCP-сервер, маршрутизатор, firewall

Виртуальный коммутатор не является физическим устройством: у него нет собственных кабелей и портов ASIC, а обработку выполняет гипервизор или ОС хоста. Но правила коммутации остаются похожими: сеть может быть изолированной внутри хоста, подключённой к одному VLAN или иметь выход через uplink. Для доступа за пределы хоста мостовой модели нужен корректно подключённый физический NIC и настроенный порт коммутатора.

В NAT-модели хост транслирует адреса VM и сам должен иметь внешнюю связность. В routed-модели хост либо внешний маршрутизатор направляет трафик между подсетями. Такие режимы удобны для лаборатории или отдельных сервисов, но не равны простому подключению VM к корпоративному VLAN.

Какие потоки разделять

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

Типовое логическое разделение трафика

Сегмент	Что передаётся	Кому обычно нужен доступ
Management	Управление хостом и платформой виртуализации	Администраторы и системы управления
VM production	Прикладной трафик гостевых ОС	Пользователи, приложения и разрешённые внешние системы
Storage	Доступ хостов к уже подготовленному сетевому хранилищу	Хосты и системы хранения
Migration	Передача состояния VM при миграции	Узлы кластера
Backup или replication	Резервное копирование и репликация, если их выделяют отдельно	Хосты, VM и средства защиты данных

Логического разделения по VLAN достаточно, если допустимы общие физические каналы и общий отказовый домен, суммарной пропускной способности хватает, а политика безопасности и требования платформы разрешают совместное использование. VLAN разделяет широковещательные домены и позволяет ограничивать обмен правилами сети, но не создаёт отдельную физическую полосу и не заменяет физическую изоляцию.

Выделенные NIC, отдельные коммутаторы или независимые пути нужны, когда требуется независимый отказовый домен, предсказуемая полоса, физическое разделение либо этого требует совместимость выбранной платформы, адаптеров или системы хранения. Расчёт числа портов, полосы и отказоустойчивости рассматривается отдельно в статье «Как спроектировать виртуальную инфраструктуру для продакшена и 1С».

VLAN не является самостоятельной защитой

VLAN задаёт границу L2-сегмента, но доступ между сегментами определяется маршрутизацией, ACL, firewall и учётными записями управления. Не подключайте management-интерфейс к пользовательскому VLAN только потому, что оба трафика идут по одному кабелю.

Сопоставление терминов ESXi, Hyper-V, Proxmox VE и libvirt

Задача	ESXi	Hyper-V	Proxmox VE	KVM/libvirt
L2-сеть на хосте	vSwitch	Виртуальный коммутатор Hyper-V	Linux bridge или Open vSwitch	bridge, virtual network или direct connection
Логическое подключение VM	Port Group	Подключение vNIC к выбранному virtual switch	Bridge и параметры сетевого устройства VM	Network/interface в XML-конфигурации VM
Интерфейс самого хоста	VMkernel-адаптер	vEthernet-адаптер management OS при внешнем switch	IP-интерфейс на bridge или VLAN-интерфейсе	Интерфейс Linux-хоста
Выход во внешнюю сеть	Физический uplink vSwitch	External switch, привязанный к физическому NIC	Физический NIC в составе bridge или uplink OVS	Предварительно созданный bridge либо direct connection
Изолированная сеть на одном хосте	Port Group на vSwitch без физических uplink	Private switch	Bridge без физического порта	Isolated virtual network

Не переносите действия между платформами буквально

VLAN tag в Port Group ESXi, VLAN-настройка vNIC Hyper-V и VLAN-aware bridge Proxmox VE решают сходную задачу, но применяются на разных объектах и по разным правилам. NAT-сеть libvirt также не равна Linux bridge. Перед изменениями сверяйтесь с официальным руководством именно своей платформы.

Безопасный порядок настройки сети VM

Подготовьте схему и внесите изменения без потери управления

Последовательность подходит для типовой конфигурации одного или нескольких хостов. Названия экранов, пунктов меню, доступные режимы VLAN и сетевые функции зависят от модели сервера, поколения NIC, редакции, релиза гипервизора, драйвера и firmware. Для конкретного действия используйте официальное руководство производителя платформы и документацию к сетевому адаптеру.

1
Зафиксируйте текущий management-доступ
Запишите IP-адрес, маску, шлюз, VLAN, физический NIC или uplink, через который доступен хост, и адреса средств управления. Проверьте локальную консоль или out-of-band-доступ сервера. Ожидаемый результат — вы понимаете, какой именно путь нельзя случайно отключить и как вернуть прежнюю конфигурацию.
2
Инвентаризируйте физические адаптеры
Сопоставьте имена NIC в гипервизоре с физическими портами сервера и портами коммутатора: по MAC-адресу, метке порта, индикации линка или документации сервера. Отметьте скорость, состояние link и назначение каждого порта. Если NIC не виден или link отсутствует, не назначайте на него management-сеть до устранения этой причины.
3
Составьте таблицу сегментов
Для каждого сегмента укажите назначение, VLAN ID, IP-подсеть, шлюз, DHCP или статическую адресацию, нужные физические uplink и потребителей. Минимальный результат: понятно, в какой VLAN должна попасть каждая VM, management-интерфейс и интерфейс доступа к хранилищу.
4
Согласуйте физические порты
До изменения гипервизора убедитесь, что порт физического коммутатора передаёт нужные VLAN по принятой схеме. Для одного нетегированного сегмента обычно используют access-подключение; для нескольких VLAN через один uplink — trunk с разрешённым списком VLAN и согласованным native или untagged VLAN, если он вообще используется. Ожидаемый результат — VLAN, назначенный на хосте, может пройти до нужной сети.
5
Создайте новое логическое подключение отдельно от рабочего management
Сначала создайте или проверьте сеть для VM, storage либо migration на свободном uplink или на уже подготовленном коммутаторе. Назначьте VLAN и подключите тестовую VM либо дополнительный служебный интерфейс. Не перепривязывайте существующий management uplink первым действием.
6
Проверьте путь тестовой VM
В гостевой ОС проверьте состояние интерфейса, получение IP-адреса, маршрут по умолчанию и доступность шлюза. Затем проверьте только те внутренние или внешние узлы, доступ к которым предусмотрен схемой. При неуспехе вернитесь к проверке VLAN, uplink и IP-параметров, не меняя рабочую management-сеть наугад.
7
Переносите management только в окно работ
Если нужно сменить VLAN, IP-подсеть или uplink управления, подготовьте план отката: прежние значения, доступ к консоли, ответственного за физический коммутатор и время на восстановление. Измените один элемент, подтвердите доступ по новому пути и только затем убирайте старый. Ожидаемый результат — хост доступен через новый адрес или VLAN, а предыдущая конфигурация сохранена до подтверждения.

Риск потери доступа к хосту

Перепривязка uplink, смена VLAN management-интерфейса и создание External switch в Hyper-V могут изменить связность самого хоста. Выполняйте такие изменения при наличии локальной консоли либо out-of-band-управления, в согласованное окно работ и с проверенным планом отката.

ESXi: vSwitch, Port Group, VMkernel и VLAN

В VMware ESXi стандартный vSphere Standard Switch (vSS) объединяет Port Group и физические uplink-адаптеры. К Port Group подключают vNIC виртуальных машин и VMkernel-адаптеры — служебные сетевые интерфейсы VMkernel. Для VM Port Group обычно задаёт сеть гостя, а VMkernel Port Group — сеть определённой службы хоста, например управления или доступа к хранилищу.

VLAN ID назначают в Port Group и согласуют с портом физического коммутатора. На vSphere Standard Switch значение 0 означает передачу кадров без VLAN-тега, а значения 1–4094 — VLAN, тег которого ESXi добавляет и удаляет для подключённых интерфейсов. Значение 4095 имеет специальный смысл: оно включает Virtual Guest Tagging, при котором несколько VLAN и их теги обрабатывает гостевая ОС; это не VLAN 4095. Физический порт должен пропускать все VLAN, предусмотренные выбранной схемой. Не полагайтесь на одинаковые названия сетей: совпадать должны фактический VLAN и путь до L3-сети.

Типовая настройка сети VM в ESXi

1
Проверьте vSwitch и uplink
Определите, к какому Standard Switch подключён физический NIC, и убедитесь, что uplink имеет link. Если vSwitch без uplink, VM смогут общаться только с сетями, доступными внутри этого хоста и данного vSwitch.
2
Создайте или проверьте Port Group VM
Создайте отдельную Port Group с понятным именем, например по назначению и VLAN, и назначьте ей требуемый VLAN ID. Для уже существующей Port Group сначала сверяйте VLAN и uplink: изменение общей Port Group затронет все подключённые VM.
3
Подключите vNIC тестовой VM
В настройках VM выберите созданную Port Group для нужного сетевого адаптера и убедитесь, что адаптер подключён при запуске. Ожидаемый результат — внутри гостевой ОС появляется активный интерфейс.
4
Отдельно проверьте VMkernel
Если создаётся служебная сеть, подключите VMkernel-адаптер к соответствующей VMkernel Port Group, назначьте ему IP-параметры по схеме и не смешивайте его с сетью VM без осознанного решения. Для IP-хранилища используйте уже подготовленную сеть iSCSI или NFS. Обычный Fibre Channel работает через FC-адаптеры и фабрику, а не через эту VMkernel-сеть. Настройка протоколов и систем хранения выходит за рамки статьи.

vSphere Distributed Switch (vDS) отличается от Standard Switch централизованным управлением через vCenter Server: конфигурация распределённого коммутатора применяется к нескольким хостам, добавленным в его среду. Не следует считать vDS функцией одиночного ESXi «по умолчанию». Его доступность зависит от состава лицензии или подписки, совместимой версии и архитектуры с vCenter; подробнее о роли vCenter — в статье «VMware vSphere и vCenter Server: установка VCSA и добавление хостов».

Несколько uplink в ESXi

Несколько физических адаптеров можно использовать для резервирования и распределения трафика по правилам vSwitch, но это не означает автоматического объединения полосы для одного потока. Режимы teaming, требования к агрегации на физическом коммутаторе и совместимость NIC нужно сверять с документацией Broadcom/VMware и производителя адаптера. Понятие объединения адаптеров раскрыто в глоссарии NIC Teaming.

Hyper-V: когда выбирать External, Internal и Private switch

Hyper-V создаёт виртуальные коммутаторы трёх базовых типов. Выбор определяет не только сеть VM, но и возможность связи management OS — основной ОС хоста — с этой сетью.

Типы виртуального коммутатора Hyper-V

Тип	Связность	Когда выбирать
External	VM подключаются к физической сети через выбранный физический NIC; при включённом доступе management OS хост также использует этот путь	VM должны быть доступны в корпоративной или иной внешней физической сети
Internal	Связь между VM и management OS данного хоста, без прямого подключения к физическому NIC	Локальная стендовая сеть, NAT или маршрутизация через хост
Private	Связь только между VM на одном хосте; management OS не подключается	Изолированный сегмент для взаимодействия VM на одном сервере

Для Hyper-V External Switch выбирают физический NIC, который должен выводить VM в физическую сеть. Параметр предоставления management OS доступа к этому адаптеру особенно важен: при включении Hyper-V создаёт виртуальный Ethernet-адаптер для хоста, а физический NIC становится частью внешнего virtual switch. Отключение доступа management OS может лишить хост обычной сетевой связности через этот адаптер.

Выберите и проверьте виртуальный коммутатор Hyper-V

1
Определите требуемую границу сети
Выберите External, если VM нужна физическая сеть; Internal, если сеть должна остаться между VM и хостом; Private, если общаться должны только VM одного хоста. Ожидаемый результат — выбранный тип соответствует требуемым участникам сети, а не просто названию коммутатора.
2
Для External switch подтвердите физический NIC
Убедитесь, что выбранный адаптер не является единственным непроверенным путём управления. Сверьте его MAC-адрес, подключённый порт коммутатора и разрешённые VLAN. Если этот NIC обслуживает management-хост, выполняйте изменение только с консольным доступом и планом отката.
3
Назначьте switch vNIC виртуальной машины
В настройках VM подключите её виртуальный адаптер к созданному virtual switch. При необходимости задайте VLAN для адаптера VM согласно принятой схеме и убедитесь, что физический порт пропускает этот VLAN.
4
Проверьте management OS после создания External switch
Убедитесь, что у management OS есть ожидаемый виртуальный Ethernet-интерфейс, сохранены нужные IP-параметры и хост отвечает по management-адресу. Если доступ пропал, используйте локальную или out-of-band-консоль для возврата прежней привязки или параметров.

VLAN в Hyper-V обычно задают на виртуальном сетевом адаптере VM либо на vEthernet-интерфейсе management OS — в зависимости от цели. Режим trunk к гостю используют только когда гостевая ОС или виртуальное сетевое устройство действительно должно обрабатывать несколько VLAN-тегов. Он требует согласования разрешённых VLAN на всех участках пути и повышает риск ошибочной изоляции.

Proxmox VE: Linux bridge, VLAN-aware bridge и Open vSwitch

Proxmox VE обычно использует Linux bridge: физический NIC добавляют как порт bridge, IP-адрес управления назначают bridge или соответствующему VLAN-интерфейсу, а сетевые устройства VM подключают к bridge. Bridge без физического порта остаётся внутренней сетью хоста, пока для него не настроены маршрутизация, NAT или иной выход.

VLAN-aware bridge позволяет передавать несколько VLAN через один bridge и назначать VLAN tag интерфейсу VM. При этом физический NIC и порт физического коммутатора должны пропускать требуемые VLAN. Это не то же самое, что создание отдельного Linux bridge на каждый VLAN: оба варианта возможны, но выбор зависит от схемы и возможностей используемой версии.

Типовая настройка сети VM в Proxmox VE

1
Проверьте, где расположен IP управления
Определите bridge и интерфейс, через которые доступен веб-интерфейс и SSH. Зафиксируйте адреса и шлюз до изменения портов bridge или VLAN-параметров.
2
Подготовьте bridge для нужной модели
Для сети VM с внешним доступом используйте bridge с физическим NIC как портом. Для изолированной сети создайте bridge без физического порта. Для передачи нескольких VLAN включайте VLAN-aware режим только после проверки, что физический uplink и коммутатор готовы к trunk-схеме.
3
Подключите сетевое устройство VM
В параметрах VM выберите нужный bridge. Если VM должна находиться в одном VLAN, задайте её VLAN tag согласно таблице сегментов. Ожидаемый результат — vNIC VM подключён к bridge и попадает в требуемый VLAN.
4
Примените изменения контролируемо
Перед применением сетевой конфигурации убедитесь в доступности консоли. После изменения сначала проверьте доступность самого Proxmox VE по management-адресу, затем тестовую VM. Если management-сеть недоступна, возвращайте предыдущую конфигурацию через консоль, а не продолжайте менять параметры удалённо.

Proxmox VE также может работать с Open vSwitch, но его bridge, bond, VLAN и uplink-модель отличаются от Linux bridge. Пути в веб-интерфейсе, формат сетевой конфигурации и допустимые параметры зависят от версии Proxmox VE. Для конкретной версии сверяйте руководство Proxmox VE и не смешивайте настройки Linux bridge с OVS в одной схеме без понимания их ролей.

KVM/libvirt: bridge, NAT и изолированная сеть

В libvirt виртуальная сеть может работать в NAT-, isolated- или bridge/direct-модели. NAT даёт VM выход во внешнюю сеть через хост при наличии связности у самого хоста, но входящие подключения извне обычно требуют отдельных правил. Isolated network обеспечивает связь VM внутри определённой виртуальной сети без внешнего выхода. Bridge или direct connection подключают VM к заранее подготовленному bridge либо физической сети, если это поддержано выбранной конфигурацией хоста.

Для bridge-подключения libvirt обычно не создаёт полноценную физическую схему сам по себе: Linux bridge и его uplink должны быть подготовлены на хосте заранее. Базовая подготовка KVM, QEMU и libvirt описана в статье «KVM, QEMU и libvirt в Linux: установка, VM, virsh и Guest Agent».

VLAN, trunk к гостю и специальные режимы

В типовом сценарии VLAN назначают на уровне виртуального подключения: Port Group в ESXi, vNIC или vEthernet в Hyper-V, параметр VLAN tag сетевого устройства VM на VLAN-aware bridge Proxmox VE. Физический uplink при этом передаёт теги до коммутатора, а порт коммутатора разрешает соответствующие VLAN. Назначать одинаковый VLAN и на vNIC, и внутри гостевой ОС без специально спроектированного trunk-сценария обычно не следует: это приводит к двойному тегированию или отсутствию связности.

Trunk и promiscuous mode включают только под конкретную задачу

Передача нескольких VLAN непосредственно в гостевую ОС нужна, например, виртуальному маршрутизатору, firewall или сетевому appliance. Промискуитетный режим, изменение MAC-адреса и разрешение forged transmits могут потребоваться отдельным сетевым функциям, но расширяют область видимости кадров или меняют контроль MAC. Не включайте их для обычной VM «на всякий случай»; проверьте цель, угрозы и поддержку гипервизора, драйвера NIC и физической сети.

Режимы нескольких uplink, NIC teaming, bonding, LACP и VLAN trunking имеют платформенные ограничения. Их доступность может зависеть от редакции, лицензии, релиза гипервизора, модели NIC, версии драйвера и firmware. Проверяйте совместимость по официальным compatibility guides платформы и руководству производителя сервера и адаптера, а не по совпадению названий функций.

Проверка сети после настройки

Если виртуальная машина не видит сеть, проверяйте цепочку последовательно: состояние vNIC, подключение к правильной виртуальной сети, VLAN, uplink, порт физического коммутатора, адресацию гостя, шлюз и целевой узел. Такой порядок отличает ошибку L2-подключения от ошибки IP-маршрутизации и не требует угадывать причину.

Проверьте связность тестовой VM

1
Проверьте состояние виртуального адаптера
Убедитесь в интерфейсе гипервизора, что vNIC VM подключён к нужному switch, Port Group или bridge и включён при старте. Внутри гостя интерфейс должен быть поднят. Если интерфейса нет, проверьте конфигурацию VM и драйвер гостевой ОС.
2
Проверьте IP-адрес и маршрут
При DHCP убедитесь, что VM получила адрес именно из ожидаемой подсети. При статической настройке сверяйте IP-адрес, маску или префикс, шлюз и DNS со схемой. Ожидаемый результат — есть адрес нужного VLAN и маршрут по умолчанию, если VM должна выходить за пределы своей подсети.
3
Проверьте шлюз
Отправьте ICMP-запрос к IP-адресу шлюза только если его политика допускает ответы на ICMP. Успешный ответ подтверждает базовую связность до L3-границы, но не доказывает доступность всех приложений.
4
Проверьте требуемый конечный ресурс
Проверьте разрешённый по схеме DNS-сервер, сервер приложений или внешний адрес. Для прикладного сервиса дополнительно проверяйте нужный TCP/UDP-порт штатным средством приложения. Если шлюз доступен, а ресурс нет, проблема может находиться в маршрутизации, firewall, DNS или на самом ресурсе.
5
Зафиксируйте результат
Запишите назначение сети, VLAN, имя виртуального подключения, uplink и результат проверки. Это позволит безопаснее подключать следующие VM и быстрее отличать ошибку новой конфигурации от уже существующей сетевой проблемы.

linux-guest-network-check.sh

# Состояние интерфейсов и IP-адреса
ip -br address

# Таблица маршрутизации и маршрут по умолчанию
ip route

# Проверка шлюза: замените адрес своим
ping -c 4 192.0.2.1

# Проверка DNS-имени, если DNS предусмотрен схемой
getent hosts example.internal

В Linux-госте показывает, через какой интерфейс и шлюз система попытается достичь указанного адреса. Замените `192.0.2.10` адресом разрешённого целевого узла.

ip route get 192.0.2.10

Вывод:

Ожидаемый результат — вывод содержит нужный интерфейс, исходный IP-адрес и, для другой подсети, ожидаемый шлюз.

Если проверка не проходит, не меняйте management-конфигурацию наугад. Зафиксируйте, на каком участке прерывается путь, и переходите к отдельной процедуре диагностики: «Диагностика проблем виртуальных машин и гипервизоров».

Термины в статье

Виртуализация: Технология абстрагирования физических вычислительных ресурсов, позволяющая создавать виртуальные серверы, хранилища, сети и другие логические ресурсы.
Виртуальная сеть: Виртуальная сеть — логическая сеть, реализованная программными средствами для связи ВМ и других виртуальных нагрузок между собой и, при необходимости, с физической сетью.
Виртуальный коммутатор Hyper-V: Виртуальный коммутатор Hyper-V — программный коммутатор, обеспечивающий в зависимости от типа связь между ВМ, хостом и физической сетью.
Виртуальный сетевой адаптер: Виртуальный сетевой адаптер — логический сетевой интерфейс гостевой ВМ, подключаемый к виртуальному коммутатору и имеющий собственные MAC-адрес и настройки.
Гипервизор: Программный слой, который абстрагирует ресурсы физического хоста, выполняет виртуальные машины и управляет ими.
Промискуитетный режим: Промискуитетный режим — режим интерфейса или виртуального порта, в котором доступные ему кадры принимаются независимо от MAC-адреса назначения.
Datastore: Логический контейнер хранилища в VMware для размещения файлов виртуальных машин (диски, конфигурации, логи)
Guest OS: Операционная система, установленная в виртуальной машине и работающая под управлением гипервизора; не следует путать с хостовой ОС гипервизора типа 2.
Hyper-V: Платформа виртуализации Microsoft с гипервизором типа 1, доступная как роль Windows Server и компонент Windows 10/11 Pro, Enterprise и Education.
KVM: Подсистема аппаратной виртуализации ядра Linux, предоставляющая пользовательским мониторам ВМ, обычно QEMU, интерфейс для запуска изолированных виртуальных машин.
libvirt: libvirt — открытый набор библиотек, API, служб и утилит для унифицированного управления ВМ, контейнерами, сетями и хранилищами на платформах виртуализации.
NIC Teaming: NIC Teaming — объединение нескольких сетевых адаптеров в логическую группу для резервирования канала и, в зависимости от режима, распределения сетевого трафика.
Open vSwitch: Open vSwitch — программный многоуровневый виртуальный коммутатор, соединяющий ВМ, контейнеры и физические сети и поддерживающий программное управление потоками трафика.
Port Group: Логическая группа портов виртуального коммутатора VMware с общими сетевыми настройками для подключения виртуальных сетевых и VMkernel-адаптеров.
Proxmox: Открытая платформа серверной виртуализации на базе Debian, использующая QEMU/KVM для виртуальных машин и LXC для системных Linux-контейнеров.
QEMU: QEMU — открытый эмулятор вычислительных систем и монитор виртуальных машин; в Linux он может использовать KVM для виртуализации с аппаратным ускорением.
SSH: SSH — криптографический сетевой протокол для удалённого доступа и передачи данных, аутентифицирующий стороны и защищающий сеанс от перехвата.
Uplink: Uplink — соединение или интерфейс, ведущий от устройства либо локального сегмента к вышестоящей сети; в виртуализации — подключение виртуального коммутатора к физической сети.
vCenter Server: Централизованная система управления инфраструктурой VMware для администрирования множества ESXi хостов из единого интерфейса
VMkernel: VMkernel — ядро гипервизора VMware ESXi, которое распределяет ресурсы хоста между ВМ и обрабатывает их сетевой и дисковый ввод-вывод.
VMware: VMware — бренд Broadcom и семейство продуктов виртуализации; серверная платформа vSphere объединяет гипервизор ESXi и средства управления vCenter Server.
VMware ESXi: VMware ESXi — гипервизор типа 1, устанавливаемый непосредственно на совместимый физический сервер для запуска и управления виртуальными машинами.
vSphere Distributed Switch: vSphere Distributed Switch — распределённый виртуальный коммутатор VMware, централизованно задающий сетевые политики и порты для группы ESXi-хостов через vCenter Server.
vSphere Standard Switch: vSphere Standard Switch — виртуальный коммутатор ESXi, настраиваемый отдельно на каждом хосте и связывающий ВМ, интерфейсы VMkernel и физические сетевые адаптеры.
vSwitch: Виртуальный L2-коммутатор VMware vSphere для подключения vNIC виртуальных машин и VMkernel-адаптеров; выход во физическую сеть обеспечивают uplink-адаптеры.