Virtual switches vmware настройка
Администрирование серверов, это очень широкий круг задач, тысячи программ и сервисов со своими тонкостями и нюансами, десятки операционных систем, постоянно что-то меняется, обновляется, физически не реально знать все наизусть. Постоянно приходится сталкиваться с тем, что ставишь или настраиваешь или исправляешь что-то впервые.
При работе с новым сервером, это не так критично, можно попробовать разные варианты решения задачи, выбрав оптимальный, никто от этого не пострадает, не считая конечно личного времени. В конце концов можно все снести и настроить заново.
В случае боевого сервера, на котором работают какие-то сервисы, веб сервера, базы данных, лежат сайты, такой вариант не прокатит, могут пострадать пользовательские данные, сервис может быть недоступен длительное время со всеми вытекающими.
В такой ситуации у администратора серверов всегда должен быть безопасный полигон для испытаний, где не страшно ошибиться, где можно потрогать новую версию операционной системы или погонять какой-то софт, в общем ломай не хочу. У меня уже не первый год, таким полигоном является VMWare workstation, на которой я держу виртуальные машины с основными операционными системами, с которыми работаю — FreeBSD, различные дистрибутивы Linux, типа Debian, CentOS, Ubuntu, и с которыми не работаю тоже, просто для общего развития, например различные Windows.
Постараюсь вкратце описать процесс создания тренировочного полигона для администрирования серверов, как делаю я, то есть не вдаваясь в документацию по VMWare, в которой и так все достаточно подробно.
Итак, основная операционка - Windows 7 ultimate x64 SP1, VMWare Workstation 7.1.4, на тестовой виртуальной машине будет установлена операционная система FreeBSD 8.2 amd64.
Компьютер на котором установлена VMWare Workstation является хост-машиной, по отношению к виртуальным машинам.
Виртуальные машины, являются гостевыми системами, по отношению к хост-машине ( виртуальная машина = гостевая система ).
Структура моей сети очень проста, обычный роутер на который приходит интернет канал, внутренний IP адрес интерфейса роутера - 192.168.1.10. Поскольку машин внутри моей сети не много, 3-5, я не использую DHCP сервер роутера а назначаю статические IP адреса, мне так удобней. На рабочем компьютере, прописан IP адрес 192.168.1.11, шлюз соответственно 192.168.1.10.
Не буду расписывать процесс установки VMWare, там нет ничего сложного. После установки потребуется перезагрузка.
VMware настройка сети. Настройка виртуального коммутатора.
Выбираем наш единственный виртуальный коммутатор и нажимаем на значок сетевой карты
В открывшемся окне видим, что у нас сейчас активен один сетевой адаптер vmnic0. Жмем на зеленый плюс, чтобы добавить второй
Видим нашу вторую сетевуху, выбираем ее и группу адаптеров, в которую нужно ее добавить(в нашем случае Active adapters).
Active adapters — сетевая карта будет использоваться
Standby adapters — сетевая карта будет задействована в случае выхода из строя основной
Unused adapters — сетевая карта не будет использоваться.
На следующем экране видим, что наши адаптеры находятся в группе активных(можно поменять группу адаптера с помощью синих стрелок, а также удалить адаптер или добавить еще).
Жмем ОК и видим, что теперь в нашем свиче два сетевых адаптера(у меня подключен только один, поэтому VMware «сигналит», что отказоустойчивость потеряна.
В виртуальных свичах VMware есть сеть для виртуальных машин VM Network(сюда подключаются виртуальные машины) и VMkernel, предназначенный для служебного трафика(Management, VMotion, iscsi и т.п.).
Давайте настроим наш управляющий интерфейс, который используется для управления хостом.
Выделяем окно с заголовком Management Network и нажимаем на карандаш для редактирования.
В настройках Management Network вы можете изменить название сети, VLAN(если используется), настройки безопасности, traffic shaping(в стандартном свиче ограничивается только исходящий трафик) и режим файловера и балансировки нагрузки.
Standard vSwitch - часть 2
Продолжаем знакомиться с вирутальной сетевой инфраструктурой VMware vSphere. В этом посте мы рассмотрим расширенный функционал, предлагаемый VMware для vSwitch.
- Security
- Promiscuous mode enable/disable
- MAC Address Change enable/disable
- Forged Transmit enable/disable
Wikipedia описывает Promiscuous mode как «неразборчивый» режим, в котором сетевая плата позволяет принимать все пакеты независимо от того, кому они адресованы. Этот режим используется в анализаторах сетевого трафика. Однако у нас не конкретная машина и сетевой адаптер, а vSwitch - L2 коммутатор. Хотя в целом режим похож, но он куда ближе к Port mirroring, пересылке всего трафика с указанного порта на выделенный, к которому подключают анализатор. При включении Promiscuous Mode на уровне vSwitch (портгруппы) vNIC (сетевой интерфейс ВМ) получает все пакеты, проходящие через vSwitch (портгруппу). Попробую это проиллюстрировать.
VLAN A - любой VLAN от 1 до 4094, а VLAN B - любой другой VLAN от 1 до 4094, но не равный A. Конкретные числа не имеют значения, достаточно того, что VLAN'ы не совпадают.
Итак, чтобы увидеть, кто с кем может общаться:
Если vSwitch сконфигурирован с включенным режимом "Promiscuous Mode", то vNIC в PG_VGT сможет увидеть весь трафик vSwitch. В то же время, vNIC из PG_EST сможет увидеть только трафик внутри своей портгруппы (или любой другой портгруппы в EST режиме, VLAN = 0). В остальном таблица довольно проста для понимания, за исключением колонки PG_VGT. Строки PG_VLA, PG_VLB и PG_VLB1 содержат и "Yes" и "No" - vNIC в PG_VLA (например) сможет увидеть трафик только для VLAN A, который может включать в себя трафик для PG_VGT.
MAC Address Change
- В VDI окружении при большом количестве создаваемых и включаемых ВМ
- В среде, где ВМ стартуют на хосте-стартовой площадке, а в дальнейшем перераспределяются по другим хостам с помощью DRS.
Forged Transmit
Параметр Forged Transmit схож по своему действию с MAC Address Change, с той лишь разницей, что он затрагивает исходящий, а не входящий трафик. При "Accept" vSwitch будет обрабатывать и пересылать пакеты с "подделанным" (forged) MAC адресом. "Reject" соотв. запрещает пересылку пакетов от MAC адреса, не совпадающего с прописанным в .vmx, и заставляет vSwitch игнорировать подобные пакеты. Точно так же, без уведомления гостевой ОС.
Параметры Forged Transmit и MAC Address Change необходимо установить в "Accept" для поддержки Unicast NLB.
пятница, 22 октября 2010 г.
Standard vSwitch - часть 1
Существует много статей о том, как сконфигурировать сеть на VMware ESX, но они по большей части на английском, либо затрагивают возможности тонкой настройки сети. Судя по вопросам, чаще всего задаваемым мне, у многих российских администраторов не хватает как раз базовых знаний и понимания, как все работает. Постараюсь в нескольких постах раскрыть тему сетей в VMware vSphere.
Ключевой компонент виртуальной сетевой инфраструктуры vSphere - vSwitch, виртуальный L2 коммутатор. vSwitch бывает двух типов - Standard vSwitch, и c выходом vSphere 4.0 появился vNetwork Distributed vSwitch (vDS). Мы будем рассматривать Standard vSwitch, присутствующий в любой редакции vSphere, в том числе и бесплатной.
- Security
- Promiscuous mode enable/disable
- MAC Address Change enable/disable
- Forged Transmit enable/disable
- Average Bandwidth
- Peak Bandwidth
- Burst Size
- Active
- Standby
- Unused
- vSwitch Port Based
- MAC Address Based
- IP Hash Based
- Explicit Failover Order
- Link State
- Beacon Probing
- vSwitch не изучает MAC адреса из проходящего трафика
- vSwitches не участвует в Spanning Tree
- vSwitch не может создать сетевую петлю
- Управляюший трафик ESX Service Console
- Сетевой трафик VMkernel
- Трафик vMotion между хостами
- Трафик Fault Tolerance между хостами
- IP Storage (iSCSI и NFS) трафик
- Управляющий трафик ESXi
На одном ESX хосте можно создать до 248 Standard vSwitch (vSphere 4.0 Configration Maximums). Следующий рисунок показывает довольно распространенный вариант использования нескольких vSwitch для разделения трафика.
Важно знать одну особенность vSwitch - ВМ, подключенные к разным vSwitch на одном хосте, будут общаться через внешнюю сеть. Прямое соединение vSwitch между собой невозможно. Поэтому невозможно и образование петель.
vSwitch - сетевое устройство, работающее на L2, канальном уровне сетевой модели OSI. Как любое устройство второго уровня, vSwitch отвечает за доставку пакетов соседним устройствам и не может осуществлять маршрутизацию. Поэтому если возникает необходимость доставки пакета в сегмент сети, напрямую не подключенный к vSwitch, то требуется наличие дополнительного маршрутизирующего устройства (физического или виртуального).
Существенное архитектурное отличие виртуальной инфраструктуры от привычной физической в том, что vSwitch берет на себя обеспечение отказоустойчивости сетевого соединения. В большинстве физических сред отказоустойчивость достигается добавлением дополнительной сетевой карты. Эти сетевые интерфейсы "связываются" при помощи специального ПО для поддержки агрегации (объединение пропускной способности нескольких сетевых интерфейсов в одном логическом) либо failover (при падении одного из линков трафик автоматически переключается на другой - не нашел адекватного перевода термина).
Так выглядит отказоустойчивость в физической среде.
А так - в виртуальной.
Легко заметить, что количество сетевых портов сократилось с 8 до 2 при сохранении эффективного уровная отказоустойчивости.
- Virtual Guest Tagging (VGT) – сетевые пакеты пересылаются ВМ через vSwitch в нетронутом виде, вместе с VLAN тэгами 802.1Q. Для включения данного режима необходимо указать VLAN в свойствах портгруппы.
- External Switch Tagging (EST) – этот метод наболее распространен в физических сетях. VLAN тэги добавляются и обрезаются при передаче трафика на физическом коммутаторе, поэтому пакет, достигший сервера, уже не будет иметь никакого тэга.
- Virtual Switch Tagging (VST) – этот метод распространен в виртуальных инфраструктурах VMware. В режиме VST VLAN тэги обрабатываются на vSwitch, а гостевая ОС работает с нетэгированным трафиком.
Небольшой пример. Скажем, у нас есть сервер, которому требуется доступ в несколько VLAN'ов.
Если мы сделаем то же самое в виртуальной инфраструктуре, картинка будет такой.
Обратите внимание, что для виртуальной машины не требуется Storage VLAN, он обрабатывается на уровне ESX и предоставляется ВМ в форме SCSI устройств.
А если машин становится больше, то дополнительных портов нам все равно не требуется.
Краткое представление и VLANах и EST режиме мы получили, теперь перейдем к VST режиму. Для включения VST режима достаточно указать VLAN ID в свойствах портгруппы. Обратите особое внимание, что для работы в VST режиме ваш физический коммутатор, к которому подключен ESX, должен уметь работать с 802.1Q трафиком!
Теперь мы можем избавиться от лишних сетевых интерфейсов, пустив весь трафик по одному транку. vSwitch автоматически определит кому предназначен трафик, отрежет VLAN тэг и направит пакет в требуемый vNIC.
А помните что мы говорили об уровне L2 и vSwitch? vSwitch не может маршрутизировать трафик между разными VLAN, поэтому для того, чтобы ВМ из VLAN 100 смогли работать с ВМ из VLAN 200, пакеты должны выйти из vSwitсh по аплинк-порту (pNIC) и добраться до L3 устройства (маршрутизатора).
При написании статьи использованы материалы "The Great vSwitch Debate" by Ken Cline.
Сети виртуальных машин.
Сеть виртуальных машин создается аналогично, только в мастере нужно выбрать Virtual Machine Port Group
Выбрать или создать VSwitch
указать название сети и VLAN
и завершить создание
После этого в нашем виртуальном коммутаторе появится еще одна сеть виртуальных машин и в настройках виртуальных машин станет доступно подключение к этой сети.
Дополнительный виртуальный коммутатор можно создать при создании VMkernel или VM Network. Как я уже говорил, наличие физического сетевого адаптера требуется только, если ВМ должны иметь доступ к внешним ресурсам(находящимся не на данном хосте ESXi).
Ну вот вкратце и всё по настройке сети VMware. Если что-то осталось не рассмотренным или непонятным, пишите в комментариях, — будем дополнять.
Настройка виртуальных коммутаторов VMWare
VMWare поддерживает 3 вида сетевого взаимодействия гостевых систем и хост-машины:
- Host-only - только хост
- Bridged - сетевой мост
- NAT - устройство трансляции адресов ( Network Address Translation )
Первый тип позволяет создать виртуальную сеть в рамках хоста, виртуальные машины при этом не имеют выхода во внешний мир, ограничиваясь внутренней сетью.
Второй тип - мост, позволяет объединить виртуальный адаптер гостевой системы с физическим сетевым адаптером хост-машины. При таком типе соединения, гостевая система
будет вести себя как независимый компьютер в рамках сети хост-машины. То есть, в моем случае, хост-машина - это 192.168.1.11, кроме нее в моей сети есть например
еще одна машины с адресами 192.168.1.12, если я подниму виртуалку и назначу ей адрес 192.168.1.13, то она будет видна в моей сети как еще один обычный компьютер.Немного путано), но если подумать, все станет понятно. Мост самый простой вариант настройки, на гостевой системе можно вообще ничего не прописывать, она
получит IP адрес с DHCP, моего роутера.Третий тип - NAT. Я пользуюсь именно этим типом, какой-то конкретной причины нет, просто так исторически сложилось, да и в настройке этот вариант не на много сложнее
сетевого моста.За настройку виртуальных коммутаторов в VMWare отвечает утилита Virtual Network Editor. Запускаем VMWare Workstation, сначала идем в Edit > Preferences, я тут практически ничего не меняю, только в первой вкладке прописываю путь до папки, где храню или буду хранить виртуальные машины:
далее запускаем Edit > Virtual Network Editor. Замечу, что в VMWare Workstation 6.5, данная утилита слегка отличается, но смысл тот-же, просто там все было разнесено по разным вкладкам а 7 версии все делается в одном окне.
1. Это список виртуальных коммутаторов. Как видно на скрине, коммутатор VMnet0 - Bridged ( мост ), VMnet1 - Host-only, и VMnet8 - это NAT, который нас и интересует.
2. Это как раз нужный коммутатор. При выделении этой строки, настройки внизу изменятся на соответствующие.
3. Выбран тип NAT, для данного коммутатора. Под кнопкой NAT Settings, настройки Network Address Translation ( см. скрин ниже ).
4. Подключить коммутатор к сети.
5. Использовать-ли для раздачи IP адресов DHCP сервер ( см. скрин ниже ).
6. Тут задан диапазон сети для виртуальных машин, то есть внутренняя сеть VMWare, находящаяся за коммутатором VMnet8.Я обычно отключаю лишние коммутаторы, что-бы не путаться. Для этого нужно выделить в списке соответствующий и снять галку с пункта 4. В данном случае я отключу коммутатор Host-only.
Здесь можно все оставить по умолчанию. Шлюз для сети 192.168.50.0 будет иметь адрес 192.168.50.2. Можете заглянуть в настройки DNS и NetBIOS, там я тоже все оставил как было.
Тут задан диапазон из которого будут выдаваться IP адреса виртуальным машинам. А так-же, так называемое время аренды, срок, на который присваивается IP адрес. Тут я тоже оставляю все как есть.
Далее можно выходить из Virtual Network Editor нажав Ок. С коммутаторами закончили.
Проверяем что у нас в сетевых подключениях на основном компьютере ( хост-машина ).
Видим в списке 2 сети, MainNet — это моя основная сеть, а VMware Network Adapter VMnet8 — это коммутатор NAT. Настройки соединения VMnet8 опять-же можно оставить как есть.
На этом первая часть, касающаяся настройки сети закончена, можно поднимать первую виртуальную машину.
In the VMware Host Client , you can edit virtual switch settings, such as the virtual switch uplinks.
Интерфейсы VMkernel.
Думаю, нужно еще рассмотреть настройки интерфейса VMkernel, используемого для служебных нужд.
Интерфейсов VMkernel может(и должно) быть несколько, чтобы разделить трафик управления от, например, трафика iscsi. Желательно, чтобы это были физически разделенные сети, ну или, хотя бы, на уровне VLANs.
Давайте настроим несколько таких интерфейсов.
Выбираем в секции Networking вкладку VMkernel adapters, выделяем пока единственный vmk0 и жмем карандаш для редактирования
В открывшемся окне на первой вкладке выбираем тип трафика, который разрешен на этом интерфейсе(давайте разрешим здесь еще VMotion — трафик миграции ВМ).
На других вкладках этого мастера можно изменить такие настройки как MTU, настройки IPv4 и IPv6.
После нажатия ОК настройки будут сохранены.
Теперь давайте создадим еще один VMkernel для трафика, например Fault Tolerance. Настройка сети для трафика хранилищ iscsi описана в статье Как подключить iscsi-lun к хосту esxi.
Итак, жмем на глобус с плюсом, чтобы добавить новый адаптер VMkernel
Выбираем тип VMkernel Network Adapter
Выбираем, использовать имеющийся или создать новый виртуальный коммутатор(мы выберем наш единственный). Жмем Next.
На следующем экране задаем имя нашего адаптера, выбираем какой версии протокол IP будет использоваться и какой трафик
Указываем сетевые настройки(статика или DHCP)
На завершающем экране мастера проверяем настройки и жмем Finish.
Видим, что теперь у нас появился второй VMkernel адаптер, который будет использован для передачи трафика Fault Tolerance logging.
среда, 20 октября 2010 г.
Procedure
- Click Networking in the VMware Host Client inventory and click Virtual switches .
- Right-click the virtual switch that you want to edit and click Edit Settings .
- (Optional) Click Add uplink to add a new physical uplink to the virtual switch.
- Change the maximum transmission unit (MTU).
The MTU improves the networking efficiency by increasing the amount of payload data transmitted with a single packet, that is, enabling jumbo frames.
- Reject . The VM network adapter receives only frames that are addressed to the virtual machine.
- Accept .The virtual switch forwards all frames to the virtual machine in compliance with the active VLAN policy for the port to which the VM network adapter is connected.
Note: Promiscuous mode is insecure mode of operation. Firewalls, port scanners, intrusion detection systems, must run in promiscuous mode.
-
Reject . If the guest OS changes the effective MAC address of the virtual machine to a value that is different from the MAC address of the VM network adapter (set in the .vmx configuration file), the switch drops all inbound frames to the adapter.
If the guest OS changes the effective MAC address of the virtual machine back to the MAC address of the VM network adapter, the virtual machine receives frames again.
- Reject . The switch drops any outbound frame from a virtual machine adapter with a source MAC address that is different from the one in the .vmx configuration file.
- Accept . The switch does not perform filtering, and permits all outbound frames.
- Route based on IP hash . Choose an uplink based on a hash of the source and destination IP addresses of each packet. For non-IP packets, whatever is at those offsets is used to compute the hash.
- Route based on source MAC hash . Choose an uplink based on a hash of the source Ethernet.
- Route based on originating port ID . Choose an uplink based on the originating port ID.
- Use explicit failover order . Always use the highest order uplink from the list of Active adapters which passes failover detection criteria.
Note: IP-based teaming requires the physical switch to be configured with EtherChannel. For all other options, EtherChannel must be disabled.
- Link Status only . Relies only on the link status that the network adapter provides. This option detects failures, such as cable pulls and physical switch power failures, but not configuration errors, such as a physical switch port being blocked by spanning tree or that is misconfigured to the wrong VLAN or cable pulls on the other side of a physical switch.
- Beacon only . Sends out and listens for beacon probes on all NICs in the team and uses this information, in addition to link status, to determine link failure. This detects many of the failures previously mentioned that are not detected by link status alone.
Select Yes , No , or Inherit from vSwitch to notify switches in the case of failover.
If you select Yes , whenever a virtual NIC is connected to the distributed switch or whenever that virtual NIC’s traffic might be routed over a different physical NIC in the team because of a failover event, a notification is sent out over the network to update the lookup tables on physical switches. In almost all cases, this process is desirable for the lowest latency of failover occurrences and migrations with vMotion.
Note: Do not use this option when the virtual machines using the port group are using Microsoft Network Load Balancing in unicast mode. No such issue exists with NLB running in multicast mode.
This option determines how a physical adapter is returned to active duty after recovering from a failure. If failback is set to Yes (default), the adapter is returned to active duty immediately upon recovery, displacing the standby adapter that took over its slot, if any. If failback is set to No , a failed adapter is left inactive even after recovery until another currently active adapter fails, requiring its replacement.
- Active Uplinks . Continue to use the uplink when the network adapter connectivity is up and active.
- Standby Uplinks . Use this uplink if one of the active adapter’s connectivities is down.
Traffic shaping policy is applied to the traffic of each virtual network adapter attached to the virtual switch.
Для этого выбираем наш хост, жмем на вкладку Configure, и в разделе Networking выбираем Virtual Switches.
Поскольку у нас на хосте имеется два сетевых адаптера(как установить драйвер на неподдерживаемую сетевую карту мы рассматривали в статье), давайте добавим нашу сетевую карту в виртуальный свич и настроим так называемый тиминг(объединение сетевых интерфейсов).
Виртуальных коммутаторов на хосте может быть несколько. Если вы хотите, чтобы ваши виртуальные машины находились в изолированной сети, можно создать виртуальный коммутатор, не используя сетевые адаптеры.
Ну а мы рассмотрим настройку обычного виртуального свича.
Настройка виртуальных коммутаторов VMWare
VMWare поддерживает 3 вида сетевого взаимодействия гостевых систем и хост-машины:
- Host-only - только хост
- Bridged - сетевой мост
- NAT - устройство трансляции адресов ( Network Address Translation )
Первый тип позволяет создать виртуальную сеть в рамках хоста, виртуальные машины при этом не имеют выхода во внешний мир, ограничиваясь внутренней сетью.
Второй тип - мост, позволяет объединить виртуальный адаптер гостевой системы с физическим сетевым адаптером хост-машины. При таком типе соединения, гостевая система
будет вести себя как независимый компьютер в рамках сети хост-машины. То есть, в моем случае, хост-машина - это 192.168.1.11, кроме нее в моей сети есть например
еще одна машины с адресами 192.168.1.12, если я подниму виртуалку и назначу ей адрес 192.168.1.13, то она будет видна в моей сети как еще один обычный компьютер.Немного путано), но если подумать, все станет понятно. Мост самый простой вариант настройки, на гостевой системе можно вообще ничего не прописывать, она
получит IP адрес с DHCP, моего роутера.Третий тип - NAT. Я пользуюсь именно этим типом, какой-то конкретной причины нет, просто так исторически сложилось, да и в настройке этот вариант не на много сложнее
сетевого моста.За настройку виртуальных коммутаторов в VMWare отвечает утилита Virtual Network Editor. Запускаем VMWare Workstation, сначала идем в Edit > Preferences, я тут практически ничего не меняю, только в первой вкладке прописываю путь до папки, где храню или буду хранить виртуальные машины:
далее запускаем Edit > Virtual Network Editor. Замечу, что в VMWare Workstation 6.5, данная утилита слегка отличается, но смысл тот-же, просто там все было разнесено по разным вкладкам а 7 версии все делается в одном окне.
1. Это список виртуальных коммутаторов. Как видно на скрине, коммутатор VMnet0 - Bridged ( мост ), VMnet1 - Host-only, и VMnet8 - это NAT, который нас и интересует.
2. Это как раз нужный коммутатор. При выделении этой строки, настройки внизу изменятся на соответствующие.
3. Выбран тип NAT, для данного коммутатора. Под кнопкой NAT Settings, настройки Network Address Translation ( см. скрин ниже ).
4. Подключить коммутатор к сети.
5. Использовать-ли для раздачи IP адресов DHCP сервер ( см. скрин ниже ).
6. Тут задан диапазон сети для виртуальных машин, то есть внутренняя сеть VMWare, находящаяся за коммутатором VMnet8.Я обычно отключаю лишние коммутаторы, что-бы не путаться. Для этого нужно выделить в списке соответствующий и снять галку с пункта 4. В данном случае я отключу коммутатор Host-only.
Здесь можно все оставить по умолчанию. Шлюз для сети 192.168.50.0 будет иметь адрес 192.168.50.2. Можете заглянуть в настройки DNS и NetBIOS, там я тоже все оставил как было.
Тут задан диапазон из которого будут выдаваться IP адреса виртуальным машинам. А так-же, так называемое время аренды, срок, на который присваивается IP адрес. Тут я тоже оставляю все как есть.
Далее можно выходить из Virtual Network Editor нажав Ок. С коммутаторами закончили.
Проверяем что у нас в сетевых подключениях на основном компьютере ( хост-машина ).
Видим в списке 2 сети, MainNet — это моя основная сеть, а VMware Network Adapter VMnet8 — это коммутатор NAT. Настройки соединения VMnet8 опять-же можно оставить как есть.
На этом первая часть, касающаяся настройки сети закончена, можно поднимать первую виртуальную машину.
In the VMware Host Client , you can edit virtual switch settings, such as the virtual switch uplinks.
Читайте также: