Dne 16.3.2016 v 14:37 Steven Dake (stdake) napsal(a):
On 3/16/16, 1:06 AM, "linux-lvm-bounces@redhat.com on behalf of Zdenek
Kabelac" <linux-lvm-bounces@redhat.com on behalf of
zdenek.kabelac@gmail.com> wrote:
Dne 16.3.2016 v 00:52 Steven Dake (stdake) napsal(a):
On 3/15/16, 3:56 PM, "linux-lvm-bounces@redhat.com on behalf of Zdenek
Kabelac" <linux-lvm-bounces@redhat.com on behalf of
zdenek.kabelac@gmail.com> wrote:
Dne 15.3.2016 v 23:31 Serguei Bezverkhi (sbezverk) napsal(a):
Hello folks,
While trying to make lvm work within a docker container I came across
an issue when all lvcreate/lvremove got stuck indefinetly or until
control-c. When I checked process I noticed lvm was waiting on one
semaphore, I found that other folks hit similar issue and they fixed
it
by setting udev_sync and udev_rules to 0. It also helped my case too.
I would greatly appreciate if you could share your thought if this
change in future can potentially have any negative impact.
Thank you
Hi
To 'unblock' stuck processes waiting on udev cookie - you could run:
'dmsetup udevcomplete_all'
However the key question is - how you could get stuck.
That may need further debugging.
You would need to expose your OS version and also version of lvm2 in
use.
Non working cookies are bad - and disabling udev sync is even more bad
idea...
Zdeknek,
To expand on what Serguei is doing, he is working on a patch to add
LVM2+Iscsi in a container for the Cinder (block storage AAS) project in
Hi
Well - this should be the 1st. sentence in the initial email reporting
the
problem.
lvm2 DOES NOT (and CANNOT) work properly inside container.
Devices are not 'containerized' resource.
This is common bug in 'Docker-land' understanding of Linux kernel.
That's where the hacks like not using 'udev' sync comes from.
Zdenek,
Just for the sake of the archive, we did manage to get LVM to work inside
a container without modifying the udev sync rules by using --ipc=host to
docker start. Thanks for the pointers. I hope that other people that run
across this problem can find this thread and use the --ipc=host solution,
since containerized applications are the future and would be bleak without
lvm2 ;)
Hi
I think you still miss the problem. So let me illustrate:
Let's assume you have a 'VG' in your host machine.
Then you let run commands operating on this VG inside your guest-like
Dockerized container application - this one surely has no access to system
lvm2 lockdir. So it will access metadata of your VG without using proper
locking - it may even think it is taking lock - since inside your 'chrooted'
container the locking will work - but it's different lock then your system
lvm2 lock - so just useless...
The situation ain't any better if you make special LV for your docker guest
and then you let guest to create there a PV to use - since your host
unless precisely configured will see and will interact with does metadata as well.
The 'lvm2' solution so far is 'clvmd' but it's well beyond docker as it's
using dlm locking and needs fair bit of cluster infrastructure.
I'm also not sure if even 'sanlock' would make a docker land easier to accept
the fact that you can't let to have 2 independent apps changing/playing with
metadata without using locking between each other.
From what you repeat to say here I assume there is no interest to make it -
right - just make it work with any hack you can find.
So you've been just warned that there is fair bit of complexity running inside
lvm2 that relies on certain system behavior - and it's not designed to be
running in container at all and used in a way you try to demonstrate/promote
as usable.
Regards
Zdenek
_______________________________________________
linux-lvm mailing list
linux-lvm@redhat.com
https://www.redhat.com/mailman/listinfo/linux-lvm
read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
