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

[Atom2 <ariel.atom2@web2web.at>]

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