snapshot-origin freezes system - what am I doing wrong?

snapshot-origin freezes system - what am I doing wrong?

[Atom2]

Hello list,
I am trying to setup a cow snapshot for a LV that is used as a master 
image for a number of VMs. The idea basically is to be able to update 
the master image even when VMs are up and running; the VMs should then 
still see the old state of the image and only when they are restarted 
they should connect to the new image.
Searching the net seemed to point towards a snapshot-origin/snapshot 
solution - however I am unable to get this to work. Information on the 
net seems to be sparse, so I though I'd ask the experts on the list. 
Here are my steps:

1.) I have a LV in volume group VG named master.ROOT 
(/dev/mapper/VG-master.ROOT), 8GB, formatted as ext4
2.) I create a sparese file: truncate -size=8G /tmp/snapshot
3.) losetup -f /tmp/snapshot --> gives /dev/loop0
4.) dmsetup create mytest.img --table "0 $(blockdev --getsz 
/dev/mapper/VG-master.ROOT) snapshot-origin /dev/mapper/VG-master.ROOT
5.) dmsetup create mytest.img.cow --table "0 $(blockdev --getsz 
/dev/loop0) snapshot /dev/mapper/VG-master.ROOT /dev/loop0 P 8"

So far so good ... however, when I try to mount the origin device by
6.) mount /dev/mapper/mytest.img
the mount call doesn't return and the system gets unresponsive/freezes 
up to a point when OOM-killer is being invoked. Login attempts on the 
console time out and in essence it is only possible to reboot the system 
using magic-sysreq key combinations.

I'd be very much obliged if someone in the know could provide me with 
information what's wrong with this approach.

Many thanks in advance Atom2


P.S. Trying to replicate the setup with a second loop device instead of 
the LV for the master image seems to not suffer from this problem - 
mounting is possible without a hickup. The issue therefore seems to be 
connecte with the LV as the snapshot-origin device, but I have no clue 
how to sort that.

Re: snapshot-origin freezes system - what am I doing wrong?

[Zdenek Kabelac]

Dne 15.5.2015 v 12:45 Atom2 napsal(a):
> Hello list,
> I am trying to setup a cow snapshot for a LV that is used as a master image
> for a number of VMs. The idea basically is to be able to update the master
> image even when VMs are up and running; the VMs should then still see the old
> state of the image and only when they are restarted they should connect to the
> new image.
> Searching the net seemed to point towards a snapshot-origin/snapshot solution
> - however I am unable to get this to work. Information on the net seems to be
> sparse, so I though I'd ask the experts on the list. Here are my steps:
>
> 1.) I have a LV in volume group VG named master.ROOT
> (/dev/mapper/VG-master.ROOT), 8GB, formatted as ext4
> 2.) I create a sparese file: truncate -size=8G /tmp/snapshot
> 3.) losetup -f /tmp/snapshot --> gives /dev/loop0
> 4.) dmsetup create mytest.img --table "0 $(blockdev --getsz
> /dev/mapper/VG-master.ROOT) snapshot-origin /dev/mapper/VG-master.ROOT
> 5.) dmsetup create mytest.img.cow --table "0 $(blockdev --getsz /dev/loop0)
> snapshot /dev/mapper/VG-master.ROOT /dev/loop0 P 8"
>
> So far so good ... however, when I try to mount the origin device by
> 6.) mount /dev/mapper/mytest.img
> the mount call doesn't return and the system gets unresponsive/freezes up to a
> point when OOM-killer is being invoked. Login attempts on the console time out
> and in essence it is only possible to reboot the system using magic-sysreq key
> combinations.
>
> I'd be very much obliged if someone in the know could provide me with
> information what's wrong with this approach.
>
> Many thanks in advance Atom2

Do you have any  scientific reason to not  use LVM2  here ?

Management of snapshot target is not trivial - especially the order
of individual table loads and resumes.

You could look at  'lvcreate -s -vvvv' if you are interested in ioctl ordering 
of all operations here.

Regards

Zdenek

Re: snapshot-origin freezes system - what am I doing wrong?

[Atom2]

Am 15.05.15 um 14:11 schrieb Zdenek Kabelac:
> Dne 15.5.2015 v 12:45 Atom2 napsal(a):
>> Hello list,
>> I am trying to setup a cow snapshot for a LV that is used as a master 
>> image
>> for a number of VMs. The idea basically is to be able to update the 
>> master
>> image even when VMs are up and running; the VMs should then still see 
>> the old
>> state of the image and only when they are restarted they should 
>> connect to the
>> new image.
>> Searching the net seemed to point towards a snapshot-origin/snapshot 
>> solution
>> - however I am unable to get this to work. Information on the net 
>> seems to be
>> sparse, so I though I'd ask the experts on the list. Here are my steps:
>>
>> 1.) I have a LV in volume group VG named master.ROOT
>> (/dev/mapper/VG-master.ROOT), 8GB, formatted as ext4
>> 2.) I create a sparese file: truncate -size=8G /tmp/snapshot
>> 3.) losetup -f /tmp/snapshot --> gives /dev/loop0
>> 4.) dmsetup create mytest.img --table "0 $(blockdev --getsz
>> /dev/mapper/VG-master.ROOT) snapshot-origin /dev/mapper/VG-master.ROOT
>> 5.) dmsetup create mytest.img.cow --table "0 $(blockdev --getsz 
>> /dev/loop0)
>> snapshot /dev/mapper/VG-master.ROOT /dev/loop0 P 8"
>>
>> So far so good ... however, when I try to mount the origin device by
>> 6.) mount /dev/mapper/mytest.img
>> the mount call doesn't return and the system gets 
>> unresponsive/freezes up to a
>> point when OOM-killer is being invoked. Login attempts on the console 
>> time out
>> and in essence it is only possible to reboot the system using 
>> magic-sysreq key
>> combinations.
>>
>> I'd be very much obliged if someone in the know could provide me with
>> information what's wrong with this approach.
>>
>> Many thanks in advance Atom2
>
> Do you have any  scientific reason to not  use LVM2  here ?
As far as I understand the snapshot-origin target with a cow snapshot is 
not (yet) directly supported by LVM2.

Therefore I have so far worked from an assumption that I need to use 
dmsetup directly to solve my use case. If, however, you tell me 
otherwise and are able to show me how to use LVM2 instead, I am more 
than happy to go down that route. Let me once again outline my use case:

I have a LV (that's the master image/template which was actually setup 
with LVM2) which is maintained from within a template VM and serves as 
the (r/o) root image for a number of other (dependent) virtual machines. 
All dependent virtual machines mount that template LV r/o and overlay it 
with an overlayfs as a r/w layer for write access.
I now want to be able to update the master image from within the 
template VM and be able to update it at any time; running dependent VMs 
should however not see any changes to the image while they are up, hence 
the requirement to have a snapshot-origin target and a snapshot that 
would cow buffer any changes in the template (origin) target until such 
time the dependent VM is restarted. At that point in time the dependent 
VM would (if required setup and) connect to a new snapshot.

I hope that clarifies my setup.

Furthermore, IMHO and in any case mounting a dm-target should under no 
circumstances in essence bring down a machine - even if something is 
horribly wrong.

> Management of snapshot target is not trivial - especially the order
> of individual table loads and resumes.
>
> You could look at  'lvcreate -s -vvvv' if you are interested in ioctl 
> ordering of all operations here.
>
I am probably missing something here, but my steps listed above do not 
involve lvcreate ... so how could I use that -vvv?

Thanks, Atom2

Re: snapshot-origin freezes system - what am I doing wrong?

[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):
>>> Hello list,
>>> I am trying to setup a cow snapshot for a LV that is used as a master image
>>> for a number of VMs. The idea basically is to be able to update the master
>>> image even when VMs are up and running; the VMs should then still see the old
>>> state of the image and only when they are restarted they should connect to the
>>> new image.
>>> Searching the net seemed to point towards a snapshot-origin/snapshot solution
>>> - however I am unable to get this to work. Information on the net seems to be
>>> sparse, so I though I'd ask the experts on the list. Here are my steps:
>>>
>>> 1.) I have a LV in volume group VG named master.ROOT
>>> (/dev/mapper/VG-master.ROOT), 8GB, formatted as ext4
>>> 2.) I create a sparese file: truncate -size=8G /tmp/snapshot
>>> 3.) losetup -f /tmp/snapshot --> gives /dev/loop0
>>> 4.) dmsetup create mytest.img --table "0 $(blockdev --getsz
>>> /dev/mapper/VG-master.ROOT) snapshot-origin /dev/mapper/VG-master.ROOT
>>> 5.) dmsetup create mytest.img.cow --table "0 $(blockdev --getsz /dev/loop0)
>>> snapshot /dev/mapper/VG-master.ROOT /dev/loop0 P 8"
>>>
>>> So far so good ... however, when I try to mount the origin device by
>>> 6.) mount /dev/mapper/mytest.img
>>> the mount call doesn't return and the system gets unresponsive/freezes up to a
>>> point when OOM-killer is being invoked. Login attempts on the console time out
>>> and in essence it is only possible to reboot the system using magic-sysreq key
>>> combinations.
>>>
>>> I'd be very much obliged if someone in the know could provide me with
>>> information what's wrong with this approach.
>>>
>>> Many thanks in advance Atom2
>>
>> Do you have any  scientific reason to not  use LVM2  here ?
> As far as I understand the snapshot-origin target with a cow snapshot is not
> (yet) directly supported by LVM2.

Just curious - from where have you got this idea ??

>
> Therefore I have so far worked from an assumption that I need to use dmsetup
> directly to solve my use case. If, however, you tell me otherwise and are able
> to show me how to use LVM2 instead, I am more than happy to go down that
> route. Let me once again outline my use case:
>
> I have a LV (that's the master image/template which was actually setup with
> LVM2) which is maintained from within a template VM and serves as the (r/o)
> root image for a number of other (dependent) virtual machines. All dependent
> virtual machines mount that template LV r/o and overlay it with an overlayfs
> as a r/w layer for write access.
> I now want to be able to update the master image from within the template VM
> and be able to update it at any time; running dependent VMs should however not
> see any changes to the image while they are up, hence the requirement to have
> a snapshot-origin target and a snapshot that would cow buffer any changes in
> the template (origin) target until such time the dependent VM is restarted. At
> that point in time the dependent VM would (if required setup and) connect to a
> new snapshot.
>
> I hope that clarifies my setup.
>
> Furthermore, IMHO and in any case mounting a dm-target should under no
> circumstances in essence bring down a machine - even if something is horribly
> wrong.
>
>> Management of snapshot target is not trivial - especially the order
>> of individual table loads and resumes.
>>
>> You could look at  'lvcreate -s -vvvv' if you are interested in ioctl
>> ordering of all operations here.
>>
> I am probably missing something here, but my steps listed above do not involve
> lvcreate ... so how could I use that -vvv?
>

Well even kernel documentation for the snapshot target itself is rather 
referencing usage of snapshot via lvm2 - and it's for a reason.

https://www.kernel.org/doc/Documentation/device-mapper/snapshot.txt

So if you could use  lvm2 - stay with lvm2 and avoid your home-brew dmsetup 
commands - it needs deep understanding how the old snapshot target works:

http://people.redhat.com/agk/talks/LVM2-LinuxTag2006/


Regards

Zdenek

Re: snapshot-origin freezes system - what am I doing wrong?

[Atom2]

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):
>>>> Hello list,
>>>> I am trying to setup a cow snapshot for a LV that is used as a 
>>>> master image
>>>> for a number of VMs. The idea basically is to be able to update the 
>>>> master
>>>> image even when VMs are up and running; the VMs should then still 
>>>> see the old
>>>> state of the image and only when they are restarted they should 
>>>> connect to the
>>>> new image.
>>>> Searching the net seemed to point towards a 
>>>> snapshot-origin/snapshot solution
>>>> - however I am unable to get this to work. Information on the net 
>>>> seems to be
>>>> sparse, so I though I'd ask the experts on the list. Here are my 
>>>> steps:
>>>>
>>>> 1.) I have a LV in volume group VG named master.ROOT
>>>> (/dev/mapper/VG-master.ROOT), 8GB, formatted as ext4
>>>> 2.) I create a sparese file: truncate -size=8G /tmp/snapshot
>>>> 3.) losetup -f /tmp/snapshot --> gives /dev/loop0
>>>> 4.) dmsetup create mytest.img --table "0 $(blockdev --getsz
>>>> /dev/mapper/VG-master.ROOT) snapshot-origin /dev/mapper/VG-master.ROOT
>>>> 5.) dmsetup create mytest.img.cow --table "0 $(blockdev --getsz 
>>>> /dev/loop0)
>>>> snapshot /dev/mapper/VG-master.ROOT /dev/loop0 P 8"
>>>>
>>>> So far so good ... however, when I try to mount the origin device by
>>>> 6.) mount /dev/mapper/mytest.img
>>>> the mount call doesn't return and the system gets 
>>>> unresponsive/freezes up to a
>>>> point when OOM-killer is being invoked. Login attempts on the 
>>>> console time out
>>>> and in essence it is only possible to reboot the system using 
>>>> magic-sysreq key
>>>> combinations.
>>>>
>>>> I'd be very much obliged if someone in the know could provide me with
>>>> information what's wrong with this approach.
>>>>
>>>> Many thanks in advance Atom2
>>>
>>> Do you have any  scientific reason to not  use LVM2  here ?
>> As far as I understand the snapshot-origin target with a cow snapshot 
>> is not
>> (yet) directly supported by LVM2.
>
> Just curious - from where have you got this idea ??
Well I simply haven't found anything within LVM2 that supports my use 
case. Everything I have found is about buffering writes to the original 
device such that the original device appears unchanged.
I am, however, curious as well: What makes you think that my use case is 
covered by pure LVM2? Do you have a link with the steps required - that 
would be great!
>
>>
>> Therefore I have so far worked from an assumption that I need to use 
>> dmsetup
>> directly to solve my use case. If, however, you tell me otherwise and 
>> are able
>> to show me how to use LVM2 instead, I am more than happy to go down that
>> route. Let me once again outline my use case:
>>
>> I have a LV (that's the master image/template which was actually 
>> setup with
>> LVM2) which is maintained from within a template VM and serves as the 
>> (r/o)
>> root image for a number of other (dependent) virtual machines. All 
>> dependent
>> virtual machines mount that template LV r/o and overlay it with an 
>> overlayfs
>> as a r/w layer for write access.
>> I now want to be able to update the master image from within the 
>> template VM
>> and be able to update it at any time; running dependent VMs should 
>> however not
>> see any changes to the image while they are up, hence the requirement 
>> to have
>> a snapshot-origin target and a snapshot that would cow buffer any 
>> changes in
>> the template (origin) target until such time the dependent VM is 
>> restarted. At
>> that point in time the dependent VM would (if required setup and) 
>> connect to a
>> new snapshot.
>>
>> I hope that clarifies my setup.
>>
>> Furthermore, IMHO and in any case mounting a dm-target should under no
>> circumstances in essence bring down a machine - even if something is 
>> horribly
>> wrong.
>>
>>> Management of snapshot target is not trivial - especially the order
>>> of individual table loads and resumes.
>>>
>>> You could look at  'lvcreate -s -vvvv' if you are interested in ioctl
>>> ordering of all operations here.
>>>
>> I am probably missing something here, but my steps listed above do 
>> not involve
>> lvcreate ... so how could I use that -vvv?
>>
>
> Well even kernel documentation for the snapshot target itself is 
> rather referencing usage of snapshot via lvm2 - and it's for a reason.
I have seen that, but I got the impression, that's the other way round 
to what I require: It creates a snapshot that copies writes to the 
original device in order for the original volume to be in a consitent 
state e.g. for bacups; those writes will then later be merged back to 
the original volume. That's, however, unfortunately not what I require. 
What I require is that upon a write to the original device the _old_ 
block is copied to the snapshot cow device so that any process accessing 
the snapshot has a consistent (and unchanged) view of the original 
device. The original device itself will change!
>
> https://www.kernel.org/doc/Documentation/device-mapper/snapshot.txt
>
> So if you could use  lvm2 - stay with lvm2 and avoid your home-brew 
> dmsetup commands - it needs deep understanding how the old snapshot 
> target works:
>
> http://people.redhat.com/agk/talks/LVM2-LinuxTag2006/
It looks as if I am not smart enough and (at least) in the area of 
device-manager (which is expected) you are much smarter than me. So let 
me pick your brain: Would you be so kind to outline the steps required 
for me to be able to setup my use case with LVM2: Again, I need a 
snapshot device that only stores changed blocks from the snapshot-origin 
device (which is used somewhere else) and routes unchanged read requests 
back to the origin device. I am still not sure whether we are on the 
same page here.

I am also very curious to understand why the exact same steps outlined 
further above _do_ work when both the snapshot-origin device and the 
snapshot device are based on losetup (spares-)file based block devices 
and fail when the snapshot-origin device is a block device created by 
LVM2 and only the snapshot device is a losetup (sparse-)file based block 
device.

Many thanks again for your patience, but I'd very much appreciate if you 
could be more explicit in your (at least for me) rather vague answers. I 
am also happy to join a session on IRC - but that channel seems to be 
pretty orphand at all times.

Thanks Atom2

Re: snapshot-origin freezes system - what am I doing wrong?

[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):
>>>>> Hello list,
>>>>> I am trying to setup a cow snapshot for a LV that is used as a master image
>>>>> for a number of VMs. The idea basically is to be able to update the master
>>>>> image even when VMs are up and running; the VMs should then still see the
>>>>> old
>>>>> state of the image and only when they are restarted they should connect
>>>>> to the
>>>>> new image.
>>>>> Searching the net seemed to point towards a snapshot-origin/snapshot
>>>>> solution
>>>>> - however I am unable to get this to work. Information on the net seems
>>>>> to be
>>>>> sparse, so I though I'd ask the experts on the list. Here are my steps:
>>>>>
>>>>> 1.) I have a LV in volume group VG named master.ROOT
>>>>> (/dev/mapper/VG-master.ROOT), 8GB, formatted as ext4
>>>>> 2.) I create a sparese file: truncate -size=8G /tmp/snapshot
>>>>> 3.) losetup -f /tmp/snapshot --> gives /dev/loop0
>>>>> 4.) dmsetup create mytest.img --table "0 $(blockdev --getsz
>>>>> /dev/mapper/VG-master.ROOT) snapshot-origin /dev/mapper/VG-master.ROOT
>>>>> 5.) dmsetup create mytest.img.cow --table "0 $(blockdev --getsz /dev/loop0)
>>>>> snapshot /dev/mapper/VG-master.ROOT /dev/loop0 P 8"
>>>>>
>>>>> So far so good ... however, when I try to mount the origin device by
>>>>> 6.) mount /dev/mapper/mytest.img
>>>>> the mount call doesn't return and the system gets unresponsive/freezes up
>>>>> to a
>>>>> point when OOM-killer is being invoked. Login attempts on the console
>>>>> time out
>>>>> and in essence it is only possible to reboot the system using
>>>>> magic-sysreq key
>>>>> combinations.
>>>>>
>>>>> I'd be very much obliged if someone in the know could provide me with
>>>>> information what's wrong with this approach.
>>>>>
>>>>> Many thanks in advance Atom2
>>>>
>>>> Do you have any  scientific reason to not  use LVM2  here ?
>>> As far as I understand the snapshot-origin target with a cow snapshot is not
>>> (yet) directly supported by LVM2.
>>
>> Just curious - from where have you got this idea ??
> Well I simply haven't found anything within LVM2 that supports my use case.
> Everything I have found is about buffering writes to the original device such
> that the original device appears unchanged.
> I am, however, curious as well: What makes you think that my use case is
> covered by pure LVM2? Do you have a link with the steps required - that would
> be great!
>>
>>>
>>> Therefore I have so far worked from an assumption that I need to use dmsetup
>>> directly to solve my use case. If, however, you tell me otherwise and are able
>>> to show me how to use LVM2 instead, I am more than happy to go down that
>>> route. Let me once again outline my use case:
>>>
>>> I have a LV (that's the master image/template which was actually setup with
>>> LVM2) which is maintained from within a template VM and serves as the (r/o)
>>> root image for a number of other (dependent) virtual machines. All dependent
>>> virtual machines mount that template LV r/o and overlay it with an overlayfs
>>> as a r/w layer for write access.
>>> I now want to be able to update the master image from within the template VM
>>> and be able to update it at any time; running dependent VMs should however not
>>> see any changes to the image while they are up, hence the requirement to have
>>> a snapshot-origin target and a snapshot that would cow buffer any changes in
>>> the template (origin) target until such time the dependent VM is restarted. At
>>> that point in time the dependent VM would (if required setup and) connect to a
>>> new snapshot.
>>>
>>> I hope that clarifies my setup.
>>>
>>> Furthermore, IMHO and in any case mounting a dm-target should under no
>>> circumstances in essence bring down a machine - even if something is horribly
>>> wrong.
>>>
>>>> Management of snapshot target is not trivial - especially the order
>>>> of individual table loads and resumes.
>>>>
>>>> You could look at  'lvcreate -s -vvvv' if you are interested in ioctl
>>>> ordering of all operations here.
>>>>
>>> I am probably missing something here, but my steps listed above do not involve
>>> lvcreate ... so how could I use that -vvv?
>>>
>>
>> Well even kernel documentation for the snapshot target itself is rather
>> referencing usage of snapshot via lvm2 - and it's for a reason.
> I have seen that, but I got the impression, that's the other way round to what
> I require: It creates a snapshot that copies writes to the original device in
> order for the original volume to be in a consitent state e.g. for bacups;
> those writes will then later be merged back to the original volume. That's,
> however, unfortunately not what I require. What I require is that upon a write
> to the original device the _old_ block is copied to the snapshot cow device so
> that any process accessing the snapshot has a consistent (and unchanged) view
> of the original device. The original device itself will change!
>>
>> https://www.kernel.org/doc/Documentation/device-mapper/snapshot.txt
>>
>> So if you could use  lvm2 - stay with lvm2 and avoid your home-brew dmsetup
>> commands - it needs deep understanding how the old snapshot target works:
>>
>> http://people.redhat.com/agk/talks/LVM2-LinuxTag2006/
> It looks as if I am not smart enough and (at least) in the area of
> device-manager (which is expected) you are much smarter than me. So let me
> pick your brain: Would you be so kind to outline the steps required for me to
> be able to setup my use case with LVM2: Again, I need a snapshot device that
> only stores changed blocks from the snapshot-origin device (which is used
> somewhere else) and routes unchanged read requests back to the origin device.
> I am still not sure whether we are on the same page here.
>
> I am also very curious to understand why the exact same steps outlined further
> above _do_ work when both the snapshot-origin device and the snapshot device
> are based on losetup (spares-)file based block devices and fail when the
> snapshot-origin device is a block device created by LVM2 and only the snapshot
> device is a losetup (sparse-)file based block device.
>
> Many thanks again for your patience, but I'd very much appreciate if you could
> be more explicit in your (at least for me) rather vague answers. I am also
> happy to join a session on IRC - but that channel seems to be pretty orphand
> at all times.

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.

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....

Regards

Zdenek

Re: snapshot-origin freezes system - what am I doing wrong?

[Atom2]

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.