bug#42252: Not possible to reliably port forward with "guix system vm" anymore

[Christopher Lemmer Webber <cwebber@dustycloud.org>]

[+ Cc: Marius Bakke]
because I don't have enough info to respond fully myself.

Bengt Richter writes:

> 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." :)

Well, I'm definitely not actively trying to 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?

You raise a point in that my "fix to a fix" was a solution when I don't
fully understand the problem that was being fixed.  Of course, this
isn't uncommon in software development, but that doesn't make it great.
I only understood as much context as I could to make my workaround to
the problem.  Is it the right long-term solution?  I'm not sure, but
I think Marius Bakke has more context to be able to reply than I do.
What I do know is that the present instructions we have for port
forwarding are now effectively broken, and this at least provides a way
to get back there.  It might not be the right one.

For the rest of your email, I do think Guix is well layered... but even
well layered systems sometimes have intermediate proposed solutions to
bugs.  Sometimes the right design is found along the way.

But part of the goal of submitting such a patch is to get code review
and provoke discussion of what the right thing is.  I *did* make it
clear that I thought it was ugly, but workable.  :)

It might not be the totally wrong thing either though... if there are
enough modifications that users might make to the -nic flag, but we
don't know how to nicely abstract over all of them yet, but for now we
do need to supply a default, this can be an escape hatch at least for
now.  This wouldn't be uncommon; that's very similar to how Guix system
configuration tends to go (we supply configuration builders for the most
common options but sometimes provide a way to just slot in a manual
config file when need be).

 - Chris