From mboxrd@z Thu Jan 1 00:00:00 1970 From: Leo Famulari Subject: Re: Bad parameter to boot GuixSD in a VM Date: Tue, 11 Apr 2017 21:00:43 -0400 Message-ID: <20170412010043.GA5129@jasmine> References: <871st0ctpw.fsf@gnu.org> <20170411203844.GA14661@g0n.xdwgrp> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="XsQoSWH+UP9D9v3l" Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:38254) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cy6eR-00065P-Dx for help-guix@gnu.org; Tue, 11 Apr 2017 21:00:52 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cy6eO-0000ro-Ci for help-guix@gnu.org; Tue, 11 Apr 2017 21:00:51 -0400 Received: from out1-smtp.messagingengine.com ([66.111.4.25]:56092) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1cy6eO-0000r2-0q for help-guix@gnu.org; Tue, 11 Apr 2017 21:00:48 -0400 Content-Disposition: inline In-Reply-To: <20170411203844.GA14661@g0n.xdwgrp> List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-guix-bounces+gcggh-help-guix=m.gmane.org@gnu.org Sender: "Help-Guix" To: Miroslav Rovis Cc: pierre@2bst.fr, help-guix@gnu.org --XsQoSWH+UP9D9v3l Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Apr 11, 2017 at 10:38:44PM +0200, Miroslav Rovis wrote: Hi, thanks for the detailed feedback! In general, the instructions in the manual related to QEMU are the simplest QEMU invocations that will work for basic use cases. They are intended to be something that a person without QEMU experience can use to boot GuixSD in a virtualized environment. We assume that users will adapt these examples to their use case if they plan to virtualize GuixSD in production. > root@gnu ~# ping www.gnu.org > ping: unknown host > root@gnu ~# > > Previously I ran "ip a", nothing really shows... And afterwards I tried: >=20 > root@gnu ~# curl https://www.gnu.org > root@gnu ~# links https://www.gnu.org > root@gnu ~# elinks https://www.gnu.org > root@gnu ~# lynx https://www.gnu.org >=20 > but none of those seems to be installed. >=20 > In short, no network in the Guix guest... There is a built-in network client `guix download` that you could try. There was (is?) a bug related to name resolution failures being cached for too long in certain cases: So, I connect to a well-known IP address like 8.8.8.8 in order to test the network. As an aside, the unprivileged "user mode" QEMU networking system doesn't support ICMP, so if you were using that, ping won't work. > And I was courious, why are you suggesting/recommending (in that manual) > the old: > -net ... > instead of the new: > -netdev ... > ? The Qemu devs are firm that the new is better, IIUC. I looked into this previously, and I decided to keep the old '-net user' syntax in the examples we provide. My reason is that '-netdev user' requires the user to specify a unique 'id' parameter, while '-net user' does not. Since both syntaxes provide the same "user mode network stack", I thought that the older and simpler syntax was better for the examples in the manual. Remember, these are supposed to be the simplest examples that will boot GuixSD with a network connection. Is there some limitation with '-net user' that we should consider for the examples in the manual? > Let me try another script: >=20 > =3D-=3D--=3D=3D=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-= =3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D >=20 > #!/bin/sh > exec qemu-system-x86_64 \ > -machine type=3Dq35,accel=3Dkvm \ > -enable-kvm \ > -cpu host \ > -device virtio-net,netdev=3Dinternet \ > -netdev \ > bridge,br=3Dbr0,id=3Dinternet,helper=3D/usr/libexec/qemu-bridge-helper= \ > -m 4196M \ > -monitor stdio \ > -boot menu=3Don \ > -drive file=3Dguixsd.img \ > -drive file=3Dguixsd-usb-install-0.12.0.x86_64-linux=20 >=20 > =3D-=3D--=3D=3D=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-= =3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D >=20 > Oh, yes! This is maybe 10 times faster! Yes, KVM will do that :) > But, still no network... Hmmmh! Hm, I'm not sure what's wrong. I assume that the TAP device is properly configured in your host system? The nice thing about the user-mode QEMU networking is that it doesn't require any special configuration on the host. But of course it's very limited... --XsQoSWH+UP9D9v3l Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEsFFZSPHn08G5gDigJkb6MLrKfwgFAljtfDsACgkQJkb6MLrK fwg2PA//djCmEIZH9IYZyLcIueE+ErX7246SGGMMdLT7T1Z/nPRr4MudqTCfF6pG hQmfKsqsSR+TYTrqGkfJruFO90UzWGfXpWxWYRPX6C2SVmsdtmTM9jnVBstBN3Bc sLQZ4+7DRm7Ih1QELDbuGYJAWd/d0q9N/5M0QP4pbcu1kbtJ1ezSKJ9rWXOCjxFu BSyzyUoLYYlRrsNKYEfPjMiEJCwKc642Let14Xp+eJD2oxTN6/+tJi8KgFi8dCju DcMnt2oKZ3/LVkQuVPa/L2KIOUY85K5+Q8DfHSwaRdcu7G7m7a/PfWZo53i6nCpK xwzEYz6UHQAqnTgJOkXiVFJVKKjUQcuEMMgWSigL070TDydPXvzCW/+wzV50bMro 7jCVHiDic6OeomW38jr2+cmBRbpNRftXOsuL84vCRsLgwJOvAaPZ4lxfKUPK33K9 dEILvHG7fRIL4OMBrVoxS7K3lW9gxQY+JUhtl/Qt0a2gVenk6DVUyYVWPIWKUh7C uzlUTDz4COZM7Q7TNue3IWHb35O63DmdwWNuaOak9RcHOdyEpam+PGZCKI/QTJD0 wr812wSybqXpGWBipoafY/shGSGBeffrZZQ7wj5dFpenCAOKhUYFvVmLkv4SVK2u 9l6IDx1mrkm4qF1etu7AxvnTkboCk0qnN8sGrIyWMbVjF2EAZ4o= =GApm -----END PGP SIGNATURE----- --XsQoSWH+UP9D9v3l--