= запуск `DirectPath I/O` на `Cisco UCS` через `vm-fex` для `vSphere`

[[PageOutline(2-3,содержание)]]

== синопсис

=== бесполезный `DirectPath I/O`
об этом весьма неплохо написано в [#link1 документации] от `vSphere`. если вкратце, то технология позволяет виртуальным машинам получать прямой доступ до физических устройств `pci` на сервере с гипервизором. однако, при использовании этой технологии перестают работать почти все полезные вещи, которые позволяет кластер `vSphere`: `fault tolerance`, `high availability`, снапшоты, `vMotion` и `DRS` с ним же.

более того, когда виртуальная машина использует устройство напрямую, минуя гипервизор, то это устройство перестаёт быть доступно самому гипервизору. например, если прокидывать сетевушку внутрь виртуалки через `DirectPath I/O`, то, да, ресурсы гипервизора на обработку трафика от виртуальной машины больше не используются - это хорошо. плохо то, что прокинутую сетевушку сможет использовать только одна виртуалка. технология, получается, весьма спорная, если не сказать больше - бесполезная.

но не всё так однозначно.

=== восхитительный `Cisco UCS`
скажу откровенно, я довольно нудный тип, которого почти невозможно чем-то восхитить. даже если это получилось, я не всегда захочу это показать, а там где захочу, то не всегда сумею. до того, как я познакомился с блейд-системами `Cisco`, я, честно говоря, даже и не знал что фирма `Cisco` производит сервера. оказалось, производит, да ещё такие, которыми я не устаю восхищаться.

всю жизнь я работаю с серверами, немного пореже в руки перепадали блейд-системы. когда я первый раз увидел `UCS manager` то стало понятно, что нахрапом его не возьмёшь. почему? хотя бы потому, что кнопочки `вкл` на сервере нет. пока не сформирован `service profile` (профиль) из определённого набора конфигурационных параметров, то железка бесполезна.

в конфигурационных параметрах профиля из сервера можно вылепить всё что угодно: параметры биос, последовательность загрузки, адреса `ip-kvm`, `hba`, версии прошивок, параметры и `mac`-адреса сетевушек (`iscsi` и обычных). всё это сделано очень гибко, с удобной иерархией и возможностью задавать пулы массово изменяющихся параметров, таких как адреса и маки. соответственно, пока всё это не изучено, то лезвие запустить не получится.

=== сетевая часть
о конфигурировании я здесь рассказывать не буду. по этой теме у фирмы `Cisco`, как и для всего остального, есть довольно внятная документация. да и в интернете, в том числе на хабре, об этом написано некоторое количество статей. я хотел бы остановиться на сетевой части блейд-систем `Cisco UCS`. сетевая часть здесь тоже особенная. дело в том, что в серверах-лезвиях отсутствуют сетевые интерфейсы. как же тогда сервера работают с сетью? всё таки сетевой адаптер в каждом лезвии есть: это `Virtual Interface Card` (`vic`).

в комплексе с `IO Module` (`iom`) в корзине эти две железки позволяют создавать реальным серверам виртуальные сетевые интерфейсы в необходимом количестве. оно, конечно, ограничено, но ограничение довольно большое - //[[span(style=color: #FF0000, должно хватить всем)]]//. так зачем же нам сотня сетевых интерфейсов на сервере? незачем, если мы не используем виртуализацию. вот тут-то настаёт время вспомнить о //[[span(style=color: #FF0000, бесполезном)]]// `DirectPath I/O`, который выступает теперь уже совсем в другом свете.

во второй части [#link1 документации] от `vSphere`, внезапно, обнаруживается, что `DirectPath I/O` на `Cisco UCS` ~~поставляется с блекджеком и шлюхами~~ работает и со снапшотами, и с `fault tolerance`, и с `high availability`, и с `vMotion` за которым неразлучно следует `DRS`. «клёво!» - подумал я, когда прочитал об этом. «сейчас быстро сделаю, будет всем щастье» и обломался. ни в документации `Cisco`, ни в документации `VMWare` я не нашёл чего-то, похожего на инструкцию, как все это сделать. из всего, что мне удалось найти было лишь [#link2 что-то], очень удалённо напоминающее попытку сделать пошаговую инструкцию. этот сайт уже сдох, поэтому ссылка на веб-архив.

=== ещё немного воды
я решил написать подробный мануал в первую очередь - для себя, чтобы, столкнувшись с задачей второй раз, ничего не забыть, быстро и успешно всё повторить. во-вторую очередь для всех остальных, хотя я прекрасно осознаю, что большинство читателей, и, возможно, я и сам в будущем, никогда не встретимся с `Cisco UCS`. спасибо импортозамещению в том числе.

для того, чтобы успешно работать с `DirectPath I/O` на `UCS` нужно хорошо понимать как работает `virtual distributed switch` (`vds`) у `vSphere`. если понимания нет или запустить его не удалось, и вы думаете, что выполнив этот мануал удасться запустить всё, что здесь описывается - это ошибка. запустить, может, и получится, но потом очень легко сломается вследствие неверных действий из-за непонимания. 

то же самое относится к `UCS manager`. описывать работу с `vds`, как и большую часть конфигурирования `UCS manager` в рамках данной статьи я не буду. инструкций у `VMWare`, `Cisco`, разных how-to, вопросов-ответов на форумах и прочего в интернет более чем достаточно.


== сам процесс (с) порутчик ржевский
=== интеграция `ucsm` и `vcsa`
для того, чтобы `ucsm` мог создать `vds` в vCenter Server Appliance (`vcsa`), в который я буду загонять виртуалки, в поcледний нужно разрешить доступ через добавление ключа:
1. открываю `ucsm` → вкладка `vm` → `filter: all` → `лкм` по `vmware` → `export vCenter extension`, указываю какую-нибудь директорию, куда упадёт файл `cisco_ucs_vmware_vcenter_extn.xml`. вообще-то я не очень люблю делать скриншоты, но такой железкой хочется рисануться:[[br]][[Image(ext.png)]]
1. теперь нужно импортировать это расширение в `vcsa`. `VMWare` утверждает, что все операции с `vCenter` начиная с версии 5.1 можно делать через веб-клиент. может быть это и так, но каким образом импортировать этот файлик через веб-клиент я не нашёл ни в версии 5.1, ни в 5.5, ни в 6.0.[[br]][[br]]поэтому открываю `vmware vsphere client` версии 6.0 → верхнее меню → `plugins` → `manage plugins` → на пустом месте открывшегося окна со списком плагинов нажимаю `пкм` → `new plug-in...` → `browse...` → `cisco_ucs_vmware_vcenter_extn.xml` → `register plug-in`.[[br]][[br]]после успешной регистрации в списке должен появиться новый плагин `Cisco-UCSM-xxx`, где вместо xxx будет ключ, которому я сделал обфускацию в скриншоте выше.

теперь `vcsa` готов принимать команды от `ucsm`.

=== `vds` для `vm-fex`
`vm-fex` работает через `virtual distributed switch`, который нужно создавать и конфигурировать в `ucsm`, а последний в свою очередь применяет эту конфигурацию к `vcsa` через интеграцию, описанную в предыдущей части. вся работа в этой части будет происходит в `ucsm` во вкладке `vm`, поэтому я не буду в каждом пункте ссылаться на неё.
1. пкм по `vmware` → `configure vCenter` → в поля `name`, `description` и `hostname (or ip address)` записываю данные своего `vcsa`: `ares`, `gallente tackler`, `10.7.16.69` → два раза `next` → разделы `folders` и `datacenters` пропускаю → `finish`;
1. пкм на `ares` → `create datacenter` → в поля `name` и `description` записываю данные своего datacenter, который уже создан в `vcsa`: `dc` → `next` → раздел `folders` пропускаю → `finish`;
1. пкм на `dc` → `create folder` → в поля `name` и `description` записываю данные папочки, в которой будет `vds`: `ucs` → `next` → раздел `DVSs` пропускаю → `finish`;
1. пкм на `ucs-main` → `create DVS` → в поля `name` и `description` записываю данные своего `vds`: `ucs-main` → `OK` → `admin state: enable`.
1. `vds` готов, теперь создам `port profiles`. по сути это то же самое, что и `distributed port group`, но в терминологии `cisco`. у меня их всего две штуки: один профиль транковый, где разрешены все виланы, в другом нетэгированный вилан с менеджмент-сетью для виртуальных машин, гостевые системы которых по каким-то причинам не могут тегировать трафик:
 a. пкм `port profiles` → в поля `name` и `description` записываю данные профиля `vm-mgmt-ucs` → `host network io performance`: `high performance` → в списке `VLANs` выбираю одну радиокнопку в третьей колонке напротив вилана `mgmt`;
 a. тоже самое делаю для транкового порта `vm-trunk-ucs`. только вместо выбора радиокнопки, в первой колонке отмечаю галочками все виланы. подразумевается, что необходимые виланы в `ucsm` уже созданы;
 a. теперь надо сделать, чтобы эти два профиля попали в `vds`. лкм по одному из них, выбираю вкладку `profile clients` → зелёный `[+]` справа → `name`: `all`, `datacenter`: `all`, `folder`: `all`, `distributed virtual switch`: `all`. со вторым профилем то же самое.
должно получиться примерно так:[[br]][[Image(vdsports.png)]][[br]]
через небольшое время этот `ucs-main` появился в `vcsa`. если этого не произошло, то стоит заглянуть во вкладку `fsm` - скорее всего, там будет написана причина.

=== сервера для гипервизоров
как я уже упоминал в начале, для того, чтобы в запустить сервер, нужно навесить на него профиль. чтобы это сделать, профиль нужно сначала создать. создание профилей для серверов - это не цель данного документа, поэтому я подразумеваю, что всё необходимое для формирования профиля уже есть. затрагивать я буду только то, что имеет отношение к `vm-fex`, без чего `DirectPath I/O` не заработает. на каждом сервере я буду делать по четыре статических сетевых интерфейса. все четыре будут привязаны к одной фабрике с `failover` на вторую. половина серверов будет работать с фабрикой `а`, другая половина, соответственно, с `b`.

первый интерфейс останется в обычном vSwitch. второй интерфейс будет подключен в обычный `vds`. третий интерфейс будет подключен в `ucs-vds`. вообще-то участие интерфейса в виде `uplink` в `ucs-vds` смахивает на атавизм, т.к. от него ничего не зависит. но если этого не сделать, то проброс виртуальных интерфейсов не работает - я проверял :) четвёртый интерфейс я планировал подключить в дополнительный `vds` в виде софтового `cisco nexus 1000v`, чтобы можно было более гибко конфигурировать порты виртуалок, но руки до него пока не дошли.

все интерфейсы я добавляю в свичи без `stand by` на уровне `VMWare`, т.к. `failover` реализован на уровне `UCS`. замечу, что для обычных лезвий или серверов с двумя интерфейсами, не резервируемыми на уровне подключения, такая схема неверна. не стоит её бездумно повторять на не-`UCS`.

=== создание `adapter policy`
`adapter policy` - это сборник настроек для каждого сетевого интерфейса в сервере. первый `adapter policy` будет для четырёх статических интерфейсов гипервизора, а второй для динамических.
1. вкладка `servers` → `policies` → `root` → пкм по `adapter policies` → `create ethernet adapter policy` → `name`: `nn-vmw`, resources:
 a. `transmit queues`: `4`, `ring size`: `4096`;
 a. `receive queues`: `4`, `ring size`: `4096`;
 a. `completion queues`: `8`, `interupts`: `16`;
 a. переписывать `options` лениво, поэтому скриншот:[[br]][[Image(adapolopt.png)]]
1. снова вкладка `servers` → `policies` → `root` → пкм по `adapter policies` → `name`: `nn-vmw-pt`, resources:
 a. `transmit queues`: `8`, `ring size`: `4096`;
 a. `receive queues`: `8`, `ring size`: `4096`;
 a. `completion queues`: `16`, `interupts`: `32`;
 a. остальное то же самое.[[br]]очередей больше в два раза, потому что для работы проброса динамических интерфейсов нужно минимум по 8 очередей. источник в подтверждение привести пока не могу. если снова найду, то добавлю.

=== создание `vnic template` с группировкой
для того, чтобы на серверах были сетевые интерфейсы, нужно создать их шаблоны. шаблоны можно использовать напрямую в каждом профиле, а можно сгруппировать через `lan connectivity policy`. во втором случае для каждого серверного профиля или шаблона профиля достаточно будет лишь указать нужный `lan connectivity policy`, который сделает всё необходимое.

создаю два шаблона для статических интерфейсов. один шаблон будет работать с фабрикой `a` с `failover` на `b`, второй наоборот.

1. вкладка `lan` → `policies` → `root` → пкм по `vNIC templates` → `create vnic template` → `name`: `trunk-a` → `fabric id`: `a`, `enable failover` → `target`: `adapter` и `vm` (**внимание**! поменять эту настройку в готовом шаблоне уже не получится) → `template type`: `updating template` → отмечаю галочками все виланы → в `mac pool` выбираю предварительно созданный пул мак-адресов → `connection policies`: `dynamic vnic`. второй шаблон `trunk-b` такой же за исключением `fabric id`: `b`.
1. под группировкой я подразумеваю `lan connectivity policy`: вкладка `lan` → `policies` → `root` → пкм по `lan connectivity policies` → `create lan connectivity policy` → `name`: `esxi4-trunk-a` кнопкой `[+] add` далее добавляю 4 сетевых интерфейса:
 a. ставлю галочку напротив `user vnic template` и заполнять остаётся всего три поля: `name`: `nic0`, `vnic template`: выбираю созданный в предыдущем пункте `trunk-a`, `adapter policy`: `nn-vmw`, созданный [#созданиеadapterpolicy ранее];
 a. повторяю ещё три раза для `name`: `nic1`..`nic3`;
повторяю весь раздел для `name`: `esxi4-trunk-b` с привязыванием соответственно к фабрике `b`.

=== создание `bios policy`
`bios policy` - это настройки bios: то что можно изменить, зайдя в bios setup. нет смысла открывать консоль и заходить туда на каждом сервере, если всё это можно сделать централизованно сразу для пачки серверов.
1. вкладка `servers` → `policies` → `root` → пкм по `bios policies` → `create bios policy`:
 a. `name`: `fex`;
 a. не лишним будет поставить галочку напротив `reboot on bios settings change`;
 a. так же я обычно ставлю радиокнопку `reset` напротив `resume on ac power loss` - сервер же;
1. в разделе `processor`:
 a. `virtualization technology (vt)`: `enabled`;
 a. `direct cache access`: `enabled`;
1. в разделе `intel direct io` все радиокнопки в состояние `enabled`;
1. к работе `DirectPath I/O` это не относится, но ещё мне нравится включать `boot option retry` в разделе `boot options`;
1. это обязательный минимум для работы `DirectPath I/O`. остальное по необходимости, или сразу жать `Finish`. другие настройки можно сменить уже после создания полиси.

=== создание `service profile`
из него формируется то, что будет вешаться непосредственно на сервер и в соответствии с чем железка будет сконфигурирована. серверный профиль можно сделать напрямую, а потом клонировать. но правильней делать его из шаблона, настройки которого будут наследоваться и меняться на всех зависимых серверных профилях. шаблон серверного профиля включает в себя массу настроек, которые здесь не рассматриваются, подразумевая, что они уже выполнены без моей помощи. здесь я рассмотрю только то, что нужно для работы `DirectPath I/O`.

вкладка `servers` → `service profile templates` → пкм по `root` → `create service profile template`. `name`: `esxi4-a`, `type`: `updating template`. вторую настройку нельзя будет сменить на готовом шаблоне, поэтому очень важно на забыть установить её при создании.

в разделе `networking` выставляю `dynamic vnic connection policy` в значение `create a specific dynamic vnic connection policy`. `number of dynamic vnics`. в соответствии с табличкой в [#link7 мануале] значение по-умолчанию у меня здесь `54`: модель `ucs` у меня 6296, модели `iom` во всех корзинах 2208, значит в соответствии с последней строчкой максимальное число `vif` может быть 58 для mtu 9000 и 58 с mtu 1500, всего 116. данная информация соответствует действительности лишь отчасти.

очевидно, что индус, который писал [#link7 мануал] не до конца разобрался в вопросе. правда в том, что если [#созданиеadapterpolicy полиси адаптеров] содержат завышенные значения количества очередей и `ring size`, то 54 динамических интерфейса сервер переварить не может. от завышенных значений я отказаться не могу - на серверах будет огромная нагрузка по трафику, гораздо больше 10 гигабит на порт (о том как это так - напишу дальше). методом математического тыка значений в полисях адаптеров и количества `vif` я выяснил, что в моём случае здесь успешно выставляется число 33 и остаётся небольшой запас для дополнительных статических интерфейсов. вдруг понадобится.

именно по этой причине я выбрал схему с четырьмя статическими интерфейсами. 33 динамических интерфейса это много, их действительно //[[span(style=color: #FF0000, должно хватить всем)]]//. но у меня в кластерах есть большое количество полуспящих виртуалок, которым мощная сеть ни к чему. тратить на них один из 33-х динамических интерфейсов - слишком расточительно. поэтому эти виртуалки будут жить на обычном `vds`, пока не начнут требовать большего. а поскольку большинство из них никогда до этого не дойдут, то жить на обычном `vds` они будут постоянно.

`adapter policy`: `nn-vmw-pt`, `protection`: `protected`. это значит, что динамические интерфейсы, которые `ucsm` создаст для `DirectPath I/O` на каждом сервере будут равномерно разбросаны по обоим фабрикам. не могу вспомнить, почему я решил так сделать. возможно, просто интуиция. возможно также, это неверно и динамические интерфейсы стоит прибивать к той же фабрике, что и статические. время покажет. переделать недолго, несложно и виртуалки для переделки останавливать не придётся.

`how do would you like to configure lan connectivity?`: `use connectivity policy`. вот тут-то я и воспользуюсь группировкой шаблонов сетевух интерфейсов, которая создавалась [#шаблонысгруппировкой здесь]. `lan connectivity policy`: `esxi4-trunk-a`.

раздел `vnic/vhba placement` проще показать скриншотом:[[br]][[Image(placement.png)]]

в разделе `operational policies` нужно выставить [#созданиеbiospolicy созданный] недавно `bios policy`. на этом можно создание шаблона серверного профиля завершаю, `finish`.

шаблона теперь можно создать непосредственно сам профиль. вкладка `servers` → `service profile templates` → `root` → пкм по `esxi4-trunk-a` → `create service profiles from template`. `naming prefix`: `test`, `name suffix starting number`: `1`, `number of instances`: `1`. это значит что из шаблона будет создан единственный профиль c именем `test1`.

теперь нужно ассоциировать профиль с сервером. вкладка `servers` → `service profiles` → `root` → пкм по `test1` → `change service profile association`. выбираю `select existing server` и в появившейся табличке выбираю сам сервер, который нужно ассоциировать с созданным профилем. после нажатия на кнопку `ok` будет вопрос-предупреждение от `ucsm`, что сервер ребутнётся, делаем? отвечаю утвердительно и жду, пока `ucsm` подготовит сервер к работе.

пока `ucsm` готовит сервер стоит обратить внимание на вкладку `network` серверного профиля. выглядеть она должна примерно так:[[br]][[Image(viflist.png)]]

после успешного выполнения весь [#созданиеserviceprofile этот] раздел необходимо повторить для создания второго шаблона и профиля, который будет работать с фабрикой `b` вместо фабрики `a`.

=== женитьба
женитьбой в автомобилестроении называют момент соединения силовой установки с кузовом. это название для данного раздела тоже отлично подходит.

процесс установки `esxi` я пропущу. это очень просто и совсем неинтересно. напишу лишь, что `esxi` я ставил из образа `Vmware-ESXi-5.5.0-2068190-custom-Cisco-5.5.2.3.iso`, который качал [#link3 здесь], а потом обновлял до `ESXi550-201512001.zip` [#link5 отсюда]. в результате, по утверждениям `vCenter`, получилась версия `5.5.0-3248547`. как вариант, можно сразу установить `Vmware-ESXi-5.5.0-3248547-Custom-Cisco-5.5.3.2.iso` ([#link4 ссылка]) - результат должен быть тот же. хотя установочный образ `esxi` специально подготовлен для серверов `Cisco`, он почему-то не включается в себя драйвер `cisco virtual machine fabric extender` (`vm-fex`).

его нужно [#link6 скачивать] отдельно: нужен файл `cisco-vem-v161-5.5-1.2.7.1.zip` из `ucs-bxxx-drivers-vmware.2.2.6c.iso`. этот драйвер надо залить в гипервизор и установить: `esxcli software vib install -d /tmp/cisco-vem-v161-5.5-1.2.7.1.zip`. кстати говоря, все вышеприведённые ссылки качаются свободно, нужно только зарегистрироваться. единственное, что нельзя скачать свободно, - это vCenter. я использую `VMware-VCSA-all-6.0.0-3634788.iso` (он же `6.0u2`), но так же имеется успешный стенд с `VMware-VCSA-all-6.0.0-2800571.iso`. установку `vcsa`, добавления в него гипервизоров и создании кластеров я так же пропущу.

стоит, наверное, аргументировать почему я выбрал `vcsa` версии `6` и `esxi` версии `5.5`. веб-клиент у всех предыдущих `vcsa` почти полностью написан на `flash`. его тормоза ещё можно было бы пережить, но для доступа к консоли виртуалок требуется плагин vmware, работающий через `npapi`, который `chrome` похоронил с песнями и плясками в сентябре 2015. учитывая недоступность некоторых функций в `vmware vsphere client`, запускать его совсем не хочется, оставаясь на веб-клиенте. в шестой версии `vcsa` с этим стало всё хорошо, можно спокойно пользоваться.

что касается `esxi`, то в версии `5.1` я наступил на весьма неприятный [#link8 баг], который не давал менять конфигурацию `iscsi` через `host profile`. а без профилей, после того, как их уже распробовал, жить очень грустно. кроме того, в `vds` на 5.5 появились фильтры, что весьма приятно. с их помощью можно реализовать функциональность, для которой раньше приходилось ставить `cisco nexus 1000v`. с `esxi` версии `6.0` тоже не сложилось: в `ucs-bxxx-drivers-vmware.2.2.6c.iso/VM-FEX/Cisco/VIC/ESXi_6.0/README.html` написано: `Not supported`.

приступим к свадьбе. в [#vdsдляvm-fex одном] из прошлых разделов я создал `vds`, который уже должен быть в `vcsa`. дело за малым: добавить один из четырёх интерфейсов сервера в `vds`. и тут меня ждал жестокий облом. один из сетевых интерфейсов гипервизора должен быть связан с с одним из аплинков `vds`. вот как выглядит список аплинков ~~здорового человека~~ `vcsa` версии `5.5`:[[br]][[Image(vcsa55uplinks.png)]]

а вот список аплинков ~~курильщика~~ `vcsa` версии `6.0`:[[br]][[Image(vcsa60uplinks.png)]]

разумеется, связать сетевой интерфейс с несуществующим аплинком невозможно, о чём красноречиво сообщает окошко с ошибкой:[[br]][[Image(vcsa60uplinkerror.png)]]

это было очень обидно. мой вопрос на эту тему в `supportforums.cisco.com` проигнорировали, а на `communities.vmware.com` в ответ получил выступление какого-то клоуна из группы `vmware employees`, который совсем не разбирался в теме, но зачем-то задавал тупые вопросы. на `vcsa` версии `5.5` очень не хотелось по причине выпиленного `npapi` из `chrome`, поэтому пришлось копнуть глубже. оказалось, что все аплинки у `vds`, созданный `ucsm` на месте, а вот веб-клиент их показать почему-то не может.

проблема решилась добавление хоста в `vds` через `vmware vsphere client`. единственное, что немного омрачило результат - не получалось выбрать конкретный аплинк, к которому привязывался сетевой интерфейс. но и эта проблема в итоге решилось добавлением `esxi` в `vds` через `host profile`. вероятно, возможен ещё один способ добавления `esxi` в `vds` - через консольный клиент или sdk, но я этот способ не пробовал, поэтому не могу достоверно утверждать, работает ли.

как я уже упоминал выше, для работы `DirectPath I/O` достаточно добавить один сетевой интерфейс в `vds`, созданный `ucsm`. назначить `esxi` адрес в этом `vds` необходимости нет. более того, это вредно ввиду ограниченности количества динамических интерфейсов. поэтому в моей конфигурации один сетевой интерфейс у `esxi` живёт в обычном `vSwitch` для того, чтобы в аварийной ситуации или при недоступности `vcsa`, связность до `esxi` можно было восстановить, а два других в обычном `vds` версии 5.5.

но вернёмся к ~~нашим баранам~~ запуску `DirectPath I/O` на виртуальной машине. единственное, что осталось сделать - это выключить виртуальную машину, мигрировать сеть в `ucs-vds`, убедиться что сетевой адаптер виртуальной машины - это `vmxnet3`, поставить галочку `reserve all guest memory` в настройках памяти и запустить. результат не заставит себя ждать. в информации о сетевой карте в строке `DirectPath I/O` появится значение `Active`. а в `ucsm` это будет выглядеть так:[[br]][[Image(ucsvms.png)]]

=== bond. james bond. или нет?
хочу показать как выглядит виртуалка, которая отдаёт примерно 14 гигабит/с. разумеется, происходит это с участием `irqbalance` и с правильно настроенным линуксом:
{{{
top - 13:35:03 up 9 days, 17:41,  2 users,  load average: 0.00, 0.00, 0.00
Tasks: 336 total,   1 running, 334 sleeping,   0 stopped,   1 zombie
Cpu0  :  1.4%us,  8.5%sy,  0.0%ni, 90.2%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu1  :  1.0%us,  7.8%sy,  0.0%ni, 91.2%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu2  :  1.4%us,  4.4%sy,  0.0%ni, 94.2%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu3  :  1.3%us,  8.1%sy,  0.0%ni, 90.6%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu4  :  2.5%us,  9.3%sy,  0.0%ni, 81.4%id,  0.0%wa,  0.0%hi,  6.8%si,  0.0%st
Cpu5  :  1.8%us,  9.5%sy,  0.0%ni, 83.6%id,  0.0%wa,  0.0%hi,  5.1%si,  0.0%st
Cpu6  :  1.8%us,  6.6%sy,  0.0%ni, 86.3%id,  0.0%wa,  0.0%hi,  5.2%si,  0.0%st
Cpu7  :  2.6%us,  8.8%sy,  0.0%ni, 83.9%id,  0.0%wa,  0.0%hi,  4.7%si,  0.0%st
Cpu8  :  2.9%us,  8.3%sy,  0.0%ni, 83.3%id,  0.0%wa,  0.0%hi,  5.4%si,  0.0%st
Cpu9  :  1.0%us,  8.0%sy,  0.0%ni, 91.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu10 :  1.3%us,  8.9%sy,  0.0%ni, 89.4%id,  0.0%wa,  0.0%hi,  0.3%si,  0.0%st
Cpu11 :  1.3%us,  9.3%sy,  0.0%ni, 89.4%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu12 :  0.7%us,  3.1%sy,  0.0%ni, 96.2%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu13 :  1.1%us,  5.3%sy,  0.0%ni, 88.0%id,  0.0%wa,  0.0%hi,  5.6%si,  0.0%st
Cpu14 :  2.9%us,  8.7%sy,  0.0%ni, 81.9%id,  0.0%wa,  0.0%hi,  6.5%si,  0.0%st
Cpu15 :  1.8%us,  9.0%sy,  0.0%ni, 82.4%id,  0.0%wa,  0.0%hi,  6.8%si,  0.0%st
Mem:   8059572k total,  3767200k used,  4292372k free,   141128k buffers
Swap:  4194300k total,        0k used,  4194300k free,   321080k cached
}}}
такое положение вещей как-бэ намекает, что можно позволить себе и больше! да, действительно можно. вопрос в том как отдавать. свичи `ucs` (они же фабрики) не умеют делать агрегацию линков с серверами. городить много интерфейсов и делать `ecmp`? нет! всё гораздо проще, делать вообще ничего не надо. любой виртуальный интерфейс лезвия `Cisco UCS` имеет такое же ограничение пропускной способности на котором корзина подключена к фабрикам. а вот корзина уже подключается к фабрикам как раз через port-channel максимум восьми десятигигабитных линков в каждую фабрику. итого, теоретический предел одного сетевого интерфейса - это 80 гигабит/с.

== полезные ссылки
[=#link1 1.] [https://pubs.vmware.com/vsphere-55/index.jsp#com.vmware.vsphere.networking.doc/GUID-BF2770C3-39ED-4BC5-A8EF-77D55EFE924C.html кусок мануала о DirectPath I/O от VMWare];[[br]]
[=#link2 2.] [http://web.archive.org/web/*/http://infrastructureadventures.com/2011/09/29/deploying-cisco-ucs-vm-fex-for-vsphere-part-1concept/ DirectPath I/O на Cisco UCS через vm-fex];[[br]]
[=#link3 3.] [https://my.vmware.com/group/vmware/details?downloadGroup=OEM-ESXI55U3B-CISCO&productId=353 cisco customer image for vmware esxi 5.5u2 install cd];[[br]]
[=#link4 4.] [https://my.vmware.com/group/vmware/details?downloadGroup=OEM-ESXI55U2-CISCO&productId=353 cisco customer image for vmware esxi 5.5u3a install cd];[[br]]
[=#link5 5.] [https://my.vmware.com/group/vmware/patch скачивание патчей для esxi];[[br]]
[=#link6 6.] [https://software.cisco.com/download/release.html?mdfid=283853163&softwareid=283853158&release=2.2(6c) драйвер cisco vm-fex для esxi];[[br]]
[=#link7 7.] [http://www.cisco.com/c/en/us/solutions/collateral/data-center-virtualization/unified-computing/vm_fex_best_practices_deployment_guide.html cisco vm-fex best practices];[[br]]
[=#link8 8.] [http://kb.vmware.com/kb/2002488 неприятный и неисправленный баг в esxi 5.1];[[br]]

== обсуждение
почесать языком можно [blog:2016/04/03 здесь].