Проблема в том, что работаете с блочными устройствами, и делаете снепшот блочного устройства, поверх, которого применяется файловая система. Т.е. пока мастер образ не меняется, производные снепшоты содержат консистентную файловую систему. А вот после изменения мастер образа - файловая система на снепшотах "развалится".
Такое теоретически возможно для контейнеров (OpenVZ, LXC, Docker), которые работают поверх файловой системы. Но изменения мастера образа приведут хоть и к корректным изменениям файловой системы, но разломают целостность на прикладном уровне. Например, знания пакетного менеджера об установленных пакетах будут неверными.
Если схема мастер-образ - дочерний снепшот позволяет вам сократить расход дискового пространства и ускорить развертывание новых копий. То для дальнейших синхронных изменений производных гостевых систем используйте системы управления конфигурациями (SCM), такие как Ansible, Salt и т.п.
Еще ничто не мешает Вам создавать новые мастер-образы с учетом новых требований и разворачивать новые дочерние инстансы на новом мастер-образе. Таким образом у вас в обороте будет одновременно несколько кустов версий мастер-образов и производных систем. Возможно для личного применения это и избыточно. Но для крупных масштабов такой подход может быть оправдан, давая вполне ощутимую экономию ресурсов. Но это будет сложная схема, которую надо грамотно поддерживать.
Для экономии ресурсов возможно есть смысл посмотреть в сторону гибридных схеме:
KVM + LXC, KVM + Docker и т.п. решения. Где за счет KVM получается хорошая изоляция, а за счет контейнеров достигается высокая плотность с минимальным перерасходом ресурсов.