Systemd.container produces non-standard systemd container

I just tried Systemd.container. The process seemed to work well, and I can log to the container with

$ machinectl --shell root@mycontainer

but machinectl can't clone the image

$ machinectl clone mycontainer testclone
Could not clone image: Operation not supported

I can export and import the image:

$ machinectl export-tar mycontainer /var/tmp/testclone.tar.gz
$ machinectl import-tar /var/tmp/testclone.tar.gz test-container

list-images gives does not give the same information for both images:

$ machinectl list-images
NAME            TYPE      RO  USAGE  CREATED                      MODIFIED
mycontainer     directory no  n/a    n/a                          n/a     
testclone       subvolume no  60M    Thu 2015-09-24 22:41:39 CEST n/a

but I can clone my newly imported image:

$ machinectl clone testclone testclone2
$ machinectl list-images
NAME            TYPE      RO  USAGE  CREATED                      MODIFIED
mycontainer     directory no  n/a    n/a                          n/a     
testclone       subvolume no  60M    Thu 2015-09-24 22:41:39 CEST n/a     
testclone2      subvolume no  60M    Thu 2015-09-24 22:48:39 CEST n/a

I guess "machinectl clone" does a little more than just copying the images...

RSS

comment 1

I forgot to tell that /var is a btrfs partition...

Comment by gueux — Fri Sep 25 14:39:49 2015

Remove comment

comment 2

The FilePath parameter to Chroot.debootstrapped is the directory to put the chroot in.

If you have a property foo that takes such a chroot directory and generates the tarball you need, you can compose it thus:

Chroot.debootstrapped system chrootdir
    `onChange` foo chrootdir tarball

Comment by joey — Sat Sep 26 12:33:57 2015

Remove comment

comment 3

You can see the difference here:

mycontainer directory no n/a n/a n/a testclone subvolume no 60M Thu 2015-09-24 22:41:39 CEST n/a

Your container is a directory while the clone is a subvolume (of btrfs). Cloning the machine involves doing some btrfs magic I would assume (with no cp -a backup). The error message could be more descriptive…

Comment by mathstuf — Tue Oct 20 01:01:54 2015

Remove comment

Thank you

I was bitten also by this weird error message and have submitted it upstream: https://github.com/systemd/systemd/issues/2060

Comment by jerryjacobs1989 — Sun Nov 29 13:04:56 2015

Remove comment

comment 5

The error message is one thing, but shouldn't the container built with Systemd.container be clonable? Maybe by adding an additional "export-tar/import-tar" step to Systemd.container or by using something different from mkchroot?

Comment by gueux — Mon Mar 28 19:39:22 2016

Remove comment

comment 6

   clone NAME NAME
       Clones a container or VM image. The arguments specify the
       name of the image to clone and the name of the newly
       cloned image. Note that plain directory container images
       are cloned into subvolume images with this command.

That seems to say that the directory that Systemd.container sets up should be clonable too. Perhaps this is a systemd bug?

If systemd needs a container to be loaded from a tarball in order to be clonable this way, I guess I would not mind if Systemd.container did that as part of its initial bootstrapping. But it is extra work so I'd like to make sure that it's really intended to need to do that.

(Myself, I don't care if I can't clone a container; I can delete any of them and propellor can rebuild them, or even move the line to a different host in config.hs to relocate the container.)

Comment by joey — Tue Mar 29 21:09:25 2016

Remove comment

comment 7

After a chat session on #systemd, I've posted a new issue https://github.com/systemd/systemd/issues/2914 There should be updates soon.