On Mon, Dec 8, 2014 at 3:00 PM, Dmitry Antipov <dmanti...@yandex.ru> wrote:
> (This is a partial repost from qemu-discuss@ list since I'm suspecting a
> bug)
>
> I'm using QEMU 2.1.1 to emulate SPARC system and have vde network between
> two
> VMs and host system, organized as shown:
>
> host
> tap0
> + 192.168.100.254 +
> | |
> | |
> vm0 vm1
> eth0 eth0
> 192.168.100.1 --- 192.168.100.2
>
> On host, I'm running vde_switch and extra stuff as:
>
> vde_switch -tap tap0 -daemon -mod 660 -group [group]
> ip addr add 192.168.100.254/24 dev tap0
> ip link set tap0 up
> echo 1 > /proc/sys/net/ipv4/ip_forward
> iptables -t nat -A POSTROUTING -s 192.168.100.0/24 -o [external network
> iface] -j MASQUERADE
>
> VMs are running with:
>
> qemu-system-sparc -m 256 -net nic -net vde -hda vm0.img
> qemu-system-sparc -m 256 -net nic -net vde -hda vm1.img
>
> Everything looks good, but...
>
> ...the problem: I need to build redundant network by using the same method,
> i.e.
> improve the network shown above with:
If you care about reliability, be aware that VDE is a seldomly used
feature. There are probably more bugs lurking there than the popular
tap networking code path.
>
> host
> tap1
> + 192.168.101.254 +
> | |
> | |
> vm0 vm1
> eth1 eth1
> 192.168.101.1 --- 192.168.101.2
>
> I'm trying to run two vde switches:
>
> vde_switch -sock /tmp/vde0 -tap tap0 -daemon -mod 660 -group [group]
> vde_switch -sock /tmp/vde1 -tap tap1 -daemon -mod 660 -group [group]
>
> and run VMs with:
>
> qemu-system-sparc -m 256 -net nic,vlan=0 -net vde,sock=/tmp/vde0,vlan=0 -net
> nic,vlan=1 -net vde,sock=/tmp/vde1,vlan=1 -hda vm0.img
Try:
qemu-system-sparc -m 256 \
-netdev vde,sock=/tmp/vde0,id=vde0 \
-device ne2k_pci,netdev=vde0 \
-netdev vde,sock=/tmp/vde1,id=vde1 \
-device ne2k_pci,netdev=vde1 \
-hda vm0.img
The is the newer syntax and it should work better.
> but the result is:
>
> Warning: hub port hub1port0 has no peer
> Warning: vlan 1 with no nics
> Warning: netdev hub1port0 has no peer
> Warning: requested NIC (anonymous, model unspecified) was not created (not
> supported by this machine?)
>
> Is this a bug?
Yes, this looks like a bug in the legacy -net option code.
Stefan
