Re: Bad parameter to boot GuixSD in a VM

[Miroslav Rovis <miro.rovis@croatiafidelis.hr>]

[-- Attachment #1: Type: text/plain, Size: 6261 bytes --]

A part reply (since I'm not sure to find time soon for more detailed
reply on some of the issues broght up, which I would very much like, but
not sure will be able to).

On 170411-21:00-0400, Leo Famulari wrote:
> On Tue, Apr 11, 2017 at 10:38:44PM +0200, Miroslav Rovis wrote:
> 
> Hi, thanks for the detailed feedback!
Your're most welcome. I'm really glad you find it useful. 

> 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.
I see.

> 
> > root@gnu ~# ping www.gnu.org
> > ping: unknown host
> > root@gnu ~#
> >
> > Previously I ran "ip a", nothing really shows... And afterwards I tried:
> > 
> > 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
> > 
> > but none of those seems to be installed.
> > 
> > In short, no network in the Guix guest...
> 
> There is a built-in network client `guix download` that you could try.
I will, as soon as I find time to.

Mainly this `guix download` I have to leave for later... (That's the
part I'll possibly go back to, in the future. Possibly.)

> There was (is?) a bug related to name resolution failures being cached
> for too long in certain cases:
> 
> <https://bugs.gnu.org/22209>
Looked it up, but not enough to understand it more fully... yet.
(another part for later)

> So, I connect to a well-known IP address like 8.8.8.8 in order to test
> the network.
Oh, no, just not Schmoog the Schmoogle, pls. :-) I don't recommend the
Schmoog to anybody. My opinion. Freely disregard it of course. However,
few people can dispute that the Schmoog are the toughest surveillors on
the world, that Sergey and Larry Schmoog made most of their moneys out
of, essentially spying on everybody they could lay their tentacles on
their electronic communications of any kind, so essentially they're
spies, and they made their moneys with the aforesaid spying, and that
their (mostly unwilling and unwitting) payers are, essentially tax
payers via almost any, even almost every country's of the world secret
agencies, from NSA to China's SA (whichever the name of it)... So...

But again, I'm only reminding about the facts/claims aforementioned, and
anybody's opinion is free to differ. I'm done reminding. Moving on
(unless there should be a need to consider replies in regard).

> 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.
May be. I'm not even advanced with Qemu... More below...

> 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?
Not that I know of, but I did find, back a few months ago when I
dedicated hours upon hours for my first long reading of Qemu manual, and
wikis in various places about Qemu, that it was much better (the cited
reasons I don't remember clearly at this time) to use "-netdev ...".

> > Let me try another script:
> > 
> > =-=--===-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> > 
> > #!/bin/sh
> > exec qemu-system-x86_64 \
> > 		-machine type=q35,accel=kvm \
> > 		-enable-kvm \
> > 		-cpu host \
> > 		-device virtio-net,netdev=internet \
> > 		-netdev \
> > 			bridge,br=br0,id=internet,helper=/usr/libexec/qemu-bridge-helper \
> > 		-m 4196M \
> > 		-monitor stdio \
> > 		-boot menu=on \
> > 		-drive file=guixsd.img \
> > 		-drive file=guixsd-usb-install-0.12.0.x86_64-linux 
> > 
> > =-=--===-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> > 
> > 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?
Yes it is. If it wasn't, how would I be able to connect to internet my
VMs running Devuan, Refracta, Tails, Gentoo, Heads (each in their time,
I run simple Qemu one at a time), if it wasn't...

> 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...
Yes it is, I remember that much. Actually now I'll tell the "more" which I
promised above.

I essentially created my scripts following various tutuorials and
copying btwn various scripts what got the previous ones running...  ;-)
Wow! how clever of me, how expertly done  ;) ;) ;) ;) 

And I actually wasn't able to get the use more networking! I think with
none or hardly one of the various VMs mentioned (and if I did with one
of the above, I don't remember which one it was anymore)...

I don't understand much at all (and maybe won't any time soon, nor later
either) on the programming side of it... But I do start those few VMs of
various kind (mentioned above) without much issues most of them these
days, and half a year ago, I wasn't able to, say, get the network
working on any of the ISOs I was trying back then...

I wish in some more time that I would learn more and be able to test for
good FOSS like Guix!

Regards!

-- 
Miroslav Rovis
Zagreb, Croatia
https://www.CroatiaFidelis.hr

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]