Discussion:
systemd-nspawn/machinectl with LUKS/LVM
(too old to reply)
b***@aquazul.com
2017-10-03 15:04:17 UTC
Permalink
Raw Message
Hi,

I'm trying to figure out the right way of using an LUKS-encrypted LV
with systemd-nspawn.

I've got an LV called "containername" which is LUKS-encrypted, and I
start the container using:

systemd-nspawn --boot --image=/dev/vg/containername

it asks me for the LUKS passphrase, and it seems to work OK on the
command line.

However, just a few questions:

1) is there any advantage to using a single-partition GPT instead of no
partition and a filesystem?

2) machinectl list-images doesn't detect the images in LVs; am I
supposed to (auto)mount them in /var/lib/machines/ ?

3) how do I best enable this on boot? "machinectl enable" won't work
since it doesn't know which image to use. Is there an example of a
systemd unit file for an image-based nspawn container?

Thanks,

-- M
Lennart Poettering
2017-10-04 09:31:57 UTC
Permalink
Raw Message
Post by b***@aquazul.com
Hi,
I'm trying to figure out the right way of using an LUKS-encrypted LV
with systemd-nspawn.
I've got an LV called "containername" which is LUKS-encrypted, and I
systemd-nspawn --boot --image=/dev/vg/containername
it asks me for the LUKS passphrase, and it seems to work OK on the
command line.
1) is there any advantage to using a single-partition GPT instead of no
partition and a filesystem?
The image dissection logic can deal with either. The GPT approach is a
bit nicer I think since the root partition can be marked as such, and
carries information about the CPU architecture this image is for (and
nspawn derives the --personality= from that). Hence, things are a lot
more discoverable this way, as images suitable for nspawn are easily
recognized as such. And then of course it offers you things like
having multiple partitions in the same image. For example, a single
image that contains a read-only squashfs /usr, combined with an ext4
writable /home or so. Last but not least, by doing GPT it is easy to
make images that boot under both KVM (or physical systems) and nspawn
in pretty much the same way.

If neither of that is interesting to you, i.e. not discoverability, no
architecture support, no multiple partitions and no KVM compat, then
you can happily do without GPT.

(mkosi makes building images easy that take benefit of GPT features btw)
Post by b***@aquazul.com
2) machinectl list-images doesn't detect the images in LVs; am I
supposed to (auto)mount them in /var/lib/machines/ ?
Yeah, that's how discovery works. You can alos place a symlink there.
Post by b***@aquazul.com
3) how do I best enable this on boot? "machinectl enable" won't work
since it doesn't know which image to use. Is there an example of a
systemd unit file for an image-based nspawn container?
It should work, if you make them available in /var/lib/machines,
either by mounting them there or by symlinking them there.

Lennart
--
Lennart Poettering, Red Hat
Mourad De Clerck
2017-10-04 10:41:01 UTC
Permalink
Raw Message
Post by Lennart Poettering
The image dissection logic can deal with either. The GPT approach is a
bit nicer I think since the root partition can be marked as such, and
<snip>

All right, makes sense.
Post by Lennart Poettering
Post by b***@aquazul.com
2) machinectl list-images doesn't detect the images in LVs; am I
supposed to (auto)mount them in /var/lib/machines/ ?
Yeah, that's how discovery works. You can alos place a symlink there.
So I tried to create a symlink to the LV block device
(/dev/vg/containername – containing a GPT) in /var/lib/machines/. I
tried naming the symlink "containername" or "containername.raw". But
"machinectl list-images -a" doesn't seem to detect this image either
way. This is with systemd 234 on Debian stretch, by the way.
Post by Lennart Poettering
It should work, if you make them available in /var/lib/machines,
either by mounting them there or by symlinking them there.
I'd like to avoid mounting the image if I can. To avoid having to
manually detect the gpt partitions, unlocking LUKS, etc, and to avoid
having to expose the container data to the host unnecessarily. But it
seems I'm doing something wrong with my symlinks.

-- M
Lennart Poettering
2017-10-04 11:09:31 UTC
Permalink
Raw Message
Post by Mourad De Clerck
Post by Lennart Poettering
The image dissection logic can deal with either. The GPT approach is a
bit nicer I think since the root partition can be marked as such, and
<snip>
All right, makes sense.
Post by Lennart Poettering
Post by b***@aquazul.com
2) machinectl list-images doesn't detect the images in LVs; am I
supposed to (auto)mount them in /var/lib/machines/ ?
Yeah, that's how discovery works. You can alos place a symlink there.
So I tried to create a symlink to the LV block device
(/dev/vg/containername – containing a GPT) in /var/lib/machines/. I
tried naming the symlink "containername" or "containername.raw". But
"machinectl list-images -a" doesn't seem to detect this image either
way. This is with systemd 234 on Debian stretch, by the way.
Oh, hmm, the thing is a device node?

Ah, uh, I forgot that your image is a block device. We are missing
some support there for that. /var/lib/machines may only contain
dirs/subvols and raw files right now, we don't support block
devices. But adding support for that should be easy, too. Can you file
an RFE bug on github about this please?

Lennart
--
Lennart Poettering, Red Hat
Mourad De Clerck
2017-10-04 11:55:02 UTC
Permalink
Raw Message
Post by Lennart Poettering
Ah, uh, I forgot that your image is a block device. We are missing
some support there for that. /var/lib/machines may only contain
dirs/subvols and raw files right now, we don't support block
devices. But adding support for that should be easy, too. Can you file
an RFE bug on github about this please?
Gladly, see: https://github.com/systemd/systemd/issues/6990

Thank you,

-- M

Loading...