[freebsd] releng/13.1 issues as vbox-6.1 guest

Владимир Друзенко vvd at unislabs.com
Thu Jul 7 21:44:28 EEST 2022


Повторяю в рассылку. Просьба не отвечать на личные адреса, а только в 
рассылку.

07.07.2022 20:40, Anton Saietskii пишет:
> On Thu, Jul 7, 2022, 20:22 Владимир Друзенко via freebsd 
> <freebsd at uafug.org.ua> wrote:
>
>     07.07.2022 18:23, Anton Saietskii пишет:
>     > Приветствую,
>     > Пока тут тестировал сабж, наткнулся на пару неприятных моментов и
>     > хотел бы поделиться -- вдруг кому полезно будет.
>     >
>     >
>     > ** Проблема №1:
>     > После установки emulators/virtualbox-ose-additions при запуске
>     > виртуалки системная дата устанавливается на 2299-й год. Это не
>     зависит
>     > от настройки "hw clock in utc" (ещё бы, тут проблема не просто в
>     > часовом поясе...)
>     > Синхронизация времени выполняется с помощью vboxservice, который
>     > находится достаточно далеко от начала rcorder, из-за чего некоторые
>     > важные файлы имеют дату в далёком будущем, т.к. изменяются во время
>     > загрузки перед запуском vboxservice.
>     > Я не проверял, станет ли системная дата опять нормальной, если
>     снести
>     > пакет, а из конфига виртуалки вычистить все свойства, которые
>     > устанавливаются guest additions. Вместо этого решил закостылить так:
>     >
>     > $ cat /etc/rc.d/save_time
>     > #! /bin/sh
>     >
>     > # KEYWORD: nojail shutdown
>     >
>     > . /etc/rc.subr
>     >
>     > name=save_time
>     > rcvar=save_time_enable
>     >
>     > start_cmd="${name}_start"
>     > stop_cmd="${name}_stop"
>     >
>     > load_rc_config $name
>     > : ${save_time_enable:=NO}
>     > : ${save_time_file:="/var/db/save_time"}
>     >
>     > save_time_start() {
>     >          if [ -r $save_time_file -a -s $save_time_file ]; then
>     >                  saved_time=`cat $save_time_file`
>     >                  echo "Restoring date/time from $save_time_file
>     as $saved_time"
>     >                  date $saved_time
>     >          fi
>     > }
>     >
>     > save_time_stop() {
>     >          echo -n "Saving date/time to $save_time_file... "
>     >          date +%Y%m%d%H%M > $save_time_file
>     >          if [ $? -ne 0 ]; then
>     >                  warn "cannot save."
>     >          else
>     >                  echo "done."
>     >          fi
>     > }
>     >
>     > run_rc_command "$1"
>     >
>     > То, что системные часы "отстанут" на время, в течение которого
>     > виртуалка была выключена, в принципе, для меня вполне терпимо.
>     > Обнаружилась лишь небольшая неприятность после: cron запускается в
>     > прошлом, т.к. vboxservice по дефолту при своём запуске корректирует
>     > время постепенно, а не моментально. Это решилось включением
>     > соответствующей опции:
>     > $ grep vboxservice_flags /etc/rc.conf
>     > vboxservice_flags="--timesync-set-start"
>     >
>     > Готов ловить летящие помидоры и яйца, если вдруг таковые имеются.
>
>     Что-то явно делаете не так или умалчиваете.
>     У меня 10+ лет работает 4 сервера с headless VirtulBox
>     (3=>4=>5=>6) на
>     FreeBSD (9=>10=>11=>12=>13) и ничего подобного замечено не было.
>
> 1. Создао виртуалку.
> 2. Поставил фрю.
> 3. Поставил пакет virtualbox-ose-additions-nox11
> 4. Запустил VBox{guest|service} (не включая автозапуск)
> 5. Перезагрузился.
> 6. В виртуалке год 2299
>
>     Конечно же при остановке сервера виртуалки savestate.
>
> Не вижу смысла при переходе хоста в S3 каждый раз писать весь объём 
> памяти виртуалки на диск.

Может из-за этого все проблемы. Так что лучше проверить.


>
>     > ** Проблема №2:
>     > Имеется следующая конфигурация дисковой подсистемы:
>     > Контроллер LSI Logic SAS, к нему подключен VDI с опциями
>     nonrotational
>     > и discard (чтобы этот VDI сам ужимался).
>     > Внутри виртуалки: GPT (1M align) -> GELI (4K sectorsize, trim
>     > пропускается) -> ZFS (autotrim=on).
>     > Хост может уходить в S3/S4, никаких специальных действий для
>     виртуалки
>     > при этом не предпринимается.
>
>     savestate
>
>
>     > Через несколько дней внезапно побились контрольные суммы, что
>     > затронуло пяток файлов, в messages было такое:
>     >
>     > Jun 24 17:21:36 freebsdvm ZFS[998]: checksum mismatch, zpool=zroot
>     > path=/dev/da0p3.eli offset=3501813760 size=12288
>     > Jun 24 17:21:36 freebsdvm ZFS[1002]: pool I/O failure,
>     zpool=zroot error=97
>     > Jun 24 17:21:36 freebsdvm ZFS[1006]: checksum mismatch, zpool=zroot
>     > path=/dev/da0p3.eli offset=3502202880 size=12288
>     > Jun 24 17:21:36 freebsdvm ZFS[1010]: pool I/O failure,
>     zpool=zroot error=97
>     > Jun 24 17:21:36 freebsdvm ZFS[1014]: checksum mismatch, zpool=zroot
>     > path=/dev/da0p3.eli offset=3502190592 size=12288
>     > Jun 24 17:22:28 freebsdvm ZFS[1028]: pool I/O failure,
>     zpool=zroot error=97
>     > Jun 24 17:22:28 freebsdvm ZFS[1032]: pool I/O failure,
>     zpool=zroot error=97
>     >
>     > Недолго думая, я переустановил затронутые пакеты, прогнал scrub
>     да успокоился.
>     > Ещё через несколько дней опять побились контрольные суммы, но
>     это уже
>     > затронуло один файл. Виртуалка начала неистово читать диск, а в
>     > messages я успел прочесть следующее (таких сообщений, как ранее
>     уже не
>     > было):
>     >
>     > Jul  4 15:13:40 freebsdvm kernel: [93142] mpt0: request
>     > 0xfffffe0005dd7d80:54344 timed out for ccb 0xfffff80018953000
>     > (req->ccb 0xfffff80018953000)
>     > Jul  4 15:13:40 freebsdvm kernel: [93142] mpt0: attempting to abort
>     > req 0xfffffe0005dd7d80:54344 function 0
>     > Jul  4 15:13:40 freebsdvm kernel: [93142] mpt0: abort of req
>     > 0xfffffe0005dd7d80:54344 completed
>     > Jul  4 15:13:40 freebsdvm kernel: [93142] mpt0: attempting to abort
>     > req 0xfffffe0005dd7d80:54344 function 0
>     > Jul  4 15:13:40 freebsdvm kernel: [93142] mpt0: abort of req
>     > 0xfffffe0005dd7d80:54344 completed
>     >
>     > С памятью на хосте всё в порядке. Что это за чудеса были и как
>     вообще
>     > такое дебажить -- я не знаю, но подозреваю, что тут какой-то косяк в
>     > реализации TRIM (а вот со стороны FreeBSD или VirtualBox?) Запускал
>     > руками zpool trim в виртуалке, vboxmanage --modifymedium 'VM
>     disk.vdi'
>     > --compact на хосте -- всё нормально, ничего не бьётся.
>     > Пока сменил тип контроллера на LSI Login SCSI и наблюдаю.
>
>     А зачем это всё?
>
>     zfs на хосте со сжатием. В гостях ufs. Запись нулей на диск внутри
>     виртуалки освобождает место на хосте.
>
> В качестве эксперимента. Задача -- протестировать FDE GELI + ZFS 
> (последний раз я подобное поднимал ещё тогда, когда GELI хотел /boot 
> на отдельном незашифрованном разделе).
> Хост в ZFS не умеет, но это и несущественно в связи с постановкой задачи.

Хост не FreeBSD?! С этого и надо начинать. Может это проблемы настройки 
хоста.


> Файлы, кстати, не бьются после выхода хоста из S3. Оно какое-то время 
> работает себе спокойно, потом внезапно ломается. Не думаю, что тут 
> вообще есть какая-то связь с S3.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.uafug.org.ua/pipermail/freebsd/attachments/20220707/614d885c/attachment-0001.htm>


More information about the freebsd mailing list