VMware ESXI 6.7 + CentOS 8 + tuned (+ немножко packer) = использование 100% CPU со стороны ESXI host

Предыстория

При разворачивании нового полутестового проекта на CentOS 8 (система выбиралась эксплуатантом) практически сразу после разворачивания системы VMware сообщила о 100% использовании CPU виртуальной машиной. Пока систему настраивали на это никто не обращал внимание, но после запуска в полу-тестовую эксплуатацию со стороны ESXI host-а загрузка процессора постоянно 100%, а со стороны самой виртуальной машины колеблется в широких диапазонах со средним значением 50%.
Вот так выглядит график загрузки CPU для этой виртуальной машины:

Информации в сети, про возможные причины такого поведения очень мало, большая часть сводится к обновлению vmware-tools, изменения параметров энергосбережения, начиная от BIOS и заканчивая параметрами ядра и банальным советам по добавлению ресурсов к хосту. Т.к. на системе уже работали пользователи то возможности по выключению/перезагрузке VM для изменения конфигруации были очень ограничены по времени и проблема немножко "затянулась".

Проблема разрастается

Приходит запрос на создание еще двух VM от другого подразделения и тоже на Cent OS восьмой версии. Почти сразу после установки и начальной настройки эксплуатантом аналогично использование процессора со стороны хоста 100% на обеих вирутальных машинах. Поскольку системы еще не используются пользователями есть возможность детально разобраться в происходящем. Это не единственные CentOS 8 в работе, поэтому вариант что проблема в системе сразу отбрасывается, да и вряд ли бы осталось незамеченым другими такое поведение системы. Единственное что объединяет первый случай и второй это то, что они разворачивались из шаблона, который создавался packer-ом, другие системы ставились эксплуатантами самостоятельно с диска. Но есть еще одна система, которая тоже разворачивалась из подобного шаблона, но на которой такая проблема не наблюдается.

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

Выход из тупика

Начался поиск того, что отличает Cent OS от других дистрибутивов и отличий в нормально работающих системах с проблемными. Большой плюс оказался в том, что проблема повторялась и на абсолютно чистой минимальной системе. Просматривая список запущенных процессов в топе взгляд зацепился за tuned. Сравниваем активные профили на нормальных системах и проблемных и.... в первом случае имеем virtual-guest а в проблемных network-latency. В ходе коротких экспериментов выясням, что убитие процесса tuned, выключение или перевод в профиль virtual-guest моментально снижает использование процессора хостом до адекватного значения.

Почему в шаблоне собранном packer-ом по умолчанию для tuned используется другой профиль еще предстоит выяснить, хотя бы для удовлетворения собственного любопытства. Явных переконфигураций быстрым взглядом найдено не было.

Резюме

Tuned внутри виртуальной машины с "неправильным" профилем может не только не улучшить производительность, но и использовать все выделенные процессоры, при чем это будет видно только со стороны хоста. Внутри виртуальной машины все выглядит идеально. Массово такой эффект не проявляется, т.к. по умолчанию внутри виртуальных машин используется профиль virtual-guest, в то время как network-latency использовался по умолчанию на наблюдаемых аппаратных системах. Первопричина такого поведения не выяснена и требует совсем других инструментов, чем есть в наличии.