Re: Python 2 and test/vm/netbsd

[Eduardo Habkost]

On Fri, Oct 18, 2019 at 09:13:24AM +0200, Thomas Huth wrote:
> On 18/10/2019 00.55, Eduardo Habkost wrote:
> > On Thu, Oct 17, 2019 at 07:05:41PM -0300, Eduardo Habkost wrote:
> >> On Wed, Oct 16, 2019 at 07:41:24PM -0300, Eduardo Habkost wrote:
> >>> On Wed, Oct 16, 2019 at 08:11:57AM +0200, Thomas Huth wrote:
> >>>> On 16/10/2019 05.00, Eduardo Habkost wrote:
> >>>>> On Tue, Sep 17, 2019 at 08:31:40PM -0300, Eduardo Habkost wrote:
> >>>>>> On Mon, Jul 01, 2019 at 07:25:27PM -0300, Eduardo Habkost wrote:
> >>>>>>> On Mon, Jun 10, 2019 at 01:58:50PM +0100, Peter Maydell wrote:
> >>>>> [...]
> >>>>>>>> The configure check also spits out deprecation warnings for
> >>>>>>>> the NetBSD/FreeBSD/OpenBSD tests/vm configurations. It would be nice
> >>>>>>>> to get those updated.
> >>>>>>>
> >>>>>>> CCing the test/vm maintainers.
> >>>>>>>
> >>>>>>> Fam, Alex, are you able to fix this and create new BSD VM images
> >>>>>>> with Python 3 available?  I thought the VM image configurations
> >>>>>>> were stored in the source tree, but they are downloaded from
> >>>>>>> download.patchew.org.
> >>>>>>
> >>>>>> Fam, Alex, can you help us on this?  Python 2 won't be supported
> >>>>>> anymore, so we need the VM images to be updated.
> >>>>>
> >>>>> Anyone?
> >>>>>
> >>>>> I'm about to submit patches to remove Python 2 support, and this
> >>>>> will break tests/vm/netbsd.
> >>>>>
> >>>>> I'm powerless to fix this issue, because the netbsd image is
> >>>>> hosted at download.patchew.org.
> >>>>
> >>>> Gerd had a patch to convert the netbsd VM script to ad hoc image
> >>>> creation, too:
> >>>>
> >>>> https://lists.gnu.org/archive/html/qemu-devel/2019-05/msg04459.html
> >>>>
> >>>> But there was a regression with the serial port between QEMU v3.0 and
> >>>> v4.x, so it was not included:
> >>>>
> >>>> https://lists.gnu.org/archive/html/qemu-devel/2019-05/msg06784.html
> >>>
> >>> The URL above has this error:
> >>>
> >>>   con recv:  x: Exitqqqqqqqqqqqqqqqqqqqqqqqqqj
> >>>   con recv: To be able to use the network, we need answers to the
> >>>   following:Network media type
> >>>   con send: <enter>
> >>>   con recv: : qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqk Perform autoconfiguration?
> >>>      >a: Yes b: Noqqqqqqqqqqqqqqqqq
> >>>   console: *** read timeout ***
> >>>   console: waiting for: 'a: Yes'
> >>>   console: line buffer:
> >>>   
> >>>   con recv: qqqqqqqqqqqqqqj
> >>>
> >>> I believe that problem was solved in v4, because v4 was reading
> >>> the serial output 1 byte at a time.
> >>>
> >>> The issue that caused the netbsd patch to be dropped was:
> >>> https://lore.kernel.org/qemu-devel/address@hidden/
> >>>
> >>> Possibly this is the same issue we saw at:
> >>> https://lore.kernel.org/qemu-devel/address@hidden/
> >>>
> >>> The test script must either close the console socket, or keep
> >>> reading from it.  Otherwise, the QEMU VCPU threads might get
> >>> stuck waiting for the chardev to be writeable.
> >>
> >> It doesn't seem to be the same issue.  Even if the console socket is 
> >> closed,
> >> I'm seeing results similar to the ones reported by Peter (the "pkgin -y
> >> install" step is unreasonably slow).
> >>
> >> Running with V=1, I see packages being downloaded at reasonable speeds, but
> >> there's a huge interval (of various minutes) between each package download.
> > 
> > I've found the cause for the slowness I'm seeing: for each file
> > being downloaded, the guest spents at least 75 seconds trying to
> > connect to the IPv6 address of ftp.NetBSD.org, before trying
> > IPv4.  I don't know if this is a NetBSD bug, or a slirp bug.
> 
> Does it work better if you turn IPv6 off? E.g.:
> 
> diff --git a/tests/vm/basevm.py b/tests/vm/basevm.py
> --- a/tests/vm/basevm.py
> +++ b/tests/vm/basevm.py
> @@ -81,7 +81,7 @@ class BaseVM(object):
>          self._args = [ \
>              "-nodefaults", "-m", "4G",
>              "-cpu", "max",
> -            "-netdev", "user,id=vnet,hostfwd=:127.0.0.1:0-:22",
> +            "-netdev", "user,id=vnet,hostfwd=:127.0.0.1:0-:22,ipv6=off",
>              "-device", "virtio-net-pci,netdev=vnet",
>              "-vnc", "127.0.0.1:0,to=20"]
>          if vcpus and vcpus > 1:

Yes, it is much better.  Thanks!

I will send a series disabling ipv6 in tests/vm/netbsd as a
workaround.

-- 
Eduardo