Am 15.05.15 um 20:56 schrieb Zdenek Kabelac:
Dne 15.5.2015 v 20:48 Atom2 napsal(a):
Am 15.05.15 um 19:58 schrieb Zdenek Kabelac:
Dne 15.5.2015 v 18:47 Atom2 napsal(a):
Am 15.05.15 um 14:11 schrieb Zdenek Kabelac:
Dne 15.5.2015 v 12:45 Atom2 napsal(a):
[snip]
I'm not saying lvm2 solves your original problem - which I still
don't seem to understand - I'm just saying you need to look at how
lvm2 is ordering ioctls with loads & resumes of targets when making
snapshot.
Thanks for bearing with me - and appologies that I have not been able to
phrase my problem so that it was easy to understand. I'll try again in
the hope that I am clearer this time:
Consider that I do have a vm-host which hosts a number of virtual
machines (VMs). Many of those VMs are similar and thus share a common
template root-file system based on ext4 (let's call that master.ROOT).
master.ROOT is an LVM2 logical volume sized at 8GB. There's only one VM
that (from time to time) has r/w access to that LV and this VM is
responsible for doing updates to the template (i.e. its then r/w root
file system).
master.ROOT is mounted r/o in all other VMs. Probably not relevant here,
but those other VMs have a presistent r/w layer on top of master.ROOT (a
dedicated overlayfs for each and every VM) to allow r/w access to their
root file-system. All that is working already with no hicups.
Now consider that I need to update master.ROOT. Currently that would
require stopping all VMs using that template, then start the template
VM, make the required changes, stop the template VM and then restart
every VM based on the updated master.ROOT image.
This is where my idea comes in: What if every VM didn't use master.ROOT
directly but rather used a snapshot of the master.ROOT image that keeps
consistent even when the underlying master.ROOT is changed. This,
according to my understanding, could be solved by the snapshot-origin
target combined with a snapshot: From the documentation that you linked
to (and that I based my idea upon):
*) snapshot-origin <origin>
which will normally have one or more snapshots based on it.
Reads will be mapped directly to the backing device. For each write, the
original data will be saved in the <COW device> of each snapshot to keep
its visible content unchanged, at least until the <COW device> fills up.
This approach would ensure that the snapshot that every VM sees stays
the same and restarts of the VM could be done at any point in time. The
master.ROOT image could also be updated at any point in time. Running
VMs would clearly still be based on the old version of master.ROOT until
such time they are restarted: When a VM is restarted, it would simply be
connected to the latest version of the snapshot. Old version of
snapshots - provided they are no longer in use by any VM - could be
cleaned up/purged when a VM is stopped.
I hope that clarifies my approach.
IMHO old snapshot is quite complicated and maybe you should take a
look at this provisioning support - especially if you think in terms
of having lots of snapshot of single master volume - usage of
old-snapshot target is pretty much dead road....
What the heck is an old-snapshot target?
Thansk again, Atom2
P.S. I am available in IRC (freenode) atm if you want to join to
exchange some ideas.
--
dm-devel mailing list
dm-devel@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/dm-devel
