[bug#43650,4/8] services: hurd-vm: Check whether /dev/kvm exists at run time.

This change allows a childhurd to run within Guix System in a VM.

* gnu/services/virtualization.scm (hurd-vm-shepherd-service)[vm-command]:
Stage the 'file-exists?' call.
---
 gnu/services/virtualization.scm | 15 ++++++++-------
 1 file changed, 8 insertions(+), 7 deletions(-)

Ludovic Courtès writes:

Hi!

> This change allows a childhurd to run within Guix System in a VM.

Ah, this

> * gnu/services/virtualization.scm (hurd-vm-shepherd-service)[vm-command]:
> Stage the 'file-exists?' call.
> ---
>  gnu/services/virtualization.scm | 15 ++++++++-------
>  1 file changed, 8 insertions(+), 7 deletions(-)
>
> diff --git a/gnu/services/virtualization.scm b/gnu/services/virtualization.scm
> index d184eea746..b84203ad18 100644
[..]
> -      #~(list
> -         (string-append #$qemu "/bin/qemu-system-i386")
> -         #$@(if (file-exists? "/dev/kvm") '("--enable-kvm") '())

ungexp'ed IF is certainly a bug!

> +      #~(append (list #$(file-append qemu "/bin/qemu-system-i386")
> +                      "-m" (number->string #$memory-size)
> +                      #$@net-options
> +                      #$@options
> +                      "--hda" #+image)
> +                (if (file-exists? "/dev/kvm")
> +                    '("--enable-kvm")
> +                    '())))

Looks good!  However...I tried adding a childhurd to a VM (see
attached), but it keeps looping...

--8<---------------cut here---------------start------------->8---
VNC server running on 127.0.0.1:5900
secret service: connected; sending files in "/etc/childhurd"
qemusystem-i386: Slirp: Failed to send packet, ret: -1
sending secrets to 11004
secret service: retrying connection [59 attempts left]
--8<---------------cut here---------------end--------------->8---

Greetings,
Janneke

Hi!

I’ve pushed ‘wip-childhurd’ with a few additional commits.

The flaky startup issue appears to be fixed by:

  88946005d7 * services: secret-service: Add initial client/server handshake.

Before that, what would happen is that:

  1. The host would connect(2) to QEMU as soon as QEMU is running;
     connect(2) would succeed immediately and so the host would send its
     secrets right away, disconnect, and move on.

     However, at that point, the guest is still booting and its secret
     service server is not even accept(2)ing yet.  Looks like QEMU’s
     SLIRP would more or less buffer the packets the host sent, “more or
     less” being the important point.

  2. The guest would eventually accept(2), which would succeed.  Then it
     would sometimes receive stuff, sometimes not, depending on what
     happened with the SLIRP buffering I suppose.

The fix is to have the server in the guest send a “hello” message.  The
client in the host waits for that message before sending its secrets.

Consequently, it can take ~20s for the ‘start’ method of the childhurd
to succeed.  Eventually, when shepherd runs on Fibers or similar, it
won’t be a problem, but for now it means that PID 1 remains stuck in
select(2) for this many seconds.

Ludo’.

Ludovic Courtès writes:

Hello,

> I’ve pushed ‘wip-childhurd’ with a few additional commits.

Great, this works/fixes it for me!  Using the attached
bare+childhurd.tmpl, I can build and start a Guix VM with a childhurd:

--8<---------------cut here---------------start------------->8---
$ $(./pre-inst-env guix system vm gnu/system/examples/bare+childhurd.tmpl) \
  -m 1G --nographic --net nic \
  --net user,hostfwd=tcp:127.0.0.1:12022-:2222,hostfwd=tcp:127.0.0.1:13022-:10022
--8<---------------cut here---------------end--------------->8---

and then, after half a minute or so:

--8<---------------cut here---------------start------------->8---
$ ssh -p 13022 localhost


  This is the GNU Hurd.  Welcome.

root@childhurd ~#
--8<---------------cut here---------------end--------------->8---

> The flaky startup issue appears to be fixed by:
>
>   88946005d7 * services: secret-service: Add initial client/server handshake.
>
> Before that, what would happen is that:
>
>   1. The host would connect(2) to QEMU as soon as QEMU is running;
>      connect(2) would succeed immediately and so the host would send its
>      secrets right away, disconnect, and move on.
>
>      However, at that point, the guest is still booting and its secret
>      service server is not even accept(2)ing yet.  Looks like QEMU’s
>      SLIRP would more or less buffer the packets the host sent, “more or
>      less” being the important point.
>
>   2. The guest would eventually accept(2), which would succeed.  Then it
>      would sometimes receive stuff, sometimes not, depending on what
>      happened with the SLIRP buffering I suppose.

Ah, thanks for the explanation...that makes sense.

> Consequently, it can take ~20s for the ‘start’ method of the childhurd
> to succeed.  Eventually, when shepherd runs on Fibers or similar, it
> won’t be a problem, but for now it means that PID 1 remains stuck in
> select(2) for this many seconds.

Yeah...Anyway LGTM!

Greetings,
Janneke

Hi!

Jan Nieuwenhuizen <janneke@gnu.org> skribis:

>> I’ve pushed ‘wip-childhurd’ with a few additional commits.
>
> Great, this works/fixes it for me!  Using the attached
> bare+childhurd.tmpl, I can build and start a Guix VM with a childhurd:
>
> $ $(./pre-inst-env guix system vm gnu/system/examples/bare+childhurd.tmpl) \
>   -m 1G --nographic --net nic \
>   --net user,hostfwd=tcp:127.0.0.1:12022-:2222,hostfwd=tcp:127.0.0.1:13022-:10022
>
>
> and then, after half a minute or so:
>
> $ ssh -p 13022 localhost
> 
> 
>   This is the GNU Hurd.  Welcome.
>
> root@childhurd ~#

Thanks for testing again.  I’ve pushed this to ‘master’ as commit
c11c19bd4d0dc4ec56b949647057dbf00567f2ae, along with a new system test
that ensures the childhurd’s SSH server is up and running in the end:

  https://git.savannah.gnu.org/cgit/guix.git/commit/?id=c11c19bd4d0dc4ec56b949647057dbf00567f2ae

You can run it with:

  make check-system TESTS=childhurd

Thank you!

Ludo’.