@glaucidium

Возможно ли сделать наследование изменений в виртуалках?

Узнал, что в qemu можно сделать диск-снимок, унаследовав его от родительского, а сам он будет содержать только изменения(и весить мало).
(команда qemu-img create -f qcow2 -b дискИсточник.qcow2 -F qcow2 снимко-диск.qcow2)

Тут-же захотелось создать слои шаблонных виртуалок(свежая ОС -> настроенная ОС -> ОС с графикой), а от них наследовать задаче-ориентированные.
Но проблема в том, что диск-источник изменять нельзя. Т.е. захотев доустановить что-то в предка, изменение не унаследуется в потомков.

Есть ли способ добиться проникновения изменений в потомков?
Или может в других виртуалках наследование дисков реализовано полноценно?
  • Вопрос задан
  • 89 просмотров
Решения вопроса 1
@hx510b
"Я знаю, что ничего не знаю"
Проблема в том, что работаете с блочными устройствами, и делаете снепшот блочного устройства, поверх, которого применяется файловая система. Т.е. пока мастер образ не меняется, производные снепшоты содержат консистентную файловую систему. А вот после изменения мастер образа - файловая система на снепшотах "развалится".

Такое теоретически возможно для контейнеров (OpenVZ, LXC, Docker), которые работают поверх файловой системы. Но изменения мастера образа приведут хоть и к корректным изменениям файловой системы, но разломают целостность на прикладном уровне. Например, знания пакетного менеджера об установленных пакетах будут неверными.

Если схема мастер-образ - дочерний снепшот позволяет вам сократить расход дискового пространства и ускорить развертывание новых копий. То для дальнейших синхронных изменений производных гостевых систем используйте системы управления конфигурациями (SCM), такие как Ansible, Salt и т.п.

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

Для экономии ресурсов возможно есть смысл посмотреть в сторону гибридных схеме:
KVM + LXC, KVM + Docker и т.п. решения. Где за счет KVM получается хорошая изоляция, а за счет контейнеров достигается высокая плотность с минимальным перерасходом ресурсов.
Ответ написан
Комментировать
Пригласить эксперта
Ответы на вопрос 1
@Tabletko
никого не трогаю, починяю примус
И даже больше: если вы внесёте какие либо изменения в родительский диск, то сразу же приведёте в нерабочее состояние дочерние диски, базировавшиеся на нём. Так как вы хотите дифференциальные диски не работают.
Ответ написан
Комментировать
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы