GNU bug report logs - #42252
Not possible to reliably port forward with "guix system vm" anymore

Previous Next

Full log

Message #17 received at 42252 <at> debbugs.gnu.org (full text, mbox):

From: Bengt Richter <bokr <at> bokr.com>
To: Christopher Lemmer Webber <cwebber <at> dustycloud.org>
Cc: 42252 <at> debbugs.gnu.org
Subject: Re: bug#42252: Not possible to reliably port forward with "guix
 system vm" anymore
Date: Wed, 8 Jul 2020 11:46:28 +0200

Hi

On +2020-07-07 16:40:21 -0400, Christopher Lemmer Webber wrote:
> In commit 5379392731b52eef22b4936637eb592b93e04318, the following change
> was introduced:
> 
>   modified   gnu/system/vm.scm
>   @@ -941,6 +941,7 @@ with '-virtfs' options for the host file systems listed in SHARED-FS."
>                '())
>    
>         "-no-reboot"
>   +     "-nic" "user,model=virtio-net-pci"
>         "-object" "rng-random,filename=/dev/urandom,id=guixsd-vm-rng"
>         "-device" "virtio-rng-pci,rng=guixsd-vm-rng"
> 
> Unfortunately, this means that in our docs where we suggest doing the
> following:
> 
>   `guix system vm config.scm` -nic user,model=virtio-net-pci,hostfwd=tcp::10022-:22
> 
> Since we now provide our own similar "-nic" field this creates a
> *second* network interface at the same address and there is a race as in
> terms of which handles connections.  Depending on the race result,
> connections to the forwarded port may hang indefinitely.
> 
> Ironically, this regression was introduced to solve another regression!
> From the commit message:
> 
>   This fixes a regression introduced in 8e53fe2b91d2776bc1529e7b34967c8f1d9edc32
>   where 'guix system vm' would no longer be using virtio.
>

This reminds a bit of doctors prescribing powerful medicine with side-effect so bad
that they have to prescribe a medicine for that, which in turn has side-effects,
in what I think is called prescription cascading, and people wind up on 25 pills a day.

"First, do no harm." :)

I wouldn't say anything, except ISTM your fix on top of a fix
is not the first to remind me of cascading :)

> What's the right solution?  One could be that "guix system vm" itself
> could take an argument that sets up port forwarding in the generated
> shell script.  Eg:
> 
>   guix system vm config.scm --hostfwd=tcp::10022-:22 --hostfwd=tcp::8888-:80
> 
> kind of ugly, but it could work.  WDYT?
> 
>  - Chris
> 
> 
> 

I'm not saying your solution is bad, I'm just saying cascading fixes may be a symptom
to diagnose, in case it indicates something like bad mutations involving bad genes
that will compromise the health of the guix ecology.

How is a "fix" judged with respect to the big picture?

Is there a higher level layered[1] design for the use of guix, like e.g. [2] which a proposed fix
might violate and therefore should be rejected, even though it makes something "work"?

Well, it's probably in an old paper by Ludo in some form, but I wonder
what concepts of layering guix developers are consciously using
when putting stuff between the declarations at the top and
the images at the bottom.

[1] https://en.wikipedia.org/wiki/Abstraction_layer
[2] https://en.wikipedia.org/wiki/OSI_model

-- 
Regards,
Bengt Richter
 

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.