надеюсь yum умеет составлять список установленных пакетов в одной системе

rpm -qa

перекинуть конфиги /etc из виртуалки (здесь должен помочь git — все правки в виртуалке буду фиксировать в виде коммитов в локальном git-репозитории в каталоге /etc и, соответсвенно, смогу накатить в виде патча на реальном сервере);

Используй etckeeper. Это обёртка над git, которая помогает сохранять права на файлы, что важно для нормальной работы системы (и для безопасности).

Вот собственно вопрос — насколько мой подход адекватен или сумасброден?

Не знаю насчёт адекватности, но в целом всё должно сработать. Пара дополнений:

• В CentOS (как и в Fedora) в initramfs по умолчанию складываются только те модули ядра, которые необходимы для загрузки системы на текущем железе. Чтобы это предотвратить, нужно создать файл /etc/dracut.conf.d/50-disable-hostonly.conf (или другим аналогичным именем) и таким содержимым: hostonly="no". После этого нужно пересоздать initramfs: dracut -vvvf. Подробности смотри в man dracut и man dracut.conf
• Как именно ты планируешь переносить готовую систему из виртуалки на реальный сервер? Сразу в виртуалке ставить на реальные диски, а затем просто воткнуть их в сервер? dd? tar? Тут тоже могут быть подводные камни. Как минимум, загрузчик и SELinux.

upd. Или я не правильно понял что именно ты хочешь сделать, и на самом деле ты хочешь не систему целиком переносить, а только файлы с настройками и данными из виртуалки на реальное железо?

К примеру, используйте «домашний сервер» как хост виртуализации с гипервизором qemu/kvm.

Миграция накопителей ВМ будет тривиальным действием.

Официальная документация: https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html...

Простая статья: https://www.itzgeek.com/how-tos/linux/centos-how-tos/install-kvm-qemu-on-cent...

Используй etckeeper

Спасибо за наводку. За правами раньше следил вручную.

и на самом деле ты хочешь не систему целиком переносить, а только файлы с настройками и данными из виртуалки на реальное железо

На текущий момент мысль следующая — установку системы на реальном железе произвести штатным установщиком с минимальным количеством устанавливаемых пакетов. Т.е. с initrd и т.п. проблем быть не должно, т.к. они не будут переносится с виртуалки. А потом доустановить нужные пакеты, применить патчи к конфигам и восстановить дополнительные данные. Думаю все действия в контексте «а потом» реализовать в виде скрипта, который минимальную систему превратит в полноценную.
Вот как бы чего не упустить в этом скрипте. Сейчас вот попробовал развернуть CentOS в виртуалке, так после минимальной установки сеть не поднялась. Управление сетью было возложено на NetworkManager, соответственно, в скрипте нужно будет NM отключать.
Вот опасаюсь, что какой-нибудь подобный подводный камень и не замечу...

Интересная мысль

Железо хоть и не первой свежести, но одну виртуалку должно потянуть.

А не лучше ли взять изначально систему управления конфигурациями, вроде Ansible,Salt или puppet? И изначально все правки конфигов и т.п. что будут производиться на виртуалке не править ручками, а производить с помощью системы управления конфигурациями? В итоге получите рецепт, приводящий Centos в минимальной установке в нужное вам состояние( с нужными пакетами, конфигами и т.п.). Примените потом чуть подправленную конфигурацию к физическому серваку, и профит...

P.S.: когда тестируется всё на виртуалке, а разворачивается потом на железом, обычно что-то где-то да упускается. Поэтому доводить до ума рецепты, из которых разворачивается сервак нужной вам конфигурации, уже под железную версию, вам таки по любому придётся уже по ходу дела.

Спасибо за информацию

Пробежался по диагонали про Ansible. Первое впечатление — то что нужно. На виртуалке нужно будет обкатать плей-лист, а потом применить его на физическом серваке.
Посмотрим как оно будет на практике...

PS: правда от наплыва новой информации столкнулся с «муками выбора» — Ansible можно использовать совместно с KVM/Qemu. Стоит-ли заморачиваться с виртуалкой?
С одной стороны железо «не ахти» и с виртуалкой производительность упадёт, но с другой стороны, если вдруг получиться сделать апгрейд железа, виртуалку будет проще(?) перенести (в сравнении с автоматическим развёртыванием новой системы).

Рассказываю, как делать в один жесткий диск.
Лепишь свою виртуалку, только разбивку для диска надо делать такую же как на будущем реальном серваке. Размер партиций +20%. Т.е. реальный размер развернутого дистрибутива, в среднем 5GB.
Весь срач выносишь в /home или ещё куда.
Потом с помощью CloneZilla делаешь образ виртуалки на жесткий диск или флешку и разворачиваешь его с помощью той же CloneZilla один в один на свой сервак.
Можно просто диск сервака подклоючить в VirtualBox напрямую и скопировать на него без танцев с CloneZilla.
Но мой тебе совет. Ставь VirtualBox и так её и оставь виртуальной. На сервак накатишь минимальную установку, а на него перенесешь свою виртуалку.
Останется только порты пробросить для доступа и всё, «ты в Хопре».
А доп. жесткие диски потом подлкючишь, если надо будет.

Я бы заморочился с виртуалкой. На виртуалке обкатываете всякие новшества, если всё Ок, применяете аккуратно обкатанные уже изменения на боевом серваке. Да и факапы разные случаются, тестовый полигон в лице виртуалки для того и нужен, что-бы выгребать их и исправлять на этапе, когда ещё не ясно на грабли мы сейчас наступим, или на твёрдую почву...