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

Previous Next

Full log

View this message in rfc822 format

From: help-debbugs <at> gnu.org (GNU bug Tracking System)
To: Marius Bakke <marius <at> gnu.org>
Cc: tracker <at> debbugs.gnu.org
Subject: bug#42252: closed (Not possible to reliably port forward with
 "guix system vm" anymore)
Date: Sat, 11 Jul 2020 21:39:01 +0000

[Message part 1 (text/plain, inline)]

Your message dated Sat, 11 Jul 2020 23:38:26 +0200
with message-id <87lfjpd965.fsf <at> gnu.org>
and subject line Re: bug#42252: Not possible to reliably port forward with "guix system vm" anymore
has caused the debbugs.gnu.org bug report #42252,
regarding Not possible to reliably port forward with "guix system vm" anymore
to be marked as done.

(If you believe you have received this mail in error, please contact
help-debbugs <at> gnu.org.)


-- 
42252: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=42252
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems

[Message part 2 (message/rfc822, inline)]

From: Christopher Lemmer Webber <cwebber <at> dustycloud.org>
To: bug-guix <at> gnu.org
Subject: Not possible to reliably port forward with "guix system vm" anymore
Date: Tue, 07 Jul 2020 16:40:21 -0400

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.

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

[Message part 3 (message/rfc822, inline)]

From: Marius Bakke <marius <at> gnu.org>
To: Christopher Lemmer Webber <cwebber <at> dustycloud.org>,
 42252-done <at> debbugs.gnu.org
Subject: Re: bug#42252: Not possible to reliably port forward with "guix
 system vm" anymore
Date: Sat, 11 Jul 2020 23:38:26 +0200

[Message part 4 (text/plain, inline)]

Hello!

Sorry for this breakage, and thanks for the analysis!

Christopher Lemmer Webber <cwebber <at> dustycloud.org> writes:

> 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.
>
> 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?

My motivation for the breaking commit was just that 'guix system vm' and
system tests would use virtio by default.  Without it, system tests with
forwarded ports used a different driver than those without forwardings.
It's a very minor issue and can be solved in other ways.  :-)

If no -nic parameter is specified on the QEMU command line, QEMU will
create one, emulating an Intel NIC.  I did not consider the discrepancy
this caused with the documentation when we unconditionally pass a -nic
parameter!

I think we should revert the commit, so that '`guix system vm` -nic foo'
works as expected for end users.  In fact I just did so.  :-)

Fixed in 1abf205d11c8b941d7d89855cb55a9cfde078838, thanks!

[signature.asc (application/pgp-signature, inline)]

Previous Next

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