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

Question

[glaucidium]

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

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

Есть ли способ добиться проникновения изменений в потомков?
Или может в других виртуалках наследование дисков реализовано полноценно?

Comments

[Valentin Barbolin]

Так не работает. Лучше придерживаться концепции докера, когда у тебя есть образ, а при сборке в него добавляется софт и конфиги. Соответственно при обновлении ты подтягиваешь новый образ докера и заново собираешь контейнер.

Answer 1

[hx510b]

Проблема в том, что работаете с блочными устройствами, и делаете снепшот блочного устройства, поверх, которого применяется файловая система. Т.е. пока мастер образ не меняется, производные снепшоты содержат консистентную файловую систему. А вот после изменения мастер образа - файловая система на снепшотах "развалится".

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

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

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

Для экономии ресурсов возможно есть смысл посмотреть в сторону гибридных схеме:
KVM + LXC, KVM + Docker и т.п. решения. Где за счет KVM получается хорошая изоляция, а за счет контейнеров достигается высокая плотность с минимальным перерасходом ресурсов.

Answer 2

[Дмитрий]

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