Re: [Qemu-discuss] How to set the network card for qemu to use?

2016-10-16 Thread Miroslav Rovis
On 161016-11:26+0200, Miroslav Rovis wrote:
...
> If I wasn't poor, I'd donate to you or where you would tell me to, but
> I'm like a Church mouse, very poor...
...

Just as the closed source makes it all mostly dirty, and in real
big-brotherly world of today it's absolutely treacherous with spying
(yes, surveillance is just the euphemism), so is the FOSS, the Free Open
Source Software the sole area that makes computing in the world not just
palatable but such a great experience of freedom and of user's own
control. User's own control is not really possible in any
Bapple-Schmapple not Schwindoze-Bindoze, just as the Schmoogle and
Zucksbook and such are dirt in themselves... 

But that would be another story that is told too little to to few
nowadays...

I updated, and I'd believe it's probably the final look and content of
that page:
http://www.croatiafidelis.hr/foss/cap/cap-161015-qemu-devuan/

In short, it works, and it's just the iptables rules that I need to
fix, but if I will need help for that, it's probably at
http://lartc.org/.  

Aleksei, thanks so much, to you and to all the Qemu people!
-- 
Miroslav Rovis
Zagreb, Croatia
http://www.CroatiaFidelis.hr


signature.asc
Description: Digital signature


Re: [Qemu-discuss] How to set the network card for qemu to use?

2016-10-16 Thread Miroslav Rovis
On 161016-10:41+0300, Aleksei wrote:
> Your link layer looks good, eth1 is enslaved to br0. On network layer, 
> you don't get an IP address - is it because you don't have a physical 
> cable plugged into eth1?
It is plugged in.

> Anyway, that shouldn't prevent Qemu from 
> creating taps on that bridge.
> 
> As for permissions stuff from Qemu side:
> Add "allow br0" line to /etc/qemu/bridge.conf to allow Qemu to create 
> tap devices on br0.

On my system:

# ls -l /etc/qemu/
total 8
-rw-r- 1 root miro 453 2016-08-13 14:39 bridge.conf
-rw-r- 1 root miro 288 2016-08-13 14:40 miro.conf
#

There is the line:
 allow br0
in /etc/qemu/bridge.conf

And in the same /etc/qemu/bridge.conf there reads also :

 include /etc/qemu/miro.conf
# Uncommenting the above would allow users in the 'bob' group
# to have permissions defined in it, iff it has the following
# permissions: root:bob 0640

And  /etc/qemu/miro.conf has one more time:

 allow br0

That's the configuration (which I arranged several weeks ago).

> Also check if qemu-bridge-helper script has setuid attribute. It should 
> have it by default, but I'm not sure about Gentoo.

I need to look more deeply into all of this... Might take time. Also, I
couldn't sleep, and I might be unable to work most of the day till
evening, can't tell...

I also had, in my /etc/sysctl.conf the line:

net.ipv4.ip_forward = 1

which, until I changed it to:

net.ipv4.ip_forward = 0

I couldn't connect just now, for a while. (I put it there when I
successfully set up connecting a LAN-only host via this router, to
internet:
http://www.croatiafidelis.hr/foss/router/SNAT-inet/
but afterwards I forgot to turn it off...

> I know nothing about grsec, so can't help you there.
You're missing a lot! 

> /--Regards, Aleksei/
> 

Thanks a lot. I would possibly have gone the wrong way and maybe even
got lost, had you not helped me.
-- 
Miroslav Rovis
Zagreb, Croatia
http://www.CroatiaFidelis.hr


signature.asc
Description: Digital signature


Re: [Qemu-discuss] How to set the network card for qemu to use?

2016-10-16 Thread Miroslav Rovis
On 161016-10:51+0300, Aleksei wrote:
> > Esp. from the screencast at:
> 
>  > 
> http://localhost/CroatiaFidelis/foss/cap/cap-161015-qemu-devuan/Screen_161016_0501_g0n.webm
>   
That was my local-only Apache. Sorry (it's sleeplessness and
headaches...)! It translates into:
http://www.CroatiaFidelis.hr/foss/cap/cap-161015-qemu-devuan/Screen_161016_0501_g0n.webm
  
> 
> > it is clear qemu still wants to use eth0.
> 
> If that last fullscreen log is Devuan's - then no, that last *eth0* 
> interface is *inside* the VM. Devuan sets up his own default eth0. Btw, 
> you're posting links to localhost :)
Really thanks! I almost went abandoning trying eth1 anymore.

> If you don't have a cable connected to eth1 interface on the host, then 
> naturally Devuan can't get IP address via DHCP (on Devuan's eth0).
The cable is connected though. I have it in front of me, the router's
light of the connection whenever I connect. 

And one more of your kind emails to go.

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


signature.asc
Description: Digital signature


Re: [Qemu-discuss] How to set the network card for qemu to use?

2016-10-16 Thread Aleksei
Your link layer looks good, eth1 is enslaved to br0. On network layer, 
you don't get an IP address - is it because you don't have a physical 
cable plugged into eth1? Anyway, that shouldn't prevent Qemu from 
creating taps on that bridge.


As for permissions stuff from Qemu side:
Add "allow br0" line to /etc/qemu/bridge.conf to allow Qemu to create 
tap devices on br0.
Also check if qemu-bridge-helper script has setuid attribute. It should 
have it by default, but I'm not sure about Gentoo.


I know nothing about grsec, so can't help you there.

/--Regards, Aleksei/



*From:* Miroslav Rovis
*Sent:* Sunday, October 16, 2016 6:18AM
*To:* Qemu-discuss
*Subject:* Re: [Qemu-discuss] How to set the network card for qemu to use?

On 161014-12:11+0300, Aleksei wrote:
...

2) Include the following to your Qemu command line. You don't need to
manually create tap devices on the host, qemu-bridge-helper script does
this for you.
  -device virtio-net,netdev=internet \
  -netdev
bridge,br=bridge0,id=internet,helper=/usr/lib/qemu/qemu-bridge-helper

3) Start VM, post results. Please try to be concise ;)

I thought about this, but what could I cut out from the log that is in
the end of this email, and which I misunderstood at first...


and post what you
are trying to do and actual error messages. Also provide your Qemu version.

$ qemu-system-x86_64 --version
QEMU emulator version 2.7.0, Copyright (c) 2003-2016 Fabrice Bellard and
the QEMU Project developers
$

I set up a bridge, not the iproute2's bridge utility's way (the one thing that
I don't use, yet, from iproute2), but the brctl way, such as:
https://wiki.gentoo.org/wiki/Network_bridge#OpenRC

This is the setup (but read: /usr/share/doc/netifrc-0.4.0/net.example.bz2 if
you run Gentoo, for other distro it's different, can't tell) [the setup]
in Gentoo:

# cat /etc/conf.d/net

modules="!udhcpc !dhclient !pump"

mac_eth0="random-ending"
config_eth0="192.168.2.4 netmask 255.255.255.0"
config_br0="192.168.1.4/24"

brctl_br0="setfd 0"
brctl_br0="sethello 10"

bridge_br0="eth1"
rc_net_br0_need="net.eth1"

mac_eth1="00:0e:2e:fd:24:9c"
config_eth1="192.168.1.4/24"

But it is very specific to Gentoo, or whoever uses netifrc package in their
distro.

Anyway, I got the layer 2, the link layer (IIRC):

# ip l

...
3: eth0:  mtu 1500 qdisc pfifo_fast state 
DOWN mode DEFAULT group default qlen 1000
 link/ether 00:0e:2e:ac:5c:a9 brd ff:ff:ff:ff:ff:ff
4: eth1:  mtu 1500 qdisc pfifo_fast master 
br0 state DOWN mode DEFAULT group default qlen 1000
 link/ether 00:0e:2e:fd:24:9c brd ff:ff:ff:ff:ff:ff
...
7: br0:  mtu 1500 qdisc noqueue 
state DOWN mode DEFAULT group default qlen 1000
 link/ether 00:0e:2e:fd:24:9c brd ff:ff:ff:ff:ff:ff

and I got the layer 3, the internet layer (IIRC):

# ip a

...
3: eth0:  mtu 1500 qdisc pfifo_fast state 
DOWN group default qlen 1000
 link/ether 00:0e:2e:ac:5c:a9 brd ff:ff:ff:ff:ff:ff
 inet 192.168.2.4/24 brd 192.168.2.255 scope global eth0
valid_lft forever preferred_lft forever
4: eth1:  mtu 1500 qdisc pfifo_fast master 
br0 state DOWN group default qlen 1000
 link/ether 00:0e:2e:fd:24:9c brd ff:ff:ff:ff:ff:ff
 inet6 fe80::1d9f:ad47:f44d:8d9e/64 scope link
valid_lft forever preferred_lft forever
...
7: br0:  mtu 1500 qdisc noqueue 
state DOWN group default qlen 1000
 link/ether 00:0e:2e:fd:24:9c brd ff:ff:ff:ff:ff:ff
 inet6 fe80::20e:2eff:fefd:249c/64 scope link
valid_lft forever preferred_lft forever

My mistake, several weeks ago when I tried this, but couldn't make it, was to
create tap0 device, instead what Aleksei said, to allow the helper to create
that tap0 device for the Qemu instance.

And this is the command that I started the Qemu with:

$ qemu-system-x86_64 -machine type=q35,accel=kvm -enable-kvm -cpu host \
-display gtk -m 1024M -device virtio-net,netdev=internet -netdev
bridge,br=br0,id=internet,helper=/usr/libexec/qemu-bridge-helper
devuan_jessie_1.0.0-beta_amd64_cloud.qcow2

Just the helper=/usr/libexec/qemu-bridge-helper is a different string than
what Aleksei suggested (it is not in /usr/lib/qemu/qemu-bridge-helper).

Must not forget to say, that I had to enable learning in the grsecurity policy
with adding this to /etc/grsec/policy:

# Role: miro
subject  /usr/libexec/qemu-bridge-helper ol
/   h
-CAP_ALL
binddisabled
connect disabled

However, a grsecurity-hardened system usually asks for even more care. It
protects you very well, but is quite a handful...

Here are the logs. And, of course, solving that remaining issue is a
grsecurity issue, not anymore qemu issue.

I think the 

Re: [Qemu-discuss] How to set the network card for qemu to use?

2016-10-15 Thread Miroslav Rovis
On 161016-05:18+0200, Miroslav Rovis wrote:
> On 161014-12:11+0300, Aleksei wrote:
...
> 
> UPDATE: No, it isn't solved, but it wouldn't fit in this email. And I already
> wrote all of this. Pls. continuation should follow soon.

And it's much less now...

But first, pls. note that the:

http://localhost/CroatiaFidelis/foss/cap/cap-161015-qemu-devuan/

now contains three sets of screencast/traces. The last one is about what
this thread, by the subject, tries to solve.

The following is again a previously prepared text (a short while ago).

---

I was almost sure that after some more learning set into grsecurity policy:

# Role: root
subject /sbin/dhcpcd ol
/   h
-CAP_ALL
binddisabled
connect disabled

that qemu-created tap0 would connect to the br0 that I created and all would
be fine.

However, this is how it went:

Oct 16 05:02:12 g0n kernel: [169135.452910] grsec: 
(miro:U:/usr/bin/qemu-system-x86_64) exec of /usr/bin/qemu-system-x86_64 
(qemu-system-x86_64 -machine type=q35,accel=kvm -enable-kvm -cpu host -display 
gtk -m 1024M -device virtio-net,netdev=internet -n) by 
/usr/bin/qemu-system-x86_64[bash:9140] uid/euid:1000/1000 gid/egid:1000/1000, 
parent /bin/bash[bash:7730] uid/euid:1000/1000 gid/egid:1000/1000
Oct 16 05:02:12 g0n kernel: [169135.508108] grsec: 
(miro:U:/usr/libexec/qemu-bridge-helper) exec of 
/usr/libexec/qemu-bridge-helper (/usr/libexec/qemu-bridge-helper --use-vnet 
--fd=14 --br=br0 ) by /usr/libexec/qemu-bridge-helper[qemu-system-x86:9142] 
uid/euid:1000/1000 gid/egid:1000/1000, parent 
/usr/bin/qemu-system-x86_64[qemu-system-x86:9140] uid/euid:1000/1000 
gid/egid:1000/1000
Oct 16 05:02:12 g0n kernel: [169135.510897] br0: port 2(tap0) entered blocking 
state
Oct 16 05:02:12 g0n kernel: [169135.510901] br0: port 2(tap0) entered disabled 
state
Oct 16 05:02:12 g0n kernel: [169135.510971] device tap0 entered promiscuous mode
Oct 16 05:02:12 g0n kernel: [169135.511357] br0: port 2(tap0) entered blocking 
state
Oct 16 05:02:12 g0n kernel: [169135.511370] br0: port 2(tap0) entered 
forwarding state
Oct 16 05:02:12 g0n kernel: [169135.512008] grsec: (:::kernelS:/) exec of 
/bin/kmod (/sbin/modprobe -q -- net-pf-16-proto-16-family-nl80211 ) by 
/bin/kmod[kworker/u8:3:9145] uid/euid:0/0 gid/egid:0/0, parent 
/[kworker/u8:3:9107] uid/euid:0/0 gid/egid:0/0
Oct 16 05:02:12 g0n kernel: [169135.512085] grsec: (root:U:/) exec of 
/lib64/udev/net.sh (/lib/udev/net.sh tap0 start ) by 
/lib64/udev/net.sh[udevd:9144] uid/euid:0/0 gid/egid:0/0, parent 
/sbin/udevd[udevd:9143] uid/euid:0/0 gid/egid:0/0
Oct 16 05:02:12 g0n kernel: [169135.515087] grsec: 
(root:U:/lib64/dhcpcd/dhcpcd-run-hooks) exec of /lib64/dhcpcd/dhcpcd-run-hooks 
(/lib/dhcpcd/dhcpcd-run-hooks ) by /lib64/dhcpcd/dhcpcd-run-hooks[dhcpcd:9147] 
uid/euid:0/0 gid/egid:0/0, parent /sbin/dhcpcd[dhcpcd:7442] uid/euid:0/0 
gid/egid:0/0
Oct 16 05:02:12 g0n kernel: [169135.522691] grsec: 
(root:U:/lib64/dhcpcd/dhcpcd-run-hooks) exec of /lib64/dhcpcd/dhcpcd-run-hooks 
(/lib/dhcpcd/dhcpcd-run-hooks ) by /lib64/dhcpcd/dhcpcd-run-hooks[dhcpcd:9149] 
uid/euid:0/0 gid/egid:0/0, parent /sbin/dhcpcd[dhcpcd:7442] uid/euid:0/0 
gid/egid:0/0
Oct 16 05:02:12 g0n dhcpcd[7442]: tap0: IAID 84:04:7b:14
Oct 16 05:02:12 g0n dhcpcd[7442]: tap0: carrier lost

Esp. from the screencast at:

http://localhost/CroatiaFidelis/foss/cap/cap-161015-qemu-devuan/Screen_161016_0501_g0n.webm
 

it is clear qemu still wants to use eth0.

Regards! (really tired, I may be having just a little strength to
possibly try a little more to achive the proposed goal... today,
hopefully)
-- 
Miroslav Rovis
Zagreb, Croatia
http://www.CroatiaFidelis.hr


signature.asc
Description: Digital signature


Re: [Qemu-discuss] How to set the network card for qemu to use?

2016-10-15 Thread Miroslav Rovis
On 161015-21:05+0300, Aleksei wrote:
> > $ qemu-system-x86_64 -cpu host -display gtk -m 1024M  
> > devuan_jessie_1.0.0-beta_amd64_cloud.qcow2
> > qemu-system-x86_64: CPU model 'host' requires KVM
> 
> Did you try adding "-machine type=q35,accel=kvm -enable-kvm" to 
> arguments? You can also do "pc" instead of "q35".
Thanks! That actually worked :-) !  

This command I issued:

$ qemu-system-x86_64 -machine type=q35,accel=kvm -enable-kvm \
-cpu host -display gtk -m 1024M \
devuan_jessie_1.0.0-beta_amd64_cloud.qcow2

And it booted!

> For this to work you need kvm modules installed and loaded - from your 
> config I'm guessing you have AMD CPU, so that would be:
> # modprobe kvm
> # modprobe kvm_amd
> You have them with "y" in your config (I have "m"), so modprobe part may 
> be unnecessary.
Thanks, Aleksei, for this other tip, but that one wouldn't/couldn't work
(not literally applied like the above which did so).
Namely, I have a no-modules all-built-in system.

> /--Regards, Aleksei/

Really great! I'm happy for this. You brought some joy into this day of
mine!
-- 
Miroslav Rovis
Zagreb, Croatia
http://www.CroatiaFidelis.hr


signature.asc
Description: Digital signature


Re: [Qemu-discuss] How to set the network card for qemu to use?

2016-10-13 Thread Miroslav Rovis
On 161013-20:56+0200, Miroslav Rovis wrote:
...

> > > Either for pass-through (the default, the SLIRP, IIUC), or I had
> > > previously tried to set a tap0 device to a host br0, but couldn't get
> > > qemu to set the image it boots to use one of a few NIC cards.
> > >
> > > Concrete setup is three NIC cards:
> > > eth0
> > > eth1
> > > eth2
> > >
> > > And the question is simple: what -netdev options (or is there some other
> > > way?) do I use to get qemu to use eth2?

I think I should try and maybe get the NIC that I connect to internet
with to get the name eth0 instead of the above.

So here below is my quest.
---

I think I should try and get my eth0 eth1 eth2 NICs renamed somehow, so that
the eth2 (the one I connect to the internet with) become eth0 and the other
two, may they get whichever, less important (if it keep consisten over
reboots).

I have found this im my local kernel, and sure it's online as well:

https://www.kernel.org/doc/Documentation/kernel-parameters.txt

This is actual setup, automatic and consistent on every reboot, by the kernel
(where I have parameter "net.ifnames=0" witout quotes in kernel command line):

# lspci | tail -4 | head -3
04:06.0 Ethernet controller: Realtek Semiconductor Co., Ltd. 
RTL-8100/8101L/8139 PCI Fast Ethernet Adapter (rev 10)
05:00.0 Ethernet controller: Marvell Technology Group Ltd. 88E8053 PCI-E 
Gigabit Ethernet Controller (rev 19)
06:00.0 Ethernet controller: Marvell Technology Group Ltd. 88E8053 PCI-E 
Gigabit Ethernet Controller (rev 19)
# lspci -n | tail -4 | head -3
04:06.0 0200: 10ec:8139 (rev 10)
05:00.0 0200: 11ab:4362 (rev 19)
06:00.0 0200: 11ab:4362 (rev 19)
# 

Looking up the /var/log/messages, I can see this is how they get their names
set:

Sep 30 03:31:03 g0n syslog-ng[2634]: syslog-ng starting up; version='3.4.8'
Sep 30 03:31:03  kernel: [0.00] Linux version 4.7.5-hardened-160929 
(root@g5n) (gcc version 5.4.0 (Gentoo Hardened 5.4.0 p1.0, pie-0.6.5) ) #1 SMP 
PREEMPT Thu Sep 29 17:16:42 CEST 2016
Sep 30 03:31:03 g0n kernel: [0.00] Command line: 
BOOT_IMAGE=/vmlinuz-4.7.5-hardened-160929 root=/dev/mapper/root ro net.ifnames=0

...[119 lines cut]...

Sep 30 03:31:03 g0n kernel: [0.00] Kernel command line: 
BOOT_IMAGE=/vmlinuz-4.7.5-hardened-160929 root=/dev/mapper/root ro net.ifnames=0
Sep 30 03:31:03 g0n kernel: [0.00] PID hash table entries: 4096 (order: 
3, 32768 bytes)

...[ 64 lines cut]...

Sep 30 03:31:03 g0n kernel: [0.391974] NET: Registered protocol family 16
Sep 30 03:31:03 g0n kernel: [0.395753] cpuidle: using governor ladder
Sep 30 03:31:03 g0n kernel: [0.399724] cpuidle: using governor menu
Sep 30 03:31:03 g0n kernel: [0.399848] node 0 link 0: io port [a000, ]
Sep 30 03:31:03 g0n kernel: [0.399850] TOM: e000 aka 3584M
Sep 30 03:31:03 g0n kernel: [0.399939] Fam 10h mmconf [mem 
0xe000-0xefff]

...[  5 lines cut]...

Sep 30 03:31:03 g0n kernel: [0.400099] ACPI: bus type PCI registered
Sep 30 03:31:03 g0n kernel: [0.400246] PCI: MMCONFIG for domain  [bus 
00-ff] at [mem 0xe000-0xefff] (base 0xe000)
Sep 30 03:31:03 g0n kernel: [0.400394] PCI: not using MMCONFIG
Sep 30 03:31:03 g0n kernel: [0.400481] PCI: Using configuration type 1 for 
base access
Sep 30 03:31:03 g0n kernel: [0.400569] PCI: Using configuration type 1 for 
extended access

...[  27 lines cut]...

Sep 30 03:31:03 g0n kernel: [0.529304] PCI host bridge to bus :00

...[ 117 lines cut]...

Sep 30 03:31:03 g0n kernel: [0.540520] pci :04:06.0: [10ec:8139] type 
00 class 0x02
Sep 30 03:31:03 g0n kernel: [0.540537] pci :04:06.0: reg 0x10: [io  
0xd000-0xd0ff]
Sep 30 03:31:03 g0n kernel: [0.540547] pci :04:06.0: reg 0x14: [mem 
0xfe01-0xfe0100ff]
Sep 30 03:31:03 g0n kernel: [0.540590] pci :04:06.0: reg 0x30: [mem 
0xfe00-0xfe00 pref]
Sep 30 03:31:03 g0n kernel: [0.540620] pci :04:06.0: supports D1 D2
Sep 30 03:31:03 g0n kernel: [0.540622] pci :04:06.0: PME# supported 
from D1 D2 D3hot D3cold

...[  10 lines cut]...

Sep 30 03:31:03 g0n kernel: [0.540878] pci :05:00.0: [11ab:4362] type 
00 class 0x02
Sep 30 03:31:03 g0n kernel: [0.540901] pci :05:00.0: reg 0x10: [mem 
0xfe32-0xfe323fff 64bit]
Sep 30 03:31:03 g0n kernel: [0.540912] pci :05:00.0: reg 0x18: [io  
0xc000-0xc0ff]
Sep 30 03:31:03 g0n kernel: [0.540951] pci :05:00.0: reg 0x30: [mem 
0xfe30-0xfe31 pref]
Sep 30 03:31:03 g0n kernel: [0.541012] pci :05:00.0: supports D1 D2
Sep 30 03:31:03 g0n kernel: [0.541013] pci :05:00.0: PME# supported 
from D0 D1 D2 D3hot D3cold
Sep 30 03:31:03 g0n kernel: [0.541074] pci :05:00.0: disabling ASPM on 
pre-1.1 PCIe device.  You can enable it with 'pcie_aspm=force'
Sep 30 03:31:03 g0n kernel: [0.541227] pci :00:15.0: PCI bridge to [bus 
05]
Sep 30 03:31:03 g0n kernel: [0.541345] pci :00:15.0:   bridge window 

Re: [Qemu-discuss] How to set the network card for qemu to use?

2016-10-13 Thread Miroslav Rovis
Hi, Aleksei!

I like the conversation style instead of top posting (if you don't mind
;-) . Less typing, and much clearer the line of discussion.

On 161013-10:11+0300, Aleksei wrote:
> Hi,
> 
> If you want VM to use host's physical NIC exclusively, then do a PCI 
> pass-through.
I had already figured that...

And I also figured that the bridging would bring me, just what you write:
> If you just want VM to be on the same network as one of the NIC's, then 
> do the bridging. Create a bridge on the host, make that NIC a slave, 
> specify that bridge in Qemu command line. See here for details: 
> https://wiki.archlinux.org/index.php/QEMU#Bridged_networking_using_qemu-bridge-helper
>  
> and https://wiki.archlinux.org/index.php/Network_bridge
I had also visited, previously, these and many other pages about Qemu.

But my problem is that the way my network cards in my Gentoo machine,
which sometimes functions as router for local network, are configured,
and its how their naming "naturally" comes up consistently after every
boot, [the way my network cards in my Gentoo machine] is:
eth0 -- local network [when used]
eth1 -- local network [when used]
eth2 -- connection to broadband router

And my problem is, I can't firure out the way to get qemu to try and get
either the passthrough or the bridging slave, via any other than:
eth0
(which, of course, fails).

> 
> /--Regards, Aleksei/

Thanks for offering your help!

So, basically I'm studying further... And will be thankful if anybody
has any pointers to where to look for the solution...

The below is, more or less, in the same line as what I restated today...

> > Either for pass-through (the default, the SLIRP, IIUC), or I had
> > previously tried to set a tap0 device to a host br0, but couldn't get
> > qemu to set the image it boots to use one of a few NIC cards.
> >
> > Concrete setup is three NIC cards:
> > eth0
> > eth1
> > eth2
> >
> > And the question is simple: what -netdev options (or is there some other
> > way?) do I use to get qemu to use eth2?

See this:
> > Because it invariably chooses eth0.
> >
> > I tried several images, such as Tails and Devuan. Always chooses: eth0.
That above is the crux of the matter.

Studying:
http://qemu.weilnetz.de/qemu-doc.html
where find this line:
-netdev 
tap,id=id[,fd=h][,ifname=name][,script=file][,downscript=dfile][,helper=helper]

(it is one line, just greater than 79 char, so broken)

I thought maybe the solution would be somewhere in those, if I set a tap device 
and enslave it to eth2 enslaved to bridge (the bridge I was previously able to 
create, and it worked, but only for eth2)  ... But how do I get a file 
decriptor of eth2 ?

Thanks if anybody gives more help on this!
-- 
Miroslav Rovis
Zagreb, Croatia
http://www.CroatiaFidelis.hr


signature.asc
Description: Digital signature