Эту проблему немного сложно объяснить без базовой справочной информации. Я постараюсь уточнить вопрос позже, если это необходимо.
Изначально у меня был один размещенный сервер (Win 2008R2) со следующим диапазоном из 8 IP-адресов.
- Single NIC ( IP: x.x.128.72 -> x.x.128.79 // Subnet: x.x.255.192 // GW: x.x.128.65 )
После установки Hyper-V и настройки одного виртуального сервера на том же компьютере я хотел назначить один из IP-адресов виртуальному серверу, оставив все остальное работать в обычном режиме.
--
Во-первых, я попробовал использовать «внешнюю» сеть, но (даже после настройки IP-адресов на «виртуальном адаптере» аналогичноЗдесьно с трудом удалось заставить сеть работать).
Мне нужно было поддерживать работу сервера (иначе я бы потратил больше времени на реализацию этого подхода)
В1 ... Было ли это разумным поступком? Стоило ли мне продолжать идти по этому пути?
--
Затем я решил попробовать другой подход — установить сеть HyperV как «Внутреннюю» (видимую для управляющей ОС).
- Physical NIC ( IP: x.x.128.72 to .75 // Subnet: x.x.255.192 // GW: x.x.128.65 )
- Virtual NIC ( IP: x.x.128.78 // Subnet: x.x.255.252 // GW: x.x.128.72 )
- Gateway was the same as the IP of the physical NIC )
- Virtual OS-NIC ( IP: x.x.128.77 // Subnet: x.x.255.252 // GW: x.x.128.78 )
- Gateway was the same as the IP of the host virtual-NIC )
--
Удивительно, но этот подход действительно сработал, и мне удалось подключиться со всех следующих устройств: - Интернет к/от физической сетевой карты (xx128.72) - физическая сетевая карта (xx128.72) к виртуальной ОС-NIC (xx128.77), например, тестирование через ping + FTP - Интернет к/от виртуальной ОС-NIC (xx128.72)
--
Проблема в том, что этот подход, похоже, действует недолго (несколько часов).
По истечении этого времени, похоже, я теряю возможность подключаться из Virtual-OS-NIC к/из Интернета (но я все еще могу подключаться из хост-ОС к виртуальной ОС и из хост-ОС к Интернету)
Я перепроверил это несколько раз с теми же результатами... Я оставляю сервер включенным на несколько часов (например, на ночь), а когда возвращаюсь утром, Virtual-OS теряет возможность маршрутизации в Интернет.
--
Я не совсем уверен, что мне теперь смотреть (или я иду совершенно не в том направлении)
Одним из «возможных важных моментов» является то, что хост-ОС также запускает RRAS (маршрутизация и удаленный доступ), но это необходимо только для запуска простого VPN.
--
В2 - На какую пшеницу мне стоит обратить внимание в следующий раз? (Есть ли какие-нибудь хорошие ссылки/рекомендации, что можно попробовать)
Буду признателен за любые мысли и комментарии (даже если вы скажете мне, что я иду в неправильном направлении)
--
*РЕДАКТИРОВАНИЕ - Вторая попытка использования "Внешнего" *
Повторив попытку с «внешним» подходом, я снова не получил доступа к сети...
Затем я снял флажок «Включить идентификацию виртуальной локальной сети для управления операционной системой»… И вуаля, все ожило.
Критическая формулировка была скрыта в ссылке «подробнее об управлении виртуальными сетями», которая гласит:
Указывает идентификационный номер, который можно использовать для изоляции сетевого трафика от управляющей операционной системы.
Конечный результат...УСПЕХ(но без решения, почему это ЧАСТИЧНО работало в течение ограниченного времени)
Позже я нашел следующую запись в блоге MSDN интересной...Понимание Hyper-V VLAN
решение1
Hyper-V на самом деле не является надстройкой над Windows, это на самом деле полноценный гипервизор, который берет на себя управление. Первоначально установленная ОС затем становится корневым разделом, подчиненным Hyper-V. Так что то, что было базовой ОС, теперь технически является особой виртуальной машиной. В этом смысле «особая» виртуальная машина может иметь пропущенное оборудование (чтобы все еще казаться обычной ОС). Это конфигурация по умолчанию для почти всего оборудования после включения Hyper-V. Однако, когда вы создаете виртуальную сеть для Hyper-V, которая подключена к физическому сетевому адаптеру, Hyper-V берет на себя управление сетевым адаптером, и он больше не пропускается.
Конфигурация вашей сетевой карты должна быть следующей:
На физическом сетевом адаптере должен быть включен только протокол «Microsoft Virtual Network Switch» (единственное исключение — когда это не физический сетевой адаптер, а, например, программно настроенная группа, в таком случае обычно используется какой-то другой протокол, который нельзя отключить).
В диспетчере виртуальных сетей Hyper-V Manager создайте «Сеть», это создаст виртуальный сетевой коммутатор в Hyper-V. Сделайте его внешним, подключенным к физическому сетевому адаптеру, также установите флажок, чтобы разрешить доступ управляющей ОС. Это создаст новый vNIC для базовой ОС (помните, что это на самом деле специальная виртуальная машина, поэтому вы добавляете vNIC к этой виртуальной машине...). Новый сетевой адаптер, возможно, придется настроить для IP-адресов, взятых из старого физического сетевого адаптера (зависит от версии Hyper-V, которую вы используете, будет ли он делать это автоматически или нет).
Создавайте виртуальные машины по своему усмотрению, добавляйте к ним vNIC и подключайте эти vNIC к соответствующей виртуальной сети.
Внешние виртуальные сети подключаются к физическому сетевому адаптеру. Они позволяют виртуальным машинам подключаться к физическим сетевым адаптерам. Внутренние виртуальные сети всегда создают новый vNIC для управляющей ОС (флажка нет, это просто всегда делается). Это позволяет виртуальным машинам взаимодействовать с базовой ОС, но не с физическими сетевыми адаптерами. Частные виртуальные сети предназначены только для виртуальных машин и никак не подключаются к управляющей ОС.
Вы также упомянули проблемы с поддержанием работоспособности. Если вы не используете сетевые карты серверного уровня (в частности, Intel, Broadcom, QLogic, Emulex, NexGen, Mellanox и т. д.), ожидайте проблем. Аналогично убедитесь, что у вас последняя версия прошивки. Если вы используете чипы Via или Realtek, вы можете сэкономить время и отказаться от идеи надежных гипервизоров уровня 1 (Hyper-V, ESXi, KVM и т. д.).