Vmware distributed switch настройка
In vSphere Networking Basics – Part 2, I talked about the vSphere Distributed Switch (vDS) and how it can help you centralize network management across your vSphere environment. On re-reading my post, I realized I left out an interesting vDS feature which is the ability to clone, for lack of a better word, the networking configuration of an ESXi host over to other hosts when hooking them up to a vDS.
This feature, or option if you prefer, is called template mode something only accessible when adding new or existing hosts to a distributed switch. To use this feature, we first set up the template host by creating the required VMkernels and the services they’ll be running such as vMotion and vSAN. When we get to the part of adding hosts to the switch, we just tick an option to have the template host’s network configuration copied over to the remaining hosts. While testing the feature I came across one major drawback, if I can call it that. I’ll address this issue at the end of the post.
Notes:
- My lab is currently running vSphere 6.5 U1 meaning that some of the steps may differ or will not be available in older versions of vSphere. I’ll also be using the vSphere Web Client since the vSphere client (HTML5), at the time of writing, does not expose the template mode option.
- Remember that distributed switches are a vCenter Server feature and available only to Enterprise Plus licenses users.
Let’s start off by configuring the template host.
Setting up a template host
Setting up an ESXi host for networking involves a few basic items amongst which;
- Create the VMkernels.
- Configure TCP/IP information for every VMkernel.
- Configure each VMkernel for the respective service it will be used for.
For this post, I’m using two ESXi 6.5 hosts. The first will act as the template host and the second will inherit the network settings from the first.
Adding hosts to a distributed switch in template mode
This section outlines the process of adding ESXi hosts to a distributed switch using template mode. In vSphere Web Client, select the Networking tab (1) and either create a new vDS or select an existing one as I illustrate next. Right-click on the vDS name and select Add and Manage Hosts from the context menu.
Adding ESXi hosts to a distributed switch
Select Add hosts on the next screen and press Next.
Adding ESXi hosts to a distributed switch
A list of all the ESXi hosts managed by vCenter and not already connected to the vDS are displayed. Select the hosts you want to connect (1) and press Next.
Selecting which hosts to add to a vDS
In the next screenshot, notice the option (1) at the bottom of the next screen which is what enables template mode. Tick on the option and press Next to continue.
Note: Clicking on the information icon next to the option gives you the following:
Use this option if you want to make the network configuration of the physical and VMkernel network adapters on this distributed switch identical on the selected hosts. Mark one of the hosts as a template. Use its existing network configuration or create a new one on the distributed switch, and apply it automatically on the other hosts. The configurations of the physical and VMkernel network adapters are applied separately. You can repeat this process as many times in the wizard as needed to achieve the desired network configuration. A host remains a template only during the lifetime of this instance of the wizard. The distributed switch is not aware of your choice and the network configuration will not be synchronized in the background if a network configuration change occurs on the template or any other host in the selection.
An important point is made here. The template host’s settings are only applied once and only once. New hosts added to the vDS at a later stage will not inherit settings from the host that was previously designated as the template host or from any other host.
Enabling the template mode option
On this next screen, make sure you select the template host, esx6-d in my case, from the list of hosts displayed.
Designating the template host
Since I’m adding newly installed hosts, the first 2 network adapter tasks will suffice. The first one takes care of connecting the ESXi’s physical NICs to the vDS uplinks. The second handles VMkernel adapters, to port mapping on the vDS.
Network adapter tasks
This is where we start applying the template host’s network configuration to the other hosts.
In the upper pane, you review the template host’s current uplink settings. Since we’re moving from a standard to a distributed switch, we must change the uplink to one on the vDS as per standard procedure.
The rest of the hosts are listed in the bottom-most pane. You must click on the Apply to all button (4) to copy over the uplink settings from the template to the rest of the hosts. Click Next to continue.
Setting uplink ports in template mode
Next, we set the template host’s VMkernel adapters (1) to use the distributed port group on the vDS we’re connecting to via the Assign port group button (2). Clicking on Apply to all (3) copies the portgroup settings to the hosts. Notice how the wizard creates an additional vmk1 VMkernel adapter marked new as shown next.
This basically answers a question a reader had brought up – Does template mode create new VMkernel adapters? – something I wasn’t sure about myself, hence this post!
Setting VMkernel adapters in template mode
Since it’s a very bad idea to have ESXi hosts and VMkernels configured with identical IP addresses, you will be prompted to enter new IP addresses for all the target VMkernel adapters, both existing and any new ones being created. Since vmk0 on target hosts will be already configured – this is always the case since it would be impossible to add it to vCenter – your only option is to type in the currently assigned IP address (1) as you cannot leave the IPv4 address field blank. Likewise, you must type in the IP address of any other VMkernel being created.
Configuring IP addressing for the various VMkernel adapters
Press Next to skip the next screen.
Pressing Finish completes the template host network configuration cloning process.
Completing the process
When configuring multiple hosts, use the status or recent tasks window to monitor the progress. The next screenshot shows the addition and configuration of vmk1, the second VMkernel adapter created on esx6-e.vsphere65.local.
Monitoring network tasks in the recent tasks window
You can run the previous PowerCLI command to verify that the vMotion VMkernel has been created and assigned the correct IP address.
Using PowerCLI yet again to retrieve VMkernel information
Additionally, use the vSphere Web client or the esxcli command to verify the same. As shown next, the correct configuration has been applied save for the TCP/IP stack type which is set to Default instead of vMotion as originally configured.
Inspecting VMkernel details in vSphere Web Client
Being a doubting Thomas, I had to rule out possible glitches with the web client’s UI. To do this, I ran the following esxcli command from an SSH session. The command outputs information about ESXi’s VMkernel adapters. The Network Instance property is set to defaultTCPipStack, meaning there’s nothing wrong with the UI!
Using the esxcli command for more detailed VMkernel info
Настройка LACP
Выбираем Distributed Switch в UI. Открываем Configure > Settings > LACP.
Нажимаем кнопку +NEW. Открывается мастер создания группы LAG.
Указываем название, я оставляю по умолчанию - lag1.
В поле Number of ports указываем количество линков. В моей практики встречалось 4 гигабитных линка, 2 десятигигабитных. Всё зависит от вашей конфигурации.
Mode - Passive. Здесь могут быть варианты в разных сетях.
Load balancing mode - я ставлю Source and destination IP address. Если вы используете Cisco, то это оправдано, иначе MAC адрес сетевухи может скакать с одного интерфейса на другой.
Uplink port groups
As with standard switches, there are uplinks that are providing connectivity to the physical world. An uplink port group has one or more uplinks. By default, there are 4 uplinks created when first create a vDS.
Again, changing settings on the uplink port group, those settings are replicated to all the connected hosts.
vDS does have features that vSS does not. Private VLANs are one of those. You can also use vDS network policies that allow you to manage traffic shaping.
Now we’re going to show you how to create a VMware vDS. First, you need to create the vSphere distributed switch. Go to the networking tab by clicking on the globe in the HTML5 client.
Then right-click on the datacenter and select Distributed Switch > New Distributed Switch
Create new vSphere Distributed Switch
Next, put some meaningful name for your switch. Note that within your datacenter you might be creating several vDS so a proper naming convention is probably not a bad idea.
Create a new vSphere Distributed Switch Wizard
We can choose which version of vDS we’ll be creating. This is obviously for compatibility reasons. You might be running some older ESXi hosts that aren’t migrated to vSphere 7 so you’d be obviously picking up the older version of the vDS.
The vDS has evolved since vSphere 6.x to 7.0.2 by adding additional features and options. Let’s move on with the wizard.
Create new vSphere Distributed Switch Wizard – Select version
Next, we need to select how many uplinks we’ll connect to this switch and if we want to enable Network I/O control (by default, it’s enabled).
Also, on this page, we’re asked to create the default port group. You can pick a name for this distributed port group here or rename it later.
Create new vSphere Distributed Switch Wizard – Uplinks and port group
On the next page, you’ll see the recapitulation. Click the finish button to create your vDS. You can have a look at the vDS topology. You’re still in the networking section and you should see your vDS here.
Click on the vDS and select Configure > Topology.
VMware vDS Topology
Next, we need to associate some of our hosts with vDS. To do that, you can right-click on the vSphere distributed switch and click on Add and Manage Hosts.
Add and manage hosts
Then we have another wizard where we can either Add hosts, manage host networking or remove hosts.
Add hosts to vDS
Next, select your hosts that you want to connect to your vDS.
Select your hosts
Next, you’ll need to assign the physical NICs to an uplink and click Next again.
Assign an uplink
Next, we have an option to migrate any VMkernel adapters if we want to (not mandatory).
Migrate VMkernel adapters if you want to
And we have an option to migrate VM networking as well.
Migrate VM networking
Next, just click Finish to close the assistant. We’re done. You can now make changes to all hosts connected to your vDS. This is the main advantage over the standard vSwitches.
VSAN from StarWind is software-defined storage (SDS) solution created with restricted budgets and maximum output in mind. It pulls close to 100% of IOPS from existing hardware, ensures high uptime and fault tolerance starting with just two nodes. StarWind VSAN is hypervisor and hardware agnostic, allowing you to forget about hardware restrictions and crazy expensive physical shared storage.
Build your infrastructure with off-the-shelf hardware, scale however you like, increase return on investment (ROI) and enjoy Enterprise-grade virtualization features and benefits at SMB price today!
Резюме
Итак, мы создали Distributed Switch, перенесли в него хосты, настроили LACP, разрешили vMotion.
VMware vSphere 7 has the possibility to use vSphere Distributed Switch to manage multiple hosts at the same time and “push” the configuration to multiple hosts at the same time. With the traditional vSphere Standard Switch (vSS) you have to repeat the configuration on a per-host basis.
A vSphere Distributed Switch (vDS) acts as a single virtual switch that is associated with selected hosts in your datacenter. You can pick a host that is part of vDS but you don’t have to “attach” all the hosts from your environment.
vDS provides centralized provisioning, monitoring, and management of virtual networks for your hosts and virtual machines (VMs). You can create and configure distributed switches on a vCenter Server system, so you need as a hard requirement, vCenter Server.
Another hard requirement is licensing. You’ll need an enterprise Plus license or a vSAN license. It’s because VMware has made said configuration available only for clients that have purchased a vSAN license.
The vCenter Server propagates the vDS configuration to each connected ESXi host in the form of a host proxy switch. The ESXi host provides the data plane for the I/O traffic. The data plane implements the packet switching, filtering, tagging, and other features for the Ethernet packet. However, the management plane is provided only via vCenter Server.
If your vCenter server is down for some reason, it does not matter for the normal functioning of VMs and hosts, but it matters for configuration. Without vCenter Server, you can’t configure vDS.
VMware vDS Architecture
Conclusion
Adding hosts to a vDS using template mode is a convenient way of ensuring a homogeneous network configuration across your ESXi hosts. The one drawback I came across, is the inability to set the TCP/IP stack value as per the template host’s configuration. The fact that you have to type in the IP addresses for preconfigured VMkernel adapters is also somewhat annoying but something I can live with.
Besides Part 2 of the networking series, you might also want to give Part 1 a read to learn about standard switching in vSphere if this is all new to you.
Final words
VMware vDS allows a single virtual switch to connect to multiple ESXi hosts. You can manage networking configurations from a central place. vDS also include rollback and recovery options for patching and updating network configuration.
With vDS you can create much powerful networking constructs than with vSS. vDS separates the management plane from the data plane and offers advanced networking features such as Network I/O control which are just perfect for QoS in conjunction with VMware vSAN where you need to separate the vSAN traffic from other networks and manage QoS. The vDS requires an Enterprise Plus license or a vSAN license.
Delphi site: daily Delphi-news, documentation, articles, review, interview, computer humor.
Идея их заключается в следующем: в случае использования стандартных вКоммутаторов у вас разные (пусть очень часто и идентично настроенные) виртуальные коммутаторы на каждом сервере. Акцент я хочу сделать вот на чем: создать и поддерживать эту, пусть даже идентичную, конфигурацию придется вам. При необходимости, например, создать еще одну группу портов для еще одного VLAN вам потребуется повторить это простое действие на всех серверах ESX(i).
А в случае создания распределенного коммутатора вы получаете один-един-ственный (логически) коммутатор, существующий сразу на всех серверах ESX(i).
Вы настраиваете только этот, логически единый коммутатор. Новую группу портов из примера выше вы создадите один раз, и она появится для всех серверов ESX(i), входящих в распределенный коммутатор.
ВМ, даже при миграции с сервера на сервер, остаются не только на том же коммутаторе, но и даже на том же порту распределенного виртуального коммутатора (это называют Network vMotion). Это позволяет проще настраивать политики безопасности, осуществлять мониторинг трафика ВМ, привязываясь даже к отдельному порту вКоммутатора.
В отличие от стандартных виртуальных коммутаторов VMware, distributed vSwitch поддерживают Private VLAN и двухсторонний traffic shaping (о том, что это такое, см. в разделах 2.4.2 и 2.4.4). В версии 4.1 в список уникальных возможностей распределенных коммутаторов добавились такие функции, как:
- Network IO Control - возможность гибко настраивать минимально и максимально доступные ресурсы пропускной способности для трафика разных типов. Подробности о NIOC см. в главе 6, посвященной распределению ресурсов;
- Load Based Teaming - балансировка нагрузки между физическими контроллерами одного вКоммутатора в зависимости от нагрузки на каждый контроллер.
Еще один плюс - распределенный вКоммутатор доступен в реализациях от VMware и от Cisco.
Вариант от Cisco, распределенный виртуальный коммутатор Cisco Nexus 1000V, приобретается независимо от vSphere (но подойдет не любая лицензия vSphere, на момент написания - только Enterprise Plus). Он обладает всеми возможностями, присущими сетевому оборудованию от Cisco. Позволяет добиться того, что все используемые коммутаторы в сети компании созданы одним производителем (здесь имеется в виду Cisco), и сетевые администраторы могут управлять ими точно так же, как коммутаторами физическими, снимая, таким образом, эти задачи с администратора vSphere. Однако рассмотрение настроек и возможностей этого решения в данной книге описано не будет.
Здесь будет описан распределенный виртуальный коммутатор от VMware. Возможность им пользоваться появляется после активации лицензии, дающей на него право, - сегодня это vSphere Enterprise Plus (и ее ознакомительный 60-дневный период после установки vSphere, Evaluation-лицензия).
Как я уже сказал, dvSwitch - объект скорее логический, как таковой существующий только для vCenter. Мы создали один распределенный вКоммутатор, но на каждом сервере, для которых он существует, автоматически создаются стандартные вКоммутаторы, скрытые от нас (рис. 2.11). Таким образом, де-факто распределенный коммутатор является шаблоном настроек. Мы создаем его и указываем настройки в vCenter - это control plane по документации VMware, то есть уровень управления. А после включения в созданный распределенный коммутатор серверов ESX(i) vCenter создает на них стандартные коммутаторы, скрытые от нас. По документации VMware это IO Plane, прикладной уровень. За всю работу отвечают скрытые коммутаторы на серверах ESX(i), все управление осуществляется только через vCenter.
Рис. 2.11. Иллюстрация сути распределенного виртуального коммутатора Источник: VMware
Минусом такой схемы распределенного виртуального коммутатора VMware является возросшая сложность, в частности зависимость от vCenter. vCenter является управляющим элементом для dvSwitch, и при недоступности vCenter у администратора нет возможности менять настройки распределенного коммутатора и даже переключать виртуальные машины на другие группы портов. Однако даже при недоступности vCenter сеть будет продолжать работать - ведь за техническую сторону вопроса отвечают скрытые от нас коммутаторы на каждом ESX(i), теряется только возможность изменения настроек.
Кстати, подключение самого vCenter к распределенному коммутатору не поддерживается VMware.
Подключитесь клиентом vSphere к vCenter. Предполагается, что в иерархии vCenter уже создан объект Datacenter, уже добавлены серверы. Распределенный виртуальный коммутатор создается для объекта Datacenter, и существовать для серверов из разных Datacenter один dvSwitch не может.
Пройдите Home ^ Networking. В контекстном меню объекта Datacenter выберите пункт New vNetwork Distributed Switch.
В запустившемся мастере нас спросят:
- Name - имя создаваемого вКоммутатора. Влияет только на удобство;
- Number of dvUplink ports - максимальное количество подключений ко внешней сети - привязанных vmnic - на каждом сервере. Обратите внимание: один такой вКоммутатор может существовать для серверов с разной конфигурацией, с разным количеством доступных сетевых контроллеров -а здесь мы ограничиваем максимальное число используемых для данного dvSwitch контроллеров на одном сервере;
- дальше вам предложат выбрать серверы, для которых будет существовать создаваемый вКоммутатор. Выбор можно осуществить или изменить позже. Если будете выбирать серверы сейчас, то вам покажут свободные физические сетевые контроллеры на каждом выбранном сервере - и вы сможете выбрать те из них, что будут использоваться для создаваемого вКоммута-тора. По ссылке View Details вам покажут исчерпывающую информацию о физическом сетевом контроллере - драйвер, производитель, статус подключения (link status), PCI-адрес, доступные через него подсети IP - не покажут здесь только MAC-адрес;
- на последнем шаге можно будет снять флажок Automatically create a default port group. Если он стоит, то автоматически будет создана группа портов со 128 портами и именем по умолчанию. Имя по умолчанию малоинформативно, поэтому я рекомендую этот флажок снимать и создавать группу портов самостоятельно, после создания вКоммутатора.
Обратите внимание. У стандартных вКоммутаторов число портов настраивается для них самих, группы портов «безразмерные». У распределенных вКоммутаторов наоборот. Вы можете создать до 248 распределенных виртуальных коммутаторов для сервера. На одном сервере может быть до 4096 портов стандартных и распределенных вКоммутаторов. Это означает, что если не задавать заведомо огромных значений числа портов, то с ограничениями с этой стороны вы не столкнетесь.
Когда вы создали dvSwitch, то на странице Home ^ Inventory ^ Networking вы видите картинку примерно как на рис. 2.12.
Здесь «Demo_dvSwitch» - это сам объект - распределенный вКоммутатор. Объект «Demo_dvSwitch-DVUplinks-28» - это группа портов, в которую объединены его подключения ко внешним сетям. То есть те порты вКоммутатора, к ко-
Рис. 2.12. Свежесозданный dvSwitch
торым подключены физические сетевые контроллеры серверов, на которых этот dvSwitch существует. Нужен этот объект для получения информации о внешних подключениях - обратите внимание на столбцы в закладке Ports для данной группы портов. Число 28 в названии - это случайным образом сгенерированное число, для уникальности имени этого объекта.
Ну и «Demo_dvPortGroup» - созданная вручную группа портов, туда можно подключать ВМ, а также виртуальные сетевые контроллеры Service Console и VMkernel.
Обратите внимание. При использовании стандартных виртуальных коммутаторов невозможно поместить в одну группу портов виртуальные машины и интерфейс VMkernel или Service Console. На распределенных виртуальных коммутаторах VMware это возможно, на dvSwitch в одной группе портов могут сосуществовать и ВМ, и интерфейсы SC и VMkernel в любых сочетаниях.
Кстати говоря, объект «VM Network» на этом рисунке - это группа портов на стандартных виртуальных коммутаторах серверов этого vCenter.
Создаём Distributed Switch
Будем считать, что вы уже знаете зачем собираетесь устанавливать Distributed Switch. Ставим.
Заходим в vCenter, переходим в раздел Networking. Нажимаем правой кнопкой на выбранный кластер,выбираем Distributed Switch > New Distributed Switch.
Открывается мастер создания распределённого коммутатора. Мы на вкладке Name and location.
Указываем название, NEXT. Мы на вкладке Select version.
Выбираем версию коммутатора. Коммутатор 6.0 не поддерживает хосты версии 6.5. Так что я выбираю последнюю версию. NEXT. Мы на вкладке Configure settings.
Выбираем количество аплинков. Можно включить Network I/O Control. Можно выбрать галку для создания дефолтной port group и указать её название. Я буду использовать эту группу для управления гипервизорами и vCenter, называю HV. NEXT. Мы на вкладке Ready to complete.
Проверяем настройки и нажимаем FINISH. Distributed Switch создан. Давайте его настроим. Нажимаем правой кнопкой на коммутатор - Settings > Edit Settings. Переключаемся в раздел Advanced. Находим блок Discovery protocol. Type - ставим в Cisco Discovery Protocol. Operations - Both.
Ссылки
Distributed Port groups
As in vSS, vDS has port groups. They’re called distributed port groups. There are connections from VMkernel network adapters and also VMs NICs that connect there. A set of distributed ports is called a distributed port group.
VMware has created those distributed port groups to simplify the configuration and management of distributed ports. You can basically apply unique network labels to each distributed port group and they are propagated to all hosts.
You can configure NIC teaming, VLAN, security, traffic shaping, and other policies to a distributed port group which then applies the policies to the underlying distributed ports. It’s very very powerful.
Создаём Distributed Switch в vCenter 7
Итак, мы решили создать распределённый коммутатор. Устанавливаем.
Заходим в vCenter 7, переходим в раздел Networking. Нажимаем правой кнопкой на выбранный кластер, выбираем Distributed Switch > New Distributed Switch.
Открывается мастер создания распределённого коммутатора. Мы на вкладке Name and location.
Указываем название, например, "DSwitch 1", NEXT. Мы на вкладке Select version.
Выбираем версию коммутатора. В vCenter доступны версии коммутаторов:
Я выбираю последнюю версию, поскольку планирую использовать ESXi 7. NEXT. Мы на вкладке Configure settings.
Выбираем количество аплинков. Можно включить Network I/O Control. Можно выбрать галку для создания дефолтной port group и указать её название. Я буду использовать эту группу для управления гипервизорами и vCenter, называю HV. NEXT. Мы на вкладке Ready to complete.
Проверяем настройки и нажимаем FINISH. Distributed Switch создан.
Давайте его немного настроим. Actions > Settings > Edit Settings.
Открывается мастер настройки распределённого коммутатора. Мы в разделе General.
Здесь можно сменить название коммутатора, указать описание и управлять настройками Network I/O Control. Переключаемся в раздел Advanced.
Находим блок Discovery protocol. Type — ставим в Cisco Discovery Protocol. Operations: Both. OK.
Здесь же можно менять MTU и управлять Multicast filtering mode. Дополнительно можно указать контакты администратора.
Идея распределённого коммутатора заключается в следующем - создать один коммутатор, который будет обслуживать сразу несколько гипервизоров. Вы получаете один единственный логический коммутатор, существующий сразу на всех серверах ESX(i). Распределённый - потому что он рулится из одной точки - vCenter, а распределяется на все хосты. Если vCenter выйдет из строя, то коммутатор продолжит работу. Мы просто потеряем возможность настраивать коммутатор.
Распределённый коммутатор имеет несколько больший функционал в отличие от обычного. Ключевые моменты:
- Private VLAN.
- Bi-directional Traffic Shaping.
- Network VMotion.
Настройка Default Port Group
Выбираем созданную вместе с коммутатором port group, мы назвали её HV. Нажимаем правой кнопкой - Edit Settings.
Открывается мастер настройки. Мы в разделе General. Port binding ставим в Static binding. Port allocation - Elastic.
Переключаемся на раздел VLAN. Эту группу портов мы будем использовать для управления хостами, поэтому настраиваем такой же VLAN, в котором живут ESXi и vCenter.
Переключаемся на раздел Teaming and failover.
По умолчанию у Port Group LACP не используется, включим. Перетаскиваем lag1 вверх, а аплинки вниз.
OK. Сохраняем. Каждый раз потом при создании новой группы портов нужно настраивать LACP для этой группы. Можно это делать прямо в процессе создания.
Create and configure your VMkernel adapters
To start with, your ESXi hosts must have at least one preconfigured VMkernel adapter if the plan is to join them to vCenter Server and hook them up to a vDS. In this example, I’m creating a second VMkernel on the template host in addition to the default vmk0.
To do this, select the ESXi host in Navigator (1) and click the Configure tab (2). Expand Networking and select VMkernel adapters (3). Click on Add Host Networking button to create a new adapter.
Adding a VMkernel adapter on ESXi
Select the first option – VMkernel Network Adapter – and click Next.
Adding a VMkernel adapter on ESXi
Leave the switch option as set. We will be migrating the host to a vDS at a later stage. VSwitch0 refers to the default standard switch created on ESXi when installed. Press Next.
Selecting network switch placement
On the next screen, type in a name for the adapter in the Network Label field (1). Choosing a meaningful name, allows you to quickly identify an adapter and its purpose. In this case, I named it vMotion VMkernel since it will be used only for vMotion traffic.
If VLANs are used on your network, set the VLAN ID for the network earmarked for vMotion traffic. Select the IP version – 4, 6 or both – from the IP Settings drop-down box.
As per my vSphere Networking Basics – Part 2, you can change the TCP/IP stack for optimal performance. You can only do this for vMotion and Provisioning traffic unless you create a custom stack. If you do go for a stack other than the default one, keep in mind the following 2 caveats:
- The TCP/IP stack type cannot be changed once defined. The only method is to delete the VMkernel and start afresh.
- The template mode feature does not copy over the TCP/IP stack type values from the template host. Instead, the value on the target hosts is always set to Default. I did not find any information on the matter so I am not sure if this is a limitation, bug or by design. If anyone knows, please share via a comment in the box below.
In this example, I set the TCP/IP stack type to vMotion (2) to show, further down, that the value is indeed not copied over to the target host(s). Also note, that vMotion is automatically selected as the only Enabled Service with every other option ghosted out which is the expected behavior.
Configuring a VMkernel adapter
Next, set the IP setting for the adapter. It’s always a good idea to go for static settings instead of relying on DHCP assigned addressing. Press Next.
Configuring IP addressing for a VMkernel adapter
Before pressing Finish, review the settings one more time.
VMkernel adapter configuration summary
The template host has two VMkernel adapters which, at this point, are still connected to the default standard switch vswitch0 present on each host. As a side-note, you can use PowerCLI to quickly retrieve a list of VMkernels on one or all hosts like so:
Using PowerCLI to retrieve VMkernel details
Looking at the command output, esx6-d.vsphere65.local is the designated template host having two VMkernels, vmk0 and vmk1. The target host, esx6-e.vSphere65.local, is configured with one adapter.
Ask Me Anything!
If anything here is unclear or you have anything to add please don’t hesitate to write to me in the comments section below. I’m always happy to help my fellow IT pros (and I also learn from you guys too!)
Распределённый коммутатор обслуживает сразу несколько гипервизоров. Мы получаем один логический коммутатор, существующий сразу на всех серверах ESXi в рамках датацентра. Коммутатор управляется из vCenter 7 и распределяется по хостам. Если vCenter 7 выйдет из строя, коммутатор будет и дальше работать, правда, мы потеряем возможность его настройки.
Распределённый коммутатор имеет несколько больший функционал в отличие от обычного. Бонусы:
- Private VLAN.
- Bi-directional Traffic Shaping.
- Network VMotion.
Добавление хоста в Distributed Switch
Нажимаем правой кнопкой на Distributed Switch - Add and Manage Hosts.
Открывается мастер. Мы попадаем в раздел Select task.
Выбираем Add hosts. NEXT. Мы попадаем в раздел Select hosts.
Нажимаем кнопку + New hosts. Открывается окно со списком доступных хостов. У меня пока один - hv00.
Выделяем хост галкой, OK.
NEXT. Мы попадаем в раздел Manage physical adapters.
vmnic1 цепляем кнопкой Assign upling к lag1-1.
Наша задача добиться того, чтобы хост одной ногой был в старом коммутаторе, а второй - в новом. NEXT. Мы попадаем в раздел Manage VMkernel adapter.
Пока ничего не меняем, пусть vmk0 будет на старом локальном коммутаторе. NEXT. Мы попадаем в раздел Migrate VM networking.
NEXT. Мы попадаем в раздел Ready to complete.
FINISH. Ждём когда хост добавится.
Снова нажимаем правой кнопкой на Distributed Switch - Add and Manage Hosts.
Открывается мастер. Мы попадаем в раздел Select task.
Теперь выбираем пункт Manage host networking. NEXT. Доходим до раздела Manage VMkernel adapter.
Выбираем vmk0, нажимаем Assign port group.
Выбираем наш Port Group с названием HV, который находится в управляющем VLAN. OK.
NEXT. Мы попадаем в раздел Migrate VM networking.
NEXT. Мы попадаем в раздел Ready to complete.
FINISH. Управление хостом должно перейти на Distributed Switch.
Снова редактируем сеть хоста.
vmnik0 привязываем к lag1-0.
NEXT. NEXT. NEXT. FINISH.
Теперь можно зайти в хост - Configure > Networking > Virtual switches и удалить локальный vSwitch0.
Потом заходим в хост - Configure > Networking > VMkernel adapters, выбираем vmk0, редактируем, разрешаем галкой vMotion.
Читайте также: