Как установить драйвер vmxnet3

Обновлено: 06.07.2024

Поводом для статьи стал виртуальный спор в кругу нескольких весьма продвинутых админов сред виртуализации, а также приближенных к ним лиц, т.е. – меня. Предметом спора была пропускная способность сетей в гипервизоре VMware ESXi, а точнее – производительность паравиртуального сетевого адаптера VMXNET3 в условиях высокой нагрузки. Гугл выдавал на эту тему ссылки типа

содержащие весьма противоречивые данные, к тому же многие тесты датировались 2012-2014 годами выпуска. Посему ваш покорный слуга принял решение провести небольшое тестирование самостоятельно.

«Под рукой» оказался практически незагруженный хост на базе материнской платы ASUS X99-E с процессором Intel Xeon E5-2620 v4 2.1 ГГц, заведомо достаточное количество RAM DDR4 2133. Версия гипервизора ESXi 6.5.0 Update 1 (Build 5969303).

Первым делом были созданы две ВМ с параметрами 4vCPU, 4 Gb RAM (All locked), 40 Gb disk (on paravirtual SCSI controller), сетевой адаптер VMXNET3. Версия ВМ – 13.

В каждую ВМ был установлен Windows Server 2012R2 со всеми обновлениями на 19.10.2017 и VMware Tools 10.1.7 (Build 5541682). Брандмауэр Windows выключен. На сетевые адаптеры внутри ВМ назначены статические IP-адреса. Для чистоты эксперимента виртуальные сетевые адаптеры обеих ВМ были подключены в отдельную порт-группу на отдельном виртуальном коммутаторе. Виртуальный коммутатор не подключался ни к одному физическому адаптеру, т.к. исследовалась производительность не конкретной сетевой карты, а паравиртуального адаптера и виртуального коммутатора.

Для замеров пропускной способности виртуальной сети между этими двумя ВМ использовался iperf 3.1.3 x64. На основании прошлого опыта использования iperf было принято решение тестировать несколько раз, с изменением количества TCP потоков от 1 до 16.

Поэтому первые 5 секунд после запуска теста решено было отбрасывать и не учитывать в результатах измерений. Благо у iperf для этого есть специальная опция –O. Также трижды производились замеры в обратном направлении трафика (опция iperf -R). Для всего этого на ВМ TEST1 был написан и запущен небольшой скрипт:

В результате были получены следующие сырые данные: <файл testresult01.log>

Offtopic: команда ECHO %date% %time% была включена в скрипт чтобы примерно отслеживать время выполнения тестов. Команда прекрасно работала из командной строки, в скрипте же выдавала почему-то один и тот же результат. Разбираться не стал. В следующем скрипте заменил

Быстрый парсинг сырого лога в табличку Excel дал вот такие результаты:

Налицо два явления: плавный рост пропускной способности до 8 потоков, а затем снижение и почти стабилизация. И различие скорости передачи в зависимости от направления. Последнее заинтересовало, и для проверки был проведен аналогичный замер, при котором ВМ «поменяли ролями»: TEST1 стала сервером, скрипт же выполнялся на TEST2. Результаты этого теста были аналогичными, для сокращения объема статьи их не привожу, но и объяснения им, кроме как «это особенность работы iperf в данной среде» на этот момент не было.

Нет ничего, что человек, а в особенности – админ среды виртуализации, не мог бы сделать лучше. Наверное. 20 гигабит в секунду на 8 TCP-потоках на дефолтных настройках были неплохим результатом, но я попытался его улучшить. Кто же знал, что все будет совсем не так просто, как предполагалось…

Включаем JUMBO FRAME.

Первое, что пришло на ум: пропускную способность можно повысить, включив Jumbo packet, т.е. увеличив MTU сетевого адаптера до 9000. В реальности, чтобы это работало, нужно, разумеется, чтобы все коммутаторы и маршрутизаторы между хостами также поддерживали MTU 9000. Поэтому включаем Jumbo frame в нашем виртуальном коммутаторе:

И смело лезем на обоих ВМ в настройки сетевого адаптера и делаем так:

Кстати, эту же настройку можно делать через PowerShell командой

А смотреть все настройки адаптера командой

Запускаем немного подправленный скрипт:

и идем пить чай с печеньками, ибо молотить он будет, по данным предыдущего замера, около часа. И действительно: <файл testresult02.log>

Для удобства сравнения накладываем график MTU 9000 на ранее полученный с MTU 1500:

Поведение графика «Туда» логично и немного предсказуемо. Но вот «Обратно» преподносит сюрприз. Особенно если сравнить значения второго «реверсного» замера с первым и третьим при TCP от 9 (выделено в таблице выше серым и зеленым): второй замер с опцией –R показывает шикарный результат 27 гигабит в секунду, но предыдущий и следующий замеры явно лажают. Это «ж-ж-ж» случилось явно неспроста, повторный тест с «обменом ролями», когда TEST1 стал сервером, а ТЕСТ2 – клиентом, это подтвердил: <файл testresult02-1.log>

Далее последовали: курение файн и факинг мануалов, множество тестовых запусков, тяжелые раздумья, снова курение мануалов и далее по кругу. Тест упорно показывал то 27 гигабит, то не поднимался выше 20. Единственным моим предположением, объясняющим происходящее, стало следующее: 20 с гаком гигабит в секунду – трафик, на обработку которого в виртуальном коммутаторе хост обязан потратить ощутимое количество процессорного времени. В случае, если это процессорное время шедулер распределяет «условно оптимально» и не пересекает с нагрузкой от ВМ – мы имеем тест со скоростью 27 гигабит. Если же «ошибается» – ВМ конфликтует за ядро pCPU с обработчиком виртуального коммутатора, и скорость теста падает.

Для косвенного подтверждения этого предположения я выставил обеим ВМ Scheduling Affinity на «четные» pCPU:

Offtopic: тут я несколько раз вводил «8,10,12,14» , но после нажатия Save и повторно Edit веб клиент упорно показывает «10,12,14,8». Ну да и бог с ним, вроде работает правильно.

Тест стал проходить намного стабильнее, esxtop показал косвенное подтверждение моего предположения:

Т.к. на хосте запущены только две мои тестовые ВМ, и для них обеих прописано Scheduling Affinity на pCPU, соответствующие физическим ядрам без гипертрейдинга – эти, в красной рамочке, периодически «прыгающие» между «нечетными» (гипертрейдинговыми) pCPU 50-70 процентов нагрузки и есть, по всей видимости, процессорное время, требуемое хосту для обработки трафика внутри виртуального коммутатора.

Итого – имеем скорость «без какой-то копеечки» 30 гигабит в секунду.
При этом настройки адаптера в обеих ВМ выглядят так:

Единственное отличие в этой картинке от аналогичной, приведенной ранее:

С «Enabled» или пустым полем производительность теста была ниже.По аналогии с «Включаем JUMBO FRAME» планировалось также «Включаем Receive Side Scaling», и «Настраиваем размеры буферов приема и буферов передачи», и даже «Меняем количество vCPU», однако реальность оказалась суровее. Перепробована куча вариантов настроек и ВМ, и сетевого адаптера. Описывать каждую нет смысла, т.к. результат теста они не улучшали. Поэтому за кадром остались некоторые очевидные и не совсем вещи, о которых имеет смысл сказать:

Выводы:

Паравиртуальный адаптер VMXNET3 – это жутко близко и запредельно быстро.

Планы: Попробовать то же самое с Linux-based оерационной системой. Например, с активно применяемой мной в жизни RouterOS Cloud Hoster Router. Вооруженный новыми знаниями я попробую штурмануть рубеж в 40 гигабит в секунду между ВМ.

Итак, вот перед вами свеженькая организация в vCloud Director, и вам только предстоит создать свою первую виртуальную машину. Сегодня расскажу, какие настройки выбирать при создании виртуальной машины, чтобы она работала и не просила есть. Поехали!

Cores per socket. Оставляйте 1 ядро на сокет, ставьте столько сокетов, сколько вам нужно виртуальных процессоров. Да, логично наоборот, но правильно так. Если у вас нет специализированных лицензионных требований. Например, вы платите за сокет, а больше сокетов означает больше лицензий. Не ставьте 2/2, чтобы получить 4. Сделайте 4/1. Такую машину гипервизор будет обслуживать оптимальным образом. Scheduler гипервизора будет меньше пенализировать такие ВМ.
Объясню на пальцах. Представьте, что проводник рассаживает пассажиров по вагону, вагон – как в Сапсане. В роли проводника scheduler, пассажиры – это ВМ. Пассажиров, которые едут в одиночку (однопроцессорные ВМ), ему распределить проще всего: их можно посадить на любое место. Семью из 4 человек (4-процессорные ВМ) уже сложнее. Им нужно найти 4 места в одном вагоне. А теперь представим, что все в семье хотят ехать только лицом друг другу, а таких групп мест – 4 вокруг стола – в вагоне только 2. С большой вероятностью такой семье придется пройти в следующий вагон (на следующий тик планирования). Это как раз та ситуация, как если бы вы выбрали 2 сокета по 2 ядра, чтобы получить 4. Скорее всего, придется подождать, чтобы нашлись подходящие места. Так же и с ВМ: ей придется ждать дольше, чем менее “прихотливым” ВМ с 1 сокетом и кучкой процессоров.

Хотя эта история актуальнее для старых версий ESXi. Начиная с 6.5 (но не ранее!) механизм vNUMA отвязан от количества виртуальных сокетов, и старая рекомендация “не плодить сокеты” не так категорична. Но все еще зависит от приложения внутри гостевой ОС.

Hot Add для CPU и Memory. Это опция добавления памяти CPU для работающей виртуальной машины. Казалось бы, прекрасная функция: не нужно гасить машину, чтобы докинуть ей ресурсов. Так вот, не все так просто, и не зря они по дефолту отключены. Лучше и не включать, если вы не знаете, что такое NUMA-топология. Допустим, под капотом облака у нас двухсокетный сервер. На каждом сокете 4 ядра. Работает это именно как 4+4, а не 8 ядер. Такая же тема с памятью: если на каждом сокете 128 ГБ, это не дает в сумме 256 ГБ. Каждый процессорный сокет имеет прямой доступ только к определенным слотам памяти. Каждый сокет вместе с причитающейся ему процессором и памятью – это физическая NUMA-нода.

Если виртуальная машина влезает в размер физической NUMA-ноды, то она исполняется внутри этой ноды. Если виртуалка не умещается в NUMA-ноду, например по памяти, то она будет использовать память из соседней NUMA-ноды. Путь к удаленной памяти будет извилист – через межпроцессорную шину. Работать это будет не так быстро, как если бы виртуалка использовала ресурсы одной ноды.

Когда вы включаете добавления виртуальных процессоров и памяти на горячую, все это идет только в нулевую NUMA-ноду. Например, добавилось еще 4 процессора, и на NUMA-ноде 0 стало 6, а на NUMA-ноде 1 – 2 процессора. Машину немного перекосило, и работает она также косо. Это связано с тем, что при включении vCPU Hot-Plug перестает работать vNUMA, через которую vSphere старается оптимизировать топологию NUMA для ВМ. Поэтому, принимая решение о включении CPU Hot-Add, учитывайте физическую топологию NUMA для обеспечения производительности ВМ. Это очень критично, если по каким-либо причинам в ВМ имеется несколько виртуальных сокетов. В этом случае несоответствие физической топологии вызовет сильное падение производительности: CPU Scheduler сойдет с ума, пытаясь предоставить процессорное время такой ВМ, что вызовет рост CPU Ready и Co-Stop.

Все добавленные виртуальные процессоры (5-8) и память попали на NUMA-ноду 0.

Отдельная история в том, что будет происходить внутри ОС и приложения после таких “добавок”. Поэтому если уж решили пользоваться этой опцией, то проверьте, поддерживает ли ваша ОС такое. Non-NUMA-Aware приложения могут сильно просесть по производительности при расположении на нескольких NUMA-нодах.

Если вы все-таки добавили процессоры или память на горячую, сразу планируйте перезагрузку ВМ (не только ОС) на ближайший запланированный даунтайм.

Галочки не ставим.

Дисковый контроллер (Bus type). Для дисков выбирайте дисковый контроллер Paravirtual. Этот тип контроллера требует установки драйверов в ОС VMware Tools. Paravirtual – это специальное виртуальное устройство, которое создавалось для работы в виртуализации и не эмулирует работу какого-то другого аппаратного устройства. Любая эмуляция аппаратного устройства всегда работает медленнее.

Если вы не хотите использовать Paravirtual (но почему?), выбирайте LSI Logic SAS. Если ОС не поддерживает и его — LSI Logic Parallel. Никогда не используйте SATA и IDE. ВМ будет медленно работать, в итоге вы не получите производительности, за которой идут в облако.

При инсталляции ОС даже свежая версия Windows может не найти драйвер для Paravirtual адаптера. В этом случае примонтируйте к ВМ два ISO файла — ваш загрузочный образ Windows и диск с VMware tools. На последнем есть необходимый драйвер.

Сетевой адаптер. Правильный выбор – VMXNet3. VMXNet3, как и дисковый адаптер Paravirtual, это паравиртуальное устройство. Оно также требует драйверов, которые входят в VMware Tools.

Если вдруг VMXNet3 не подходит (проявляется какая-то несовместимость), то на крайний случай используйте E1000E. Но не ожидайте от адаптера E1000E производительности больше, чем 1 Гбит.

В общем, E1000E без прямых указаний вендоров не используйте. Казалось бы, оно новее, но сделано для обеспечения еще большей совместимости c legacy.

Вот не надо E1000E.

VMware Tools. Следите, чтобы они были установлены в ОС, запущены и актуальны. В VMware Tools входят драйвера устройств и разные другие компоненты, которые позволяют общаться ОС виртуальной машины с гипервизором, и наоборот. Через них происходит синхронизация времени ОС с хостом виртуализации (отключаемо), ходят heartbeat’ы, которые показывают гипервизору, что виртуалка жива, и прочее. Для работы ОС на виртуальной машине нужны как минимум драйверы сетевой карточки, дискового адаптера. Свежие версии всего вот этого входят в VMware Tools.

По умолчанию актуальные версии Windows и Linux имеют драйвера для работы с виртуальными устройствами VMware, но если у вас будут VMware Tools, то эти драйвера будут всегда свежими. Для Linux рекомендуется использовать open-vm-tools. Это не просто лучшая интеграция с ОС, но и обновление драйверов вместе с системой.

Отдельные диски для данных. Используйте разные виртуальные диски под данные и операционную систему. Да и на физических серверах стоит так делать. Вы сможете отдельно бекапить эти диски (с разным расписанием, например), сможете переключить диск с данными или его клон на другую ВМ и прочее.

Кроме того, новый виртуальный диск также получит дополнительную квоту на дисковую производительность.

Кастомизация. При первом включении ВМ нужно кастомизировать, чтобы все настройки из облака (например выданный облаком IP-адрес) применились к ОС. После уберите эту галку от греха подальше, чтобы нечаянно не сбросить настройки ОС: SID, пароль администратора и т. п.

Конечно, все вышесказанное – упрощенная картина, слова “капитана О” и, вообще, “все же это знают”. Но, как показывает практика, более 70% ВМ в облаке содержат одну или сразу несколько описанных ошибок.

В этой статье мы рассмотрим, как установить VMWare Tools на различных гостевых ОС.

VMware Tools поддерживается на 32-и 64-разрядных операционных системах, включая Windows, Linux, Solaris, Mac OS X и другие.

Если в виртуальной машине не установлен набор VMWare Tools, то в гостевой операционной системе ВМ отсутствуют некоторые важные функции и возможности.

Также благодаря наличию VMTools в гостевой ОС обеспечивается:

Корректность и плавность миграции (VMotion and Storage VMotion) между хостами ESXi;
Выполнение автоматического перезапуска зависшей ВМ на другом хосте с помощью VMware High Availability (HA);
Корректное подключение и отключение дисков и файлов ISO образов;
Доступна кастомизация ОС при установке из шаблона (смена пароля администратора, настройка автовхода в ОС, смена уникального UID при клонировании с помощью sysprep и т.д.);
Повышается производительность ОС;
Использование memory ballooning для оптимизации использования оперативной памяти хоста.

Чтобы проверить, установлена ли VMWare tools в гостевой ОС виртуальной машине, выберите ее в клиенте vSphere.

Если VMTools не установлены, статус будет “Not Running, not installed”

Установка VMWare Tools в Windows

Чтобы установить VMTools в гостевой ВМ с Windows, нужно подключить ISO файл.

Установка VMware Tools в Linux

В дистрибутивах Linux есть два способа установки VMWare tools – с помощью ISO файла vmtools (по аналогии с Windows) и с помощью open-source пакета Open-VM-Tools.

Установка VMTools через ISO образ аналогична установке в Windows, только для запуска установки используется perl-скрипт.

Например, в CentOS установка выполняется так:

Вы можете установить все зависимости, необходимые для установки VMTools с помощью команды: yum -y install kernel-devel gcc dracut make perl

Смонтируйте ISO образ с VMTools;
В гостевой Linux смонтируйте ISO образ в каталог /mnt: mount /dev/cdrom /mnt/
Распакуйте архив с VMTools: cd /mnt/

Также вы можете установить VMTools с помощью пакета Open-VM-Tools (OVT) от VMware. Они доступны для установки из базовых репозиториев с помощью YUM или APT.

Например, в Debian/Ubuntu для установки OVT используется команды:

apt-get update
apt-get install open-vm-tools

Если вы используете Ubuntu с графическим интерфейсом, установите open-vm-tools-desktop:

apt-get install open-vm-tools open-vm-tools-desktop

В CentOS/RHEL используются такие команды:

yum update
yum -y install open-vm-tools

Для запуска службы и добавления ее в автозагрузку, выполните:

service vmtoolsd start
chkconfig vmtoolsd on

Обратите внимание, что после установки OVT в статусе ВМ будет указано:

Обзор виртуальных сетевых адаптеров виртуальных машин VMware vSphere

Как известно, компания VMware сделала несколько нововведений в продукте VMware vSphere в части сетевого взаимодействия виртуальных машин (vNetwork). В частности, появился виртуальный сетевой адаптер VMXNET 3, который является продолжением серии виртуальных устройств VMXNET, которые используются в качестве vNIC. Эти устройства не имеют физических аналогов (то есть эмулируется собственная карта VMware), а значит их использование доступно только после установки драйверов с VMware Tools.

Итак, собственно, эволюция устройств VMXNET:

VMXNET — это virtual network adapter, который оптимизирован для быстродействия сетевого взаимодействия виртуальных машин.
VMXNET 2 (Enhanced) — Адаптер VMXNET 2 базируется на обычной виртуальной сетевой карте VMXNET, но позволяет получить некоторые возможности по улучшению производительности, такие как Jumbo Frames (для сетей 10 ГБит), TCP Segmentation Offloading (TSO). Этот адаптер доступен только для хостов VMware ESX/ESXi 3.5 или выше.
Устройство VMXNET 2 поддерживается только для следующих гостевых операционных систем:

32- и 64-битные версии Microsoft Windows XP и более поздние
32- и 64-битные версии Red Hat Enterprise Linux 5.0 и более поздние
32- и 64-битные версии SUSE Linux Enterprise Server 10 и более поздние
32- и 64-битные версии Asianux 3 и более поздние
32- и 64-битные версии Debian 4/Ubuntu and later и более поздние
32- и 64-битные версии Sun Solaris 10 U4 and later и более поздние

Теперь приведем сетевые адаптеры виртуальных машин, которые используются на VMware ESX 4 в зависимости от различных условий:

Для того, чтобы использовать тот или иной тип виртуального сетевого адаптера для виртуальной машины, необходимо выставить его при добавлении к виртуальной машине при создании или редактировании свойств (см. рисунок). Также vNIC можно добавить с помощью добавления строчек в конфигурационный vmx-файл виртуальной машины:

Вместо [X] необходимо подставить номер виртуального сетевого адаптера, начиная с 0.

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