Directpath i o vmware что это такое

Обновлено: 21.11.2024

vSphere DirectPath I/O (DPIO) — это функция vSphere, которая использует процессоры с поддержкой VT, установленные на хостах ESXi, для повышения производительности виртуальных машин. Функция процессора в некоторых процессорах Intel и AMD, называемая блоком управления памятью ввода-вывода (MMU), переназначает передачи прямого доступа к памяти (DMA) и прерывания устройства. Это позволяет виртуальным машинам обходить vmkernel и получать прямой доступ к физическому оборудованию. Несмотря на то, что DPIO доступен в vSphere 4, он был улучшен для vSphere 5. Например, vMotion теперь поддерживается для виртуальных машин с включенным DPIO на оборудовании Cisco UCS, хотя это Обратите внимание, что для использования этой функции виртуальная машина должна быть настроена с DPIO на Cisco UCS через распределенную модульную систему Cisco Virtual Machine Fabric Extender (VM-FEX).

За исключением виртуальных машин, настроенных с DirectPath на Cisco UCS в распределенной модульной системе VM-FEX, включение DPIO для виртуальной машины делает следующие функции недоступными для этой виртуальной машины:

  • в движении
  • Оперативное добавление и удаление виртуальных устройств
  • Записать и воспроизвести
  • Отказоустойчивость
  • ГК
  • Снимки

Взаимодействуя напрямую с оборудованием, DPIO может повысить производительность ВМ за счет сокращения циклов ЦП, которые в противном случае использовались бы для преобразования vmkernel. Ввод-вывод DirectPath — это расширенная функция, которую рекомендуется использовать только для сред с существенно высокими сетевыми нагрузками. Все, что чрезвычайно чувствительно ко времени/задержке, может выиграть от DPIO. Подробнее о преимуществах производительности здесь.

Настройка ввода-вывода DirectPath на хосте ESXi

Для того, чтобы DPIO работал на ваших хостах, необходимо выполнить ряд предварительных условий. Прежде всего, вам необходимо убедиться, что процессор вашего хоста ESXi поддерживает транзитную передачу данных и включена поддержка виртуализации. Вы можете проверить это в клиенте vSphere, перейдя на свой хост, затем на вкладку «Конфигурация» и «Дополнительные параметры». Если вы видите сообщение: «Хост не поддерживает сквозную конфигурацию», то вам следует проверить правильность настройки BIOS сервера.

После того, как вы внесли необходимые изменения, сообщение «не поддерживается» должно быть заменено сообщением о том, что «в настоящее время нет устройств, поддерживающих транзит».

Итак, теперь вы можете щелкнуть Настроить сквозную передачу , а затем выбрать устройства, которые будут настроены для сквозной передачи:

Выберите устройство, для которого вы настраиваете сквозную передачу, и нажмите "ОК". Примечание. Если вы выберете устройство, которое ESXi уже использует, вам будет представлено предупреждающее сообщение. Это может быть очень полезно, если вы случайно выберете не то устройство:

Теперь устройства должны отображаться как доступные для прямого доступа. Примечание. Если значки устройств содержат оранжевую стрелку, вам потребуется перезагрузить хост, прежде чем устройство можно будет назначить виртуальной машине:

Настройка устройства PCI на виртуальной машине

Последний шаг — настроить виртуальную машину для использования устройства. Следующий процесс описывает, как это сделать:

  1. В клиенте vSphere выберите виртуальную машину.
  2. Нажмите "Изменить настройки".
  3. Выбрав вкладку "Оборудование", нажмите "Добавить".
  4. Выберите устройство PCI, нажмите «Далее».
  5. Выберите ранее настроенное транзитное устройство и нажмите "Далее".
  6. Нажмите "Готово".

Есть несколько вещей, о которых следует помнить, наряду с ограничениями, упомянутыми ранее:

<р>1. Виртуальная машина должна быть выключена перед добавлением устройств PCI.

<р>2. К ВМ, работающей на ESXi 5, можно добавить до 6 устройств PCI.

<р>3. Добавление устройства DirectPath к виртуальной машине устанавливает резервирование памяти в соответствии с размером памяти виртуальной машины.

Справочники и полезные ссылки

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

VMware DirectPath I/O – это технология, доступная в vSphere 4.0 и более поздних версиях, которая использует аппаратную поддержку (Intel VT-d и AMD-Vi), чтобы предоставить гостям прямой доступ к аппаратным устройствам. В случае сети виртуальная машина с вводом-выводом DirectPath может напрямую обращаться к физическому сетевому адаптеру вместо использования эмулированного (vlance, e1000) или паравиртуализированного (vmxnet, vmxnet3) устройства. Хотя и паравиртуализированные устройства, и ввод-вывод DirectPath могут поддерживать высокую пропускную способность (свыше 10 Гбит/с), ввод-вывод DirectPath может дополнительно экономить циклы ЦП при рабочих нагрузках с очень большим количеством пакетов в секунду (скажем, > 50 тыс./с).Однако ввод-вывод DirectPath не поддерживает многие функции, такие как совместное использование физической сетевой карты, перераспределение памяти, vMotion и управление сетевым вводом-выводом. Поэтому VMware рекомендует использовать ввод-вывод DirectPath только для рабочих нагрузок с очень высокой скоростью передачи пакетов, когда для достижения желаемой производительности может потребоваться экономия ЦП за счет ввода-вывода DirectPath.

Ввод-вывод DirectPath для сети

VMware vSphere 4.x предоставляет гостям три способа выполнения сетевого ввода-вывода: эмуляция устройства, паравиртуализация и ввод-вывод DirectPath. Виртуальная машина, использующая ввод-вывод DirectPath, напрямую взаимодействует с сетевым устройством, используя его драйверы устройств. Хост vSphere (под управлением ESX или ESXi) участвует только в виртуализации прерываний сетевого устройства. Напротив, виртуальная машина (ВМ), использующая эмулируемое или паравиртуализированное устройство (далее называемое виртуальным сетевым адаптером или виртуализированным режимом), взаимодействует с виртуальным сетевым адаптером, который полностью контролируется хостом vSphere. Хост vSphere обрабатывает прерывания физического сетевого адаптера, обрабатывает пакеты, определяет получателя пакета и при необходимости копирует его в целевую виртуальную машину. Хост vSphere также является посредником при передаче пакетов через физическую сетевую карту.

С точки зрения пропускной способности сети паравиртуализированная сетевая карта, такая как vmxnet3, в большинстве случаев соответствует производительности ввода-вывода DirectPath. Это включает в себя возможность передавать или получать 9+ Гбит/с TCP-трафика с одной виртуальной сетевой картой, подключенной к виртуальной машине с 1 виртуальным ЦП. Однако ввод-вывод DirectPath имеет некоторые преимущества по сравнению с виртуальными сетевыми адаптерами, такие как более низкие затраты на ЦП (поскольку он обходит выполнение уровня сетевой виртуализации vSphere) и возможность использовать аппаратные функции, которые еще не поддерживаются vSphere, но могут поддерживаться гостевой системой. драйверы (например, механизм разгрузки TCP или разгрузка SSL). В виртуализированном режиме работы хост vSphere полностью контролирует виртуальную сетевую карту и, следовательно, может предоставлять множество полезных функций, таких как совместное использование физической сетевой карты, vMotion и управление сетевым вводом-выводом. Обходя этот уровень виртуализации, ввод-вывод DirectPath уступает функциям виртуализации потенциально более низким затратам ЦП, связанным с сетью. Кроме того, для операций ввода-вывода DirectPath требуется резервирование памяти, чтобы гарантировать, что память виртуальной машины не будет выгружена, когда физический сетевой адаптер попытается получить доступ к памяти виртуальной машины.

Отчет VMware о производительности операций ввода-вывода DirectPath и эмуляции

Компания VMware использовала микротест netperf [1] для построения графика прироста операций ввода-вывода DirectPath в зависимости от скорости передачи пакетов. Для оценки VMware использовала следующую установку:

  • Виртуальная машина SLES11-SP1 в vSphere 4.1. vSphere работала на двухпроцессорном процессоре Intel E5520 (частота 2,27 ГГц) с сетевым адаптером Broadcom 57711 10GbE в качестве физического сетевого адаптера.
  • В качестве источника или приемника трафика использовалась собственная машина Linux.
  • Эталонный тест UDP_STREAM для netperf, а также функции пакетной передачи и интервала для отправки или получения пакетов с контролируемой скоростью.

На приведенном выше рисунке показана экономия ЦП благодаря вводу-выводу DirectPath в процентах от одного ядра к скорости передачи пакетов (пакетов в секунду — PPS). Сразу видны преимущества ввода-вывода DirectPath при высокой скорости передачи пакетов (100 000 пакетов в секунду). Однако также очевидно, что при более низких скоростях передачи пакетов преимущества ввода-вывода DirectPath не столь значительны. При скорости 10 000 кадров в секунду ввод-вывод DirectPath может сэкономить только около 6 % ресурсов одного ядра. Это важное наблюдение, так как многие корпоративные рабочие нагрузки не имеют очень высокого сетевого трафика (см. таблицы 1 и 2).

Чтобы еще больше проиллюстрировать конкретные варианты использования и преимущества ввода-вывода DirectPath, VMware также сравнила его производительность с производительностью виртуальной сетевой карты с тремя сложными рабочими нагрузками: рабочей нагрузкой веб-сервера и двумя рабочими нагрузками базы данных. Рабочая нагрузка и конфигурация веб-сервера были аналогичны SPECweb® 2005 (описаны в ссылке [2]). Мы запустили фиксированное количество пользователей, запрашивающих данные с веб-сервера, и измерили загрузку ЦП между вводом-выводом DirectPath и паравиртуализированной виртуальной сетевой картой. Из-за высокой скорости передачи пакетов этой рабочей нагрузки DirectPath I/O может поддерживать на 15 % больше пользователей на % используемого ЦП. Обратите внимание, что при типичной рабочей нагрузке веб-сервера пакеты, которые получает веб-сервер, меньше 1500 байт (в среднем 86 байт в наших экспериментах). Следовательно, мы не можем напрямую использовать числа получения на рис. 1 для расчета экономии ЦП.

Затем мы рассмотрели рабочую нагрузку базы данных с гораздо более низкой скоростью передачи пакетов. Мы использовали бенчмарк Order Entry [3] и измерили соотношение количества операций в секунду. Как и ожидалось, из-за низкой скорости передачи пакетов производительность виртуального сетевого адаптера и ввода-вывода DirectPath была одинаковой.

Матрица совместимости

DirectPath I/O требует, чтобы виртуальной машине был разрешен прямой доступ к устройству, а устройству было разрешено изменять память виртуальной машины (например, копировать полученный пакет в память виртуальной машины). Кроме того, виртуальная машина и устройство теперь могут совместно использовать важную информацию о состоянии, невидимую для ESX. Следовательно, использование ввода-вывода DirectPath несовместимо со многими основными функциями виртуализации.В таблице 3 представлена ​​матрица совместимости для ввода-вывода DirectPath.

Заключение

Как указано в начале этого поста, ввод-вывод DirectPath предназначен для конкретных случаев использования. Это еще одна технология, которую пользователи VMware могут развернуть для повышения производительности приложений с очень высокими требованиями к скорости передачи пакетов.

Дополнительная литература

Ссылки

SPECweb ® 2005 является зарегистрированным товарным знаком Standard Performance Evaluation Corporation (SPEC).

Недавно я обдумывал идею настроить виртуальную машину FreeNAS на моем хосте ESXi 6.5. Это дало бы мне альтернативный ресурс общего хранилища для добавления в среду тестирования. Имея это в виду, я сел и начал искать рекомендации, а что нет, о том, как выполнить задачу. Во многих сообщениях, с которыми я сталкивался, рекомендовалось использовать сквозную передачу или сквозную передачу, технически известную как ввод-вывод DirectPath. Моя первоначальная мысль заключалась в том, чтобы использовать RDM или старый добрый vmdk и подключить его к виртуальной машине FreeNAS.

Проблема с последним решением в основном связана с производительностью, несмотря на то, что это тестовая среда. С включенным DirectPath я могу предоставить виртуальной машине FreeNAS прямой доступ к паре неиспользуемых дисков, установленных на хосте. Поэтому, не задумываясь, я пошел дальше и включил сквозную передачу данных на контроллере хранилища на тестовом хосте ESXi.

А вот и большой отказ от ответственности. НЕ ДЕЛАЙТЕ ЭТОГО НА РАБОТАЮЩЕЙ СИСТЕМЕ. Вас предупредили!

Этот пост существует с единственной целью помочь какой-то бедняге оправиться от того, что оказалось глупой оплошностью. Об этом подробнее.

Что пошло не так?

Физический хост, который я выбрал для своего грандиозного плана, имеет один контроллер IBEX SATA с 3 подключенными к нему дисками. Ничего фантастического. Это просто программно эмулированный RAID, который ESXi даже не распознает, отсюда и неиспользуемые диски. Я использую только один диск, на который я также установил ESXi. Помните, что это тестовая среда. На этом диске также есть локальное хранилище данных по умолчанию и пара виртуальных машин.

Диск по умолчанию разбивается на несколько разделов во время установки ESXi. Два раздела, называемые bootbank и altbootbank, содержат двоичные файлы ESXi, которые загружаются в память в процессе загрузки. Я вернусь к этому позже.

Вернемся к включению ввода-вывода DirectPath на плате PCI, такой как контроллер системы хранения. На следующем снимке экрана я выделил рассматриваемый хост ESXi и пометил шаги, предпринятые для включения DirectPath для устройства PCI. Это можно сделать, просто установив флажок рядом с именем устройства. В данном случае я включил сквозную передачу на SATA-контроллере Ibex Peak. Имейте в виду, что это мой единственный контроллер хранилища.

После включения DirectPath вы получаете напоминание о том, что хост необходимо перезагрузить, чтобы изменения вступили в силу.

Опять же, не долго думая, я перезагрузил хост. Пять минут спустя, и хозяин снова был на линии. Я приступил к созданию новой виртуальной машины для FreeNAS, но быстро обнаружил, что у меня больше нет хранилища данных для ее создания. И меня вдруг осенило! При включенном DirectPath гипервизор больше не будет иметь доступа к устройству. Черт!

Вот тогда я и оказался с кучей недоступных ВМ в хранилище данных, которого больше не было.

В этот момент быстро бы возникла паника, если бы это была действующая система, но, к счастью, этого не произошло. Я начал копаться в клиенте vSphere и в первую очередь заметил, что адаптер хранилища Ibex не указан в разделе Адаптеры хранилища независимо от количества выполненных повторных сканирований.

Первое логичное решение, которое пришло на ум, заключалось в том, чтобы отключить ввод-вывод DirectPath на контроллере системы хранения, перезагрузить хост и вернуть все в прежнее великолепие. Я так и сделал, перезагрузил хост и подождал еще 5 минут только для того, чтобы обнаружить, что на хосте по-прежнему отсутствуют хранилище данных и адаптер хранения.

Исправление

Первое исправление, которое я нашел в сети, описано в статье KB1022011. По сути, вы подключаетесь к ESXi по SSH и проверяете /etc/vmware/esx.conf в поисках строки, в которой для владельца устройства установлено значение passthru. . Его нужно изменить на vmkernel, чтобы отключить сквозную передачу.Чтобы убедиться, что устройство является правильным, просмотрите значение /device и сравните его со значением Device ID в веб-клиенте vSphere; Настроить -> Устройства PCI -> Изменить.

В этом примере идентификатор устройства для контроллера хранилища — 3b25, что означает, что я знаю, что меняю правильный. Вы можете увидеть это на следующем снимке экрана.

Чтобы заменить запись, используйте vi, заменив passthru на vmkernel, что я и сделал. Я перезагрузил хост в третий раз, и, к моему большому раздражению, хранилище данных по-прежнему отсутствовало. Еще немного покопавшись, я наткнулся на эти две ссылки; Неправильный способ использования VMware DirectPath и KB2043048 .

Первая ссылка помогла мне решить проблему, а также вдохновила меня на написание этого поста, так что спасибо автору.

Итак, почему исправление не удалось?

Простое объяснение заключается в том, что сделанные изменения, учитывая мои настройки, не сохранятся, потому что все выполняется из энергозависимой памяти, то есть в ОЗУ. Это означает, что после перезагрузки ESXi изменения, сделанные в esx.conf, также теряются, и все возвращается на круги своя. В процессе загрузки двоичные файлы ESXi загружаются из раздела sda5 (bootbank) или sda6 (altbootbank) в зависимости от того, какой из них в данный момент помечен как активный.

Файлы конфигурации хоста автоматически и периодически резервируются с помощью скрипта в архив с именем state.tgz, который копируется в оба раздела в зависимости от того, какой из них активен в данный момент. Этот механизм резервного копирования позволяет вам вернуться к предыдущему состоянию с помощью Shift-R во время загрузки ESXi. К сожалению, в моем случае сквозное изменение также было заархивировано и скопировано в оба раздела или так показалось.

ESXi имеет полную видимость диска во время загрузки, что объясняет, почему ему это удается в первую очередь, несмотря на настройку сквозного доступа. Только при чтении esx.conf параметр сквозной передачи применяется принудительно/

Возврат к предыдущему состоянию с помощью Shift-R мне не помог, поэтому я пошел по пути GParted.

Исправление GParted

GParted, GNOME Partition Editor, бесплатная утилита для управления дисками на базе Linux, которая бесчисленное количество раз спасала меня. Вы можете создать загрузочный USB-накопитель GParted, загрузив ISO отсюда и используя Rufus.

Как уже упоминалось, нам нужно изменить параметр passthru в резервной копии файла esx.conf, который находится в архиве state.tgz. . Для этого мы должны сначала распаковать state.tgz, который содержит второй архив, local.tgz.

Распаковка local.tgz дает папку /etc, в которой мы находим esx.conf. Находясь там, откройте esx.conf< /em> в редакторе. Найдите и измените запись passthru и сожмите папку /etc обратно в state.tgz.< /эм>

Наконец мы перезаписываем исходные файлы state.tgz в каталогах /sda5 и /sda6 и перезагружаем хост.

Вот вся процедура в пошаговой форме.

Шаг 1. Загрузите сервер ESXi с USB-накопителя GParted. После этого откройте окно терминала.

Шаг 2. Выполните следующие команды.

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

Здесь я показываю файл, подключенный к хосту по SSH

Шаг 4. Скопируйте самый последний файл state.tgz в /temp. Здесь я предположил, что самым последним файлом является тот, который находится в папке /mnt/hd1. У вас может быть иначе.

Шаг 5. Распакуйте файл state.tgz и полученный файл local.tgz с помощью tar. У вас должен получиться каталог etc, как показано на рисунке.

Шаг 6. Перейдите к /temp/etc/vmware и откройте esx.conf в vi.

  • Нажмите [/] и введите passthru, а затем Enter. Это приведет вас к строке, которую нужно отредактировать, при условии, что passthru включен только для одного устройства. Если нет, убедитесь, что идентификатор устройства совпадает с указанным выше.
  • Нажмите [Insert] и измените значение на vmkernel.
  • Нажмите [ESC], [:] и введите wq.
  • Нажмите [Enter], чтобы сохранить изменения.

Шаг 7. Сожмите архив и скопируйте его обратно в /mnt/hd1 и /mnt/hd2.

Перезагрузите хост, и ваше хранилище данных и виртуальные машины должны вернуться к жизни. Процедура мне подошла. Адаптер хранилища, хранилище данных и виртуальная машина вернулись к жизни без видимых проблем.

Заключение

Мораль этой истории заключается в том, чтобы тестировать, тестировать и тестировать, прежде чем воспроизвести что-то в производственной системе. Чтение руководства и предварительное исследование помогут избежать подобных ситуаций. Правильным решением, конечно, в этом случае было бы установить второй контроллер хранилища и включить на нем DirectPath. Оптимальным решением будет установка FreeNas на правильное оборудование вместо его виртуализации, о чем я не писал, но могу рассказать в следующем посте. А пока ознакомьтесь с полным списком сообщений о VMware в этом блоге, чтобы узнать о других интересных темах.

Автор: Саймон Лонг, 3 августа 2009 г.

Ввод-вывод VMware VMDirectPath

Что такое ввод-вывод VMware VMDirectPath?

VMDirectPath позволяет гостевым операционным системам напрямую обращаться к устройству ввода-вывода, минуя уровень виртуализации. Этот прямой или сквозной путь может повысить производительность систем VMware ESX, в которых используются высокоскоростные устройства ввода-вывода, такие как 10-гигабитный Ethernet. К одной виртуальной машине можно подключить до двух транзитных устройств.

Ввод-вывод VMDirectPath экспериментально поддерживается для следующих устройств хранения и сетевого ввода-вывода:

  • Адаптеры Fibre Channel QLogic QLA25xx 8 Гбит/с
  • Адаптеры Fibre Channel Emulex LPe12000 8 Гбит/с
  • адаптеры LSI 3442e-R и 3801e (на базе чипа 1068) SAS 3 Гбит/с
  • Контроллер Intel 82598 10 Gigabit Ethernet
  • Контроллеры Broadcom 57710 и 57711 10 Gigabit Ethernet

VMware регулярно добавляет поддержку нового оборудования. Проверьте поддержку вашего оборудования на портале VMware Hardware Compatibility Guide.

Каковы преимущества использования VMware VMDirectPath I/O?

Ввод-вывод VMDirectPath можно использовать, когда вашей гостевой ОС требуется более высокая производительность устройства ввода-вывода. Это также позволяет использовать устройства ввода-вывода, которые не поддерживаются сервером ESX напрямую, и связывать их с виртуальными машинами, поскольку уровень виртуализации обходится.

Каковы недостатки использования VMware VMDirectPath I/O?

  • После прямого подключения виртуальной машины к устройству ввода-вывода ваша виртуальная машина больше не сможет использовать такие функции, как VMotion и DRS.
  • У вас не может быть двух устройств в двух разных контекстах (например, одно используется VMkernel, а другое — транзитное) с использованием одного слота PCI. Например, сетевая карта с двумя головками выделена для VMkernel ИЛИ доступна для транзита. При выборе одного из них автоматически выбирается и другой. В диалоговом окне вы узнаете, почему это произошло.

Как настраивается ввод-вывод VMware VMDirectPath на хосте ESX?

Чтобы настроить ввод-вывод VMDirectPath на хосте ESX, следуйте инструкциям в руководстве VMware: Настройка устройств транзита ввода-вывода VMDirectPath на хосте ESX

В этом посте описывается процедура настройки сетевого устройства NVIDIA для работы в режимах транзитного ввода-вывода DirectPath и динамического ввода-вывода DirectPath в VMware ESXi 7.0 и обратно.

Назначаемое оборудование — это платформа, которая позволяет динамическому вводу-выводу DirectPath использовать vSphere HA и DRS для начального размещения ВМ.

При включении ВМ с профилем NVIDIA vGPU DRS выберет хост ESXi для размещения этой ВМ.

Назначаемое оборудование требует аппаратной версии 17 виртуальной машины.

Балансировка нагрузки DRS для устройств ввода-вывода Dynamic DirectPath пока недоступна. Так что только для первоначального размещения ВМ.

Перед настройкой устройства для сквозной передачи PCI убедитесь, что платформа и устройство соответствуют требованиям для сквозной передачи PCI, см. документ VMware vSphere VMDirectPath I/O: Требования для платформ и устройств (2142307).

Чтобы настроить транзитные устройства на хосте ESXi:

<р>1. Выберите хост ESXi из списка VMware vSphere Client.

<р>2. Войдите в режим обслуживания хоста ESXi.

<р>3. В Навигаторе щелкните Настройка, Оборудование и устройства PCI. На странице сквозной конфигурации перечислены все доступные сквозные устройства.

<р>4. Нажмите НАСТРОЙКА ПЕРЕХОДА.

<р>5. Выберите устройства и добавьте метку оборудования ("ConnectX-5").

<р>6. Нажмите "ОК".

Слот PCI устройства — 13:00.1 .

<р>7. Убедитесь, что для устройства настроен сквозной режим:

а. Выберите хост ESX\ESXi в списке VMware vSphere Client.

б. В навигаторе выберите «Настроить», «Оборудование», «Устройства PCI и устройства с поддержкой сквозной передачи». На странице "Устройства с поддержкой сквозной передачи" перечислены все включенные устройства сквозной передачи.

<р>в. Подтвердить:

<р>8. Выйдите из режима обслуживания хоста ESXi.

<р>1. В Navigator в клиенте vSphere щелкните правой кнопкой мыши виртуальную машину и выберите Изменить настройки.
2. Выберите вкладку Виртуальное оборудование.
3. Нажмите Добавить другое устройство.

Выберите устройство PCI.

Примечание. Когда устройство назначается, виртуальная машина автоматически резервирует память для полного настроенного объема памяти.

Готово!

Перед проверкой планировщика распределенных ресурсов (DRS) с помощью начального размещения рабочей нагрузки убедитесь, что vSphere DRS включен:

<р>1. Выберите узел кластера из списка VMware vSphere Client.

<р>2. Убедитесь, что vSphere DRS включен.

<р>3. Установите уровень автоматизации на «Вручную». И нажмите ОК.

Мы установили уровень автоматизации на "Вручную" только для просмотра рекомендации по размещению. После этого вы сможете вернуть DRS на уровень полиции вашей компании.

Distributed Resource Scheduler (DRS) начальное размещение рабочей нагрузки Dynamic DirectPath I/O

Необходимо использовать одни и те же устройства с поддержкой PCI Passthrough (идентификатор PCI устройства) на всех серверах ESXi для первоначального размещения DRS рабочей нагрузки Dynamic DirectPath I/O.

В нашем случае это 13:00.1

<р>1. В Navigator в клиенте vSphere щелкните правой кнопкой мыши выключенную виртуальную машину, выберите «Питание» и «Включение питания».

<р>2. Вы увидите рекомендации по включению питания.

<р>3. Убедитесь, что у вас есть сетевой адаптер в гостевой ОС ВМ.

<р>4. Выключите виртуальную машину.

<р>5. Войдите в режим обслуживания сервера ESXi.

<р>6. Включите виртуальную машину.

<р>7. Вы увидите новые рекомендации по включению питания.

Готово!

<р>1. В Navigator в клиенте vSphere щелкните правой кнопкой мыши виртуальную машину и выберите Изменить настройки.
2. Выберите вкладку Виртуальное оборудование.
3. Нажмите X на устройстве PCI, которое вы хотите удалить. И нажмите ОК.

Чтобы принудительно перейти в несквозной режим, выполните следующие действия:

<р>1. Выберите хост ESXi из списка VMware vSphere Client.

<р>2. Войдите в режим обслуживания хоста ESXi.

<р>3. В Навигаторе щелкните Настройка, Оборудование и устройства PCI. На странице сквозной конфигурации перечислены все доступные сквозные устройства.

<р>4. Нажмите НАСТРОЙКА ПЕРЕХОДА.

<р>5. Отмените выбор устройства, которое вы хотите перевести в обычный режим.

<р>5. Нажмите "ОК".

<р>9. Выйдите из режима обслуживания хоста ESXi.

Готово!

О Борисе Ковалёве

Последние несколько лет Борис Ковалев работал архитектором решений в компании NVIDIA, отвечая за сложное машинное обучение и передовые исследования и проектирование облачных вычислений на базе VMware. Ранее он более 15 лет работал старшим консультантом и архитектором решений в нескольких компаниях, в последнее время — в VMware. Он написал несколько эталонных проектов для VMware, машинного обучения, Kubernetes и контейнерных решений, которые доступны на веб-сайте документации NVIDIA.

Связанные документы

Этот документ предоставляется только в информационных целях и не должен рассматриваться как гарантия определенной функциональности, состояния или качества продукта.Ни корпорация NVIDIA, ни ее прямые или косвенные дочерние и аффилированные компании (совместно именуемые «NVIDIA») не делают никаких заявлений или гарантий, явных или подразумеваемых, в отношении точности или полноты информации, содержащейся в этом документе, и не несут ответственности за любые ошибки. содержащиеся здесь. NVIDIA не несет ответственности за последствия или использование такой информации или за любые нарушения патентов или других прав третьих лиц, которые могут возникнуть в результате ее использования. Этот документ не является обязательством по разработке, выпуску или доставке каких-либо Материалов (определение приведено ниже), кода или функций.
NVIDIA оставляет за собой право вносить исправления, модификации, дополнения, улучшения и любые другие изменения в этот документ. , в любое время без предварительного уведомления.
Клиент должен получить самую свежую информацию перед размещением заказа и убедиться, что эта информация является актуальной и полной.
Продукты NVIDIA продаются в соответствии со стандартными условиями продажи NVIDIA. поставляются во время подтверждения заказа, если иное не оговорено в отдельном договоре купли-продажи, подписанном уполномоченными представителями NVIDIA и покупателем («Условия продажи»). Настоящим NVIDIA прямо возражает против применения каких-либо общих положений и условий для клиентов в отношении покупки продукта NVIDIA, упомянутого в этом документе. Никакие контрактные обязательства прямо или косвенно не формируются этим документом.
Продукты NVIDIA не разработаны, не одобрены и не имеют гарантии пригодности для использования в медицинской, военной, авиационной, космической технике или оборудовании жизнеобеспечения, а также в приложениях, где разумно ожидать, что сбой или неисправность продукта NVIDIA приведет к травме, смерти или ущербу имуществу или окружающей среде. NVIDIA не несет ответственности за включение и/или использование продуктов NVIDIA в таком оборудовании или приложениях, и поэтому такое включение и/или использование осуществляется на собственный риск клиента.
NVIDIA не делает заявлений и не гарантирует, что продукты, основанные на этом документе, будут подходит для любого указанного использования. Тестирование всех параметров каждого продукта не обязательно выполняется NVIDIA. Заказчик несет единоличную ответственность за оценку и определение применимости любой информации, содержащейся в этом документе, за обеспечение того, что продукт подходит и подходит для применения, запланированного заказчиком, и за выполнение необходимого тестирования для приложения, чтобы избежать отказа приложения. или продукт. Слабые стороны конструкции продукта клиента могут повлиять на качество и надежность продукта NVIDIA и привести к дополнительным или отличным условиям и/или требованиям, помимо тех, которые содержатся в этом документе. NVIDIA не несет никакой ответственности, связанной с любым невыполнением обязательств, ущербом, расходами или проблемами, которые могут быть основаны или связаны с: (i) использованием продукта NVIDIA каким-либо образом, противоречащим данному документу, или (ii) конструкцией продукта клиента.
Никакие лицензии, явные или подразумеваемые, не предоставляются в соответствии с какими-либо патентными правами NVIDIA, авторскими правами или другими правами интеллектуальной собственности NVIDIA в соответствии с данным документом. Информация, опубликованная NVIDIA относительно сторонних продуктов или услуг, не является лицензией NVIDIA на использование таких продуктов или услуг, а также гарантией или их подтверждением. Для использования такой информации может потребоваться лицензия от третьей стороны в соответствии с патентами или другими правами на интеллектуальную собственность третьей стороны или лицензия от NVIDIA в соответствии с патентами или другими правами на интеллектуальную собственность NVIDIA.
Воспроизведение информации в этом документе Документ допустим только в том случае, если он предварительно одобрен NVIDIA в письменной форме, воспроизведен без изменений и в полном соответствии со всеми применимыми экспортными законами и правилами, а также со всеми соответствующими условиями, ограничениями и уведомлениями.
ЭТОТ ДОКУМЕНТ И ВСЕ ПРОЕКТЫ NVIDIA СПЕЦИФИКАЦИИ, СПРАВОЧНЫЕ ПЛАТЫ, ФАЙЛЫ, ЧЕРТЕЖИ, ДИАГНОСТИКА, СПИСКИ И ДРУГИЕ ДОКУМЕНТЫ (ВМЕСТЕ И ОТДЕЛЬНО, «МАТЕРИАЛЫ») ПРЕДОСТАВЛЯЮТСЯ «КАК ЕСТЬ». NVIDIA НЕ ПРЕДОСТАВЛЯЕТ НИКАКИХ ЯВНЫХ, ПОДРАЗУМЕВАЕМЫХ, ПРЕДУСМОТРЕННЫХ ЗАКОНОМ ИЛИ ИНЫМ ОБРАЗОМ ГАРАНТИЙ В ОТНОШЕНИИ МАТЕРИАЛОВ И ЯВНО ОТКАЗЫВАЕТСЯ ОТ ВСЕХ ПОДРАЗУМЕВАЕМЫХ ГАРАНТИЙ НЕНАРУШЕНИЯ ПРАВ, КОММЕРЧЕСКОЙ ПРИГОДНОСТИ И ПРИГОДНОСТИ ДЛЯ ОПРЕДЕЛЕННОЙ ЦЕЛИ. В СТЕПЕНИ, НЕ ЗАПРЕЩЕННОЙ ЗАКОНОМ, NVIDIA НИ ПРИ КАКИХ ОБСТОЯТЕЛЬСТВАХ НЕ НЕСЕТ ОТВЕТСТВЕННОСТИ ЗА ЛЮБОЙ УЩЕРБ, ВКЛЮЧАЯ, ПОМИМО ПРОЧЕГО, ЛЮБОЙ ПРЯМОЙ, КОСВЕННЫЙ, ОСОБЫЙ, СЛУЧАЙНЫЙ, ШТРАФНЫЕ ИЛИ ПОСЛЕДУЮЩИЕ УБЫТКИ, КАКИМ ОБРАЗОМ ПРИЧИНЕН И НЕЗАВИСИМО ОТ ТЕОРИИ ОТВЕТСТВЕННОСТИ, ВОЗНИКШИЙ ЛЮБОЕ ИСПОЛЬЗОВАНИЕ ЭТОГО ДОКУМЕНТА, ДАЖЕ ЕСЛИ NVIDIA БЫЛА УВЕДОМЛЕНА О ВОЗМОЖНОСТИ ТАКИХ УЩЕРБОВ. Невзирая на любые убытки, которые покупатель может понести по какой-либо причине, совокупная и кумулятивная ответственность NVIDIA по отношению к покупателю за описанные здесь продукты ограничивается в соответствии с Условиями продажи продукта.

Товарные знаки
NVIDIA, логотип NVIDIA и Mellanox являются товарными знаками и/или зарегистрированными товарными знаками NVIDIA Corporation и/или Mellanox Technologies Ltd. в США и других странах. Другие названия компаний и продуктов могут быть товарными знаками соответствующих компаний, с которыми они связаны.

Авторское право
© Корпорация NVIDIA и ее филиалы, 2022 г. Все права защищены.

Читайте также: