Компания VMware обнаружила, что использование ядра Linux 5.13, которое было выпущено чуть больше месяца назад, приводит к серьезному снижению производительности нагрузок, работающих в гипервизоре ESXi. Речь идёт о падении вычислительной производительности до 3 раз и сетевой нагрузки до 40 %.

Проблема, вероятно, заключается в алгоритме работы планировщика по умолчанию. Специалисты VMware выяснили, что ранее планировщик работал с шагом в 15 мс, а теперь — 4 мс, что отражается на ESXi. Судя по всему, новые значения увеличивают число прерываний, что отражается на производительности системы в целом.

tecmint.com

Тестирование проводилось на ОС RHEL 8.1 в разных конфигурациях: одна виртуальная машина с 8 vCPU и 16 Гбайт памяти и 8 виртуальных машин по 4 vCPU и 8 Гбайт памяти. В комментариях к заметке на Phoronix, рассказывающей о проблеме, также отметили проблемы с сетевым подключением.

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

В прошлом году VMware выпустила первую экспериментальную версию ESXi для Arm-процессоров. Следует отметить, что перенос ESXi на Arm является огромной технической задачей не только потому, что ESXi — большая кодовая база со множеством технических тонкостей, но и потому что семантика, лежащая в основе процессоров Arm, сильно отличается от архитектуры x86.

Как сообщили в VMware, это потребовало тщательного тестирования и доработки, чтобы гарантировать, что ESXi работает как на Arm, так и на x86-платформах, сохраняя при этом высокие стандарты ESXi. Тем не менее, работа на Arm-версией продолжается, и на днях компания представила очередной минорный релиз ESXi Arm Edition 1.3.

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

Основные особенности ESXi Arm fling v1.3:

• Улучшенная совместимость оборудования (различные исправления ошибок и улучшения);
• Добавлена экспериментальная поддержка процессоров Ampere Altra (только для систем с одним сокетом);
• Поддержка ACPI для виртуальных машин;
• Поддержка NVMe и PVSCSI Boot в vEFI;
• Возможность обходного решения для загрузки ISO на некоторых серверах Arm;
• Устранение сбоя VMM для новых гостевых ОС и систем на базе Neoverse N1;
• Улучшенная виртуализация гостевого контроллера прерываний;
• Улучшенная виртуализация PMU;
• Улучшенная поддержка ВМ, использующих прямой порядок байтов (big endian).

VMware рассказала про ESXi-on-Arm в сентябре 2018 года, в 2019-ом предположила, что она сможет найти применение в SmartNIC или может оптимально подойти для облака AWS на базе Arm, но уже в 2020 году VMware заявила, что клиенты не видят необходимости в этом гипервизоре, поэтому он скорее всего не станет полноценным продуктом. Так что же изменилось с тех пор?

VMware собирается принять участие в конференции разработчиков Arm, которая начнется 6 октября. На этой конференции компания собирается представить новое решение для Arm, охватывающее локальную среду и периферийные вычисления.

Еще одним косвенным доказательством может являться новая учетная запись @esxi_arm в Твиттере с профилем, который гласит «Перенос знаменитого гипервизора VMware на 64-битный Arm». VMware даже заказала логотип ESXi-on-Arm, на логотипе которого изображена куропатка (в названии «Ptarmigan» есть слово «Arm»):

На данный момент нет достаточного количества информации о новом гипервизоре и остается только предполагать какой он будет, однако, учитывая, что VMware определенно любит Kubernetes и микросервисы, а AWS и Oracle заявляют, что Arm отлично подходит для подобных рабочих нагрузок, то такой анонс выглядит вполне логичным.

VMware в недавнем обновлении предоставила поддержку Kubernetes для пользователей vSphere, но на данный момент этот продукт еще недостаточно удобен в использовании. С появлением подобного продукта для Arm у VMware будет больше причин довести до совершенства поддержку контейнеров в своем гипервизоре.

Будет ли новый продукт востребован? Определенно да, ведь Arm активно развивает направление серверных процессоров. На днях она представила две новых платформы Neoverse c поддержкой SIMD SVE и формата bfloat16, а также интерфейсов PCIe 5.0, DDR5 и HBM: Neoverse N2 (Perseus) продолжит развитие универсальных CPU, а в V1 (Zeus) сделан упор на повышение производительности любой ценой.

Все больше пользователей начинают всерьез начинают рассматривать Arm как альтернативу х86, поэтому ESXi-on-Arm будет пользоваться популярностью.

На этой неделе появилась информация о проблеме совместимости между гипервизором VMware ESXi и Windows Server 2019. Отмечается, что из-за этого некоторые клиенты не смогут безопасно создавать снимки своих виртуальных машин. Это касается версий ESXi 6.7 и 6.5, причём проблема проявляется только в последней серверной ОС Microsoft.

Сбой происходит при использовании функции гипервизора под названием application quiescing. Эта функция готовит виртуальную машину к безопасной остановке, чтобы сделать снапшот. Создание «слепка» системы производится лишь после полной приостановки системы, иначе можно получить неполные или устаревшие данные: информацию из кэша, старые снапшоты и тому подобное.

theregister.co.uk

VMWare говорит, что проблема возникает из-за службы теневого копирования тома VSS, и в качестве временного решения предлагает отключить application quiescing перед созданием снапшота. Правда, как сказано выше, это, скорее всего, приведёт к потере данных. Запасной вариант — использование накопителей с MBR вместо GPT — не лучше.

Самое интересное, что на форумах поддержки VMware эта проблема периодически поднимается уже несколько месяцев. Однако решения пока нет. Возможной альтернативой является использование сторонних систем для создания снапшотов и работы с ними. Но это может оказаться дорогим удовольствием. Комментария от Microsoft пока не последовало.