Hasher/vm-run

Иногда для запуска тестов в секции %check требуются рутовые привилегии, чтоб обойти это ограничение есть пакет rpm-build-vm (анонс), который позволяет запустить произвольную команду под qemu с псевдо-рутовыми привилегиями.

Он работает по аналогии с virtme, eudyptula-boot, vido и т.д. — бутится Linux ядро, где корень файловой системы (то есть содержимое hasher) предоставлен внутрь qemu по протоколу 9p, а init запускает вашу команду. Нужно учитывать, что хоть внутри виртуализации у вас будут рутовые привилегии, но снаружи будет обычный юзер builder. Если для тестов надо создавать файлы под рутом, то можно использовать tmpfs или создать ext4 образ в файле и примонтировать его куда требуется. Код возврата вашей команды вернется из vm-run.

Справка по возможностям: vm-run --help.

Пример, что добавить в spec для обычного user space пакета (не ядра и не модуля ядра) для запуска make check под рутом:

 BuildRequires: rpm-build-vm
 ...
 %check
 vm-run make check

Установка rpm-build-vm автоматически доставляет ядро kernel-image-un-def в hasher, что будет излишне при сборке ядра или ядерного модуля, поэтому есть пакет rpm-build-vm-run, который не имеет зависимостей к ядру. Пример использования для ядра или модуля:

 BuildRequires: rpm-build-vm-run
 ...
 %check
 vm-run "команды запуска тестов..."

Если тяжелые тесты имеет смысл запускать только под KVM и не запускать под эмуляцией, то следует использовать опцию --kvm=cond, она работает более надежно чем проверка [ -w /dev/kvm ]. В случае, если поддержка KVM не будет обнаружена vm-run --kvm=cond не запустит команду, но завершится успешно:

 %check
 vm-run --kvm=cond make check

Включение kvm

Для ускорения работы тестов полезно настроить kvm в hasher. Поддержка kvm есть на всех основых архитектурах.

A: Помимо того, что в системе должен быть загружен соответствующий вашей архитектуре kvm модуль (например, kvm-intel), необходимо ещё выполнить следующие два условия:

• В /etc/hasher-priv/system нужно добавить /dev/kvm в allowed_devices=, например:

 allowed_mountpoints=/proc,/dev/pts,/dev/shm
 allowed_devices=/dev/kvm

• В ~/.hasher/config добавить /dev/kvm в known_mountpoints=, например:

 known_mountpoints=/proc,/dev/pts,/dev/kvm

• Если нужно зайти в hasher интерактивно, то добавляется третье условие — при запуске hsh-shell нужно передать /dev/kvm в ключ --mountpoints=, пример:

 $ hsh-shell --mountpoints=/proc,/dev/pts,/dev/kvm

Советы по использованию

ext4

По умолчанию исходная файловая система пробрасывается по 9p (9pfs) на которой могут работать не все ожидаемые тестами возможности файловых систем или нет доступа на запись вне $HOME. Поэтому можно автоматически сгенерировать образ ext4 со всеми файлами. Два варианта:

1. Образ сгенерируется под пользователем rooter при создании сборочной среды (так что там может быть не все что вы ожидаете):

 BuildRequires: rpm-build-vm-createimage

и при запуске передать флаг --rootfs:

 vm-run --rootfs команды

2. Образ генерируется под builder во время запуска - BuildRequires: rpm-build-vm как обычно, а при запуске передать флаг --ext4:

 vm-run --ext4 команды

В обоих случая имя образа /tmp/vm-ext4.img, а отображение исходной файловой системы по 9p будет примонтировано в /mnt/9p.

sbin, user, sudo

• Если в PATH нежен /sbin:/usr/sbin поможет опция --sbin</code.
• Если для работы тестов нужно sudo, то есть fake sudo, которое включается опцией --sudo. (Пакет sudo для этого ставить не нужно.)
• Если запуск должен начинаться не под root, а под builder - есть опция --user. (Что автоматически добавляет sudo.) Некоторые тесты могут рассчитывать на работу под пользователем, а запускать рутовые команды через sudo.