Комментарии 16
В кои-то веки хабрастатья, а не «как нам внедрить культуру рубашек василькового цвета в нашем смузи-стартапе»
А почему бы просто кучу qemu-system-x86_64 из cli не запустить? libvirt кажется избыточным.
Libvirt - по-привычке.
Возможно действительно можно будет убрать эту прослойку. Хорошая идея.
Если у вас будет время написать скрипт без libvirt лично мне было бы очень интересно посмотреть на результат.
Без libvirt команда будет примерно такая:
/usr/libexec/qemu-kvm -name guest=memtest1 \
-m 12288 \
-cpu host -smp 2 \
-kernel /opt/vm-memtest/memtest64.efi \
-chardev stdio,id=char0,logfile=/opt/vm-memtest/console-out-vm-memtest1,signal=off \
-serial chardev:char0 \
-display none \
-append console=ttyS0,115200 \
-enable-kvm > /dev/null 2>&1 &
Что происходит внутри вм будет видно через файл консоли /opt/vm-memtest/console-out-vm-memtest1. Остановить ВМ можно будет через kill ее процесса. Оформлять это дальше в скрипт для себя интереса не вижу, мне привычней с libvirt.
ИМХО есть варианты попроще Prime95 в режиме Torture Test или обычный stress с нужным набором --vm --vm-bytes --vm-stride --vm-hang --vm-keep или еще варианты https://wiki.archlinux.org/title/Stress_testing#Discovering_Errors
Если памяти много с виртуалками непонянто в каком именно модуле сбой
memtest на физике может указать вполне конкретный модуль и без management платы (да и не каждая укажет) можно конечно разобрать и через MCE в современных CPU + mcelog
выход из строя памяти это что то из разряда невозможного как по мне, и произойти такое может тролько при "исключительных навыках" персонала обслуживания, на моей практике с неисправностью памяти я сталкивался раза 3 и то на десктопах, не на серверах, особенности техпроцесса производства просто не допускают таких проблем.
но для масштабных систем контр таких проблем на жиденьких комплектующих обычно решается партизированием серверов на большое количество слабых систем и системы распределения, это обеспечивает стабильность и легкую диагностику
Да, память ломается значительно реже, чем диски. Но ломается все. И enterprice сервера (mb) и их бп, и вентиляторы и память в них. Ломается память даже в контроллере СХД. ВСЕ это видел многократно. В продвинутых серверах и СХД сбой памяти не приводит к простою в обслуживании (и такое видел).
А вот поломок десктопов наоборот не видел (просто я с ними не работаю). Но я не утверждаю, что они не ломаются.
Про деление сильных систем на много более слабых - это холивар про идеальный мир. По-прежнему остается набор ПО, который плохо партиционируется. Мир по-прежнему нуждается в многосокетных системах, хотя все мечтают о микросервисах.
На десктопах и лептопах память сбоит довольно часто. Но не по причине выхода из строя, а по причине пыли, попавшей на контакты модуля или слота памяти. Сталкивался десятки раз. Обычные продув и прочистка, как правило, лечат сабж.
Файл EFI называется memtest64.efi, а в скрипте он идет как memtest.x64.efi.
Надо бы подправить.
А еще попробовал повторить на Almalinux 9.3, ругается при запуске:
ERROR Unable to open file: /opt/vm-memtest/console-out-vm-memtest1: Permission denied
Если закомментировать строчку
--serial file,path=${MyDir}/console-out-vm-${vmprefix}${i} \
то запускается.
Возможно там есть нюанс с SELinux. На моей системе он был отключен. Попробуйте его отключить тоже. Вероятно ему контекст консольного файла не нравится.
Вы правы. После отключения SELinux все работает!
Вижу, вы исправили имя EFI в скрипте, но не до конца, надо еще убрать лишний x, чтобы стало memtest64.efi :)
И вопрос про методику тестирования. Допустим, гипервизор упал в процессе тестирования. Что делать дальше?
Запускать половину виртуальных машин с memtest и тестировать половину памяти или вынимать половину планок памяти физически и тестировать?
Нужно взять блокнот и записать текущую конфигурацию памяти, какой модуль где стоит. Заглянуть в системный контроллер, изучить нет ли каких-нибудь полезных сообщений о сбоях памяти (из которых можно сделать предположения что сломалось), найти документацию к материнской плате и выяснить порядок заполнения модулей. Убрать половину модулей памяти и повторить тест памяти. Система упадет - все повторяем, убираем еще половину памяти, не упадет - меняем все модули в сервере на извлеченные, вновь повторяем тест. И так далее. Все записываем. Добавляем/заменяем/убавляем, пока мы однозначно не выявим неисправный модуль памяти или поврежденный слот.
А 5 часов у вас занял только первый общий прогон? Потом еще и еще? Долго все равно получается искать виновника...
Если есть плохой модуль, с высокой степенью вероятности он проявит себя с негативной стороны существенно раньше. В статье упоминал про подобный нагрузочный тест с сотней вм для ESXi, там гипервизор падал в сиреневый экран примерно за 5-10 минут после старта memtest-виртуалок. За три часа мы провели достаточную серию тестов, чтобы выявить виноватый модуль, без него все стало хорошо.
Я не стал тут публиковать как развернуть сотню виртуалок в ESXi, там больше деталей: dhcp, tftp, pxeboot, ansible (community.vmware.vmware_guest module)
Как тестировать память быстрей?