Creating initvm in docker doesn't work

[danielmeer]

Hi,

I can build, start and connect to the docker container by using the provided dockerfile in the contrib/ directory.

But when running elbe initvm create, it doesn't do anything except displaying an error message every few seconds:

elbe@987bc96de8be:/elbe$ elbe initvm create
libvirt: XML-RPC error : Failed to connect socket to '/var/run/libvirt/libvirt-sock': No such file or directory
libvirt: XML-RPC error : Failed to connect socket to '/var/run/libvirt/libvirt-sock': No such file or directory
libvirt: XML-RPC error : Failed to connect socket to '/var/run/libvirt/libvirt-sock': No such file or directory

If I abort the command, I get this:

elbe@987bc96de8be:/elbe$ elbe initvm create
libvirt: XML-RPC error : Failed to connect socket to '/var/run/libvirt/libvirt-sock': No such file or directory
libvirt: XML-RPC error : Failed to connect socket to '/var/run/libvirt/libvirt-sock': No such file or directory
libvirt: XML-RPC error : Failed to connect socket to '/var/run/libvirt/libvirt-sock': No such file or directory
^CTraceback (most recent call last):
  File "/usr/lib/python3/dist-packages/elbepack/initvmaction.py", line 87, in __init__
    self.conn = libvirt.open("qemu:///system")
  File "/usr/lib/python3/dist-packages/libvirt.py", line 255, in open
    if ret is None:raise libvirtError('virConnectOpen() failed')
libvirt.libvirtError: Failed to connect socket to '/var/run/libvirt/libvirt-sock': No such file or directory

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/bin/elbe", line 60, in <module>
    cmdmod.run_command(sys.argv[2:])
  File "/usr/lib/python3/dist-packages/elbepack/commands/initvm.py", line 89, in run_command
    action = InitVMAction(args[0])
  File "/usr/lib/python3/dist-packages/elbepack/initvmaction.py", line 498, in __init__
    InitVMAction.__init__(self, node, initvmNeeded=False)
  File "/usr/lib/python3/dist-packages/elbepack/initvmaction.py", line 95, in __init__
    time.sleep(10)
KeyboardInterrupt

The behavior is the same on ELBE v14.6 and v14.2. My host system is an Ubuntu 22.04.

Any help or pointers would be appreciated.

[danielmeer]

The docker container is installing ELBE 14.3 from the Linutronix repository. When I run the v14.6 git checkout I get a different error:

elbe@987bc96de8be:/elbe$ ./elbe initvm create
Traceback (most recent call last):
  File "./elbe", line 57, in <module>
    mod = __import__(modname)
  File "/elbe/elbepack/commands/initvm.py", line 11, in <module>
    from elbepack.initvmaction import InitVMAction, InitVMError
  File "/elbe/elbepack/initvmaction.py", line 28, in <module>
    from elbepack.repodir import RepodirError, Repodir
  File "/elbe/elbepack/repodir.py", line 40
    bin_el.text = f"http://LOCALMACHINE:{httpd.server_address[1]} {repo[1]}"
                                                                           ^
SyntaxError: invalid syntax

[bgermann]

You need at least Python 3.6 to run Elbe. You should install Elbe via the Debian packages.

[danielmeer]

OK, then please ignore my second post.

The Elbe installation done by Docker is using the Debian packages (my first post). So this still stands. The container is based on Debian Stretch, which only has Python 3.5.

[bgermann]

Using Docker, you are on your own. You need the libvirt damon running. Look at the elbe documentation which libvirt groups the running user has to be in.

[d4nuu8]

Take a look at #317

It's using Podman but the basics are the same.

[danielmeer]

The approach with Podman seems to work much nicer! There is one missing package that I had to install for ELBE 14.6:

apt-get install python3-passlib

Unfortunately, it still fails at the end of the initvm creation:

[            (1*installer)  2 shell  3 shell  4- log           ][ Oct 13 13:21 ]
                          ... 100%
Installing GRUB boot loader  ... 16%... 33%... 50%... 66%... 83%... 100%
Sent SIGKILL to all processes.. 12%... 20%... 33%... 41%... 50%... 62%... 70%... 83%... 91%
Requesting system reboot
[  530.101523] reboot: Restarting system
qemu-img create -f qcow2 -F qcow2 -b initvm-base.img initvm.img
Formatting 'initvm.img', fmt=qcow2 cluster_size=65536 extended_l2=off compression_type=zlib size=85899345920 backing_file=initvm-base.img backing_fmt=qcow2 lazy_refcounts=off refcount_bits=16
libvirt: QEMU Driver error : internal error: process exited while connecting to monitor: Could not access KVM kernel module: Permission denied
2022-10-13T13:21:46.112127Z qemu-system-x86_64: failed to initialize kvm: Permission denied
Traceback (most recent call last):
  File "/usr/src/elbe", line 60, in <module>
    cmdmod.run_command(sys.argv[2:])
  File "/usr/src/elbepack/commands/initvm.py", line 96, in run_command
    action.execute(directory, opt, args[1:])
  File "/usr/src/elbepack/initvmaction.py", line 169, in execute
    self.initvm.create()
  File "/usr/lib/python3/dist-packages/libvirt.py", line 1353, in create
    raise libvirtError('virDomainCreate() failed')
libvirt.libvirtError: internal error: process exited while connecting to monitor: Could not access KVM kernel module: Permission denied
2022-10-13T13:21:46.112127Z qemu-system-x86_64: failed to initialize kvm: Permission denied
Starting the initvm Failed
Giving up

My user on the host is in the libvirt and libvirt-qemu group.

[bgermann]

That is why you are on your own with containers: You have to make sure that you can use /dev/kvm. Usually you do that with privileged containers.

[manut]

If you want to use Elbe in a container it might be interesting to just call elbe buildchroot as shown here: https://github.com/Linutronix/elbe/blob/master/contrib/k8s/jenkins-shared-lib/vars/elbebuild.groovy

The used Containerfile is also there: https://github.com/Linutronix/elbe/blob/master/contrib/k8s/Dockerfile

But consider that the container needs to run in privileged mode and qemu binfmt things are available..

Than it is sth very similar to what you do with debos —disable-fakemachine

[danielmeer]

Thanks for the hints! But I think I will give up for the moment.

One of the reasons I wanted to use a container instead of a VM is to use all of my computer's resources when building an image. But as everything is running inside the initvm, I wouldn't have gained anything anyway.