Rich Freeman on 12 Oct 2015 14:23:32 -0700


[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]

Re: [PLUG] Video link: "Virtualizing Bare-Metal Systems with QEMU" and meeting bookmarks


On Mon, Oct 12, 2015 at 5:02 PM, JP Vossen <jp@jpsdomain.org> wrote:
> Jumping *way* back to the bind mount stuff, I use them mostly for
> getting grub to install right, but I was just reading
> http://www.linux.it/~ema/2015/10/07/systemd-is-your-friend/ today and it
> has some good systemd stuff on `journalctl` and and `systemd-nspawn` for
> containers that do all the bind mounts for you.
>
> We probably need some more presos on systemd; I know I do...

I don't own a monopoly on the topic, but I'm happy to take requests if
you have something in mind.  There are a lot of things you could cover
from the practicalities of using systemd to writing units and so on.

n the topic of systemd-nspawn I might humbly suggest this guide as well:
https://rich0gentoo.wordpress.com/2014/07/14/quick-systemd-nspawn-guide/

One other trick with systemd is to watch out for shared bind mounts.
If you create your own bind mounts systemd might make them a shared
mount (I'd have to dig through the docs that define how to control
this behavior and different distros may have different defaults).
That means that if you bind mount /dev into another directory, then
umount that bind mount, the kernel may also umount your original /dev.
That happens if you mount from the command line and don't explicitly
configure the bind mount to be private, which is normally the default.
Bit of a gotcha there.

One of the nice thing about nspawn and mount namespaces in general is
that you can mount all the garbage you want inside and it all gets
cleaned up when the last process exits, and nothing outside the
container sees it.  So, I can create tmpfs mounts in a container and
they all go away when the container exits.  Likewise, I can have a
container that has its /proc and /dev mounted and maybe 47 bind
mounts, and then run tar from outside the container and tar won't try
to store the entire contents of vram or 47 copies of whatever the bind
mounts were pointing at.  Tar outside the container doesn't see all
the mounts inside - it just sees the directory tree the container
started with.

--
Rich
___________________________________________________________________________
Philadelphia Linux Users Group         --        http://www.phillylinux.org
Announcements - http://lists.phillylinux.org/mailman/listinfo/plug-announce
General Discussion  --   http://lists.phillylinux.org/mailman/listinfo/plug