[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Connection of a qemu guest to the 'net.
Re: Connection of a qemu guest to the 'net.
Fri, 19 Mar 2021 07:59:31 +1100
So just to get to your last point first again
"network script /etc/qemu-ifup failed with status 256"
might mean that qemu couldn't find the script or the file isn't executable.
Can you try again making sure that the /etc/qemu-ifup script exists, that it's
first line is "!#/bin/sh" and that it's executable (chmod a+x /etc/sh")
Alternately, can you put the script in the directory you're working in and
explicitly specify the location of the script on the command line as follows?
sudo qemu-system-i386 \
-drive file=/dev/KingstonCF,media=disk,format=raw \
-vga std \
-boot order=c \
-netdev type=tap,id=peternet,script="./qemu-ifup",downscript=no \
If that still doesn't work then perhaps you could manually try to run the
script with a temporarily created tap interface as follows.
sudo ip tuntap add mode tap name tap8
sudo ip link set tap8 up
sudo /etc/qemu-ifup tap8
If there are no errors see if the tap interface is actually connected to the
bridge with either the "ip" or "brctl" commands. On my system I get
# sudo ip link show master br0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq master br0 state
UP mode DEFAULT group default qlen 1000
link/ether dc:xx:xx:xx:xx:55 brd ff:ff:ff:ff:ff:ff
177: tap8: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast master
br0 state DOWN mode DEFAULT group default qlen 1000
link/ether 0a:xx:xx:xx:xx:46 brd ff:ff:ff:ff:ff:ff
# sudo brctl show br0
bridge name bridge id STP enabled interfaces
br0 8000.020000000002 no eth0
Then you can delete the temporary tap interface
# sudo ip tuntap del mode tap tap8
> > If one of the more experienced people who lurk on these forums could
> > comment on it just in case it's pure rubbish I'd be more comfortable
> > making an attempt at putting it somewhere permanent.
> Organizing into sections with headings will help. Almost any addition
> to https://en.wikibooks.org/wiki/QEMU/Devices/Network will be
> improvement. Content with an error or two is better than no content. (!)
> In a wiki, errors can be corrected. =8~)
Yes, good point. As I said I'll look into it and let you know if I do it so you
can review it!
> > My view is that Interfaces are at the Data Link and optionally at the
> > Network Layer as well. For example an eth0 interface has an Ethernet
> > MAC address (Data Link Layer) but if you want you can also give it an
> > IP and IPv6 address (Network Layer).
> OK. Acknowledged.
> > You have to create the bridge before you connect the interface to it
> > in the same way that you have to put your network switch on the desk
> > before you can plug your Ethernet cables into it!!
> Interesting analogy. Seems strictly correct although a reader might
> misinterpret. The switch and cables are both at the physical layer
> whereas you refer to them as analogues rather than OSI components.
Yeah, I reflected on that analogy last night and I thought it was a bit flawed
in that respect too.
> > Can you clarify that? Do you mean you have no bridge on the Shorewall?
> > Does it have a switch in it? A "switch" and a "bridge" are
> > functionally equivalent.
> This is my understanding. Shorewall is not a daemon. It sets up
> routing by iptables.
> Any command such as "ip link show" never reported a bridge until br0
> was created for qemu. To my understanding, Shorewall does not require
> a bridge or switch but either can be present with Shorewall. Several
> documents are available. One here.
> > > inet6 fe80::6c05:fdff:fedf:e2eb/64 scope link
> > > valid_lft forever preferred_lft forever
> > This is the IPv6 Link Local address. Every interface with IPv6
> > enabled will automagically assign itself an IPv6 address based on it's
> > eMAC address.
> Thanks. I'm learning about IPv6 along with qemu.
IPv6 is pretty awesome, mainly because it lets you access servers on your
network from the wider internet without having to do weird things with IPv4
NAT. Does your ISP provide you with IPv6 connectivity? If so then it's
definitely worth setting up. I have some servers on my network that I can
access remotely via IPv6 and it's so easy and convenient. The other great thing
about it is that because the address space is so massively huge, you never get
entities on the internet randomly "scanning" your hosts because it would take
20 septillion years for them to find them due to there being so many addresses
available. My IPv4 host (my router) gets scanned all day every day.
> This is my current qemu command.
> sudo qemu-system-i386 \
> -drive file=/dev/KingstonCF,media=disk,format=raw \
> -vga std \
> -boot order=c \
> -nic tap,model=ne2k_pci,br=br0
> As described previously, br0 is created here when the qemu host boots.
> br0 continues to exist when qemu is executed.
Do you need the "br=br0" parameter there? Anyway, see the top of the post for
> With the /etc/qemu-ifup provided by Berto, no guest system appears
> and this is reported to the terminal.
> qemu-system-i386: network script /etc/qemu-ifup failed with status 256
> With the /etc/qemu-ifup provided by qemu in Debian 10, a guest system
> appears and this is reported to the terminal.
> W: /etc/qemu-ifup: no bridge for guest interface found
Is there one included in qemu? Can you send me a copy? Does it need to be
edited to include the bridge interface name?
Anyway, we're getting there!
> br0 is present but qemu fails to recognize it. The /etc/qemu-ifup in
> Debian avoids catastrophic failure.
> Why does qemu fail to recognize br0? My best guess is that an error
> is present in my qemu command above.
> Thx, ... P.
> cell: +1 236 464 1479 Bcc: peter at easthope. ca
> VoIP: +1 604 670 0140