You are not logged in.
I'm facing networking issues with qemu-kvm.
I'm trying to give a virtual machine direct access to a physical ethernet card using a bridge.
I'm running this script:
#!/bin/sh
export WAN=enp1s0
ip tuntap add tap0 mode tap user virtuser group virtuser
brctl addbr br0
brctl addif br0 tap0
brctl addif br0 ${WAN}
brctl setfd br0 9
brctl sethello br0 2
brctl setmaxage br0 12
brctl stp br0 off
ip link set dev ${WAN} up
ip link set dev br0 up
ip link set dev tap0 up
iptables -I FORWARD -m physdev --physdev-is-bridge -j ACCEPT
ip addr change 0.0.0.0 dev tap0
ip addr change 0.0.0.0 dev ${WAN}
then starting the qemu machine under the user virtuser
qemu-system-x86_64 -enable-kvm -hda testma.img -m 2048 -k en-us -usbdevice tablet -net nic,model=virtio,vlan=0 -net tap,vlan=0,ifname=tap0,script=no,downscript=no -curses
When I try to get an ip with dhcp from within the virtual machine it isn't working, I'm getting nothing.
I've made sure that the hardware is ok, if I try to get an ip with enp1s0 or br0 I'm getting it and I have access to the internet.
After trying a few methods for the last few days (vde switch, macvtap, traffic forwarding with iptables) and failing to make all of them work I think I need help.
Last edited by Yochai (2013-06-05 13:20:16)
Offline
The bridge needs an ip address.
Try executing this after you've brought br0 up:
dhcpcd br0
"...one cannot be angry when one looks at a penguin." - John Ruskin
"Life in general is a bit shit, and so too is the internet. And that's all there is." - scepticisle
Offline
IMO, the the -net bridge method is the simplest way to get bridged networking in a qemu VM.
But whether the Constitution really be one thing, or another, this much is certain - that it has either authorized such a government as we have had, or has been powerless to prevent it. In either case, it is unfit to exist.
-Lysander Spooner
Offline
Running dhcpcd br0 just gave br0 an ip address (and access to the out side world), it did nothing for the virtual machine.
Trying to use the -net bridge method didn't work. To do that I added the br0 bridge configuration to netctl, added 'allow br0' in /etc/qemu/bridge.conf and called my virtual machine as shown in the wiki. it said "Device 'bridge' could not be initialized". tried to point it at the direct location of the bridge helper, no go.
Offline
Running dhcpcd br0 just gave br0 an ip address (and access to the out side world), it did nothing for the virtual machine.
As far as I understand it, the bridge needs to see the outside world for the tap device to, so the vm can see it. At least that's how I set it up. It took me ages to get my set-up working consistently though, so there may have been some settings that were unnecessary. I'm not risking breaking them again though, at the moment as it's a work machine.
Can't see what else you're missing, sorry.
"...one cannot be angry when one looks at a penguin." - John Ruskin
"Life in general is a bit shit, and so too is the internet. And that's all there is." - scepticisle
Offline
Would you mind posting the command you used that resulted in the "Device 'bridge' could not be initialized" error? Also, what is the bridge helper you're talking about?
But whether the Constitution really be one thing, or another, this much is certain - that it has either authorized such a government as we have had, or has been powerless to prevent it. In either case, it is unfit to exist.
-Lysander Spooner
Offline
That resulted in "Device 'bridge' could not be initialized':
qemu-system-x86_64 -enable-kvm -hda testma.img -m 2048 -k en-us -usbdevice tablet -net nic,vlan=0 -net bridge,vlan=0,br=0 -curses
as for the helper I tried, /usr/lib/qemu/qemu-bridge-helper
Offline
After playing with the permissions on /usr/lib/qemu/qemu-bridge-helper and /etc/qemu/bridge.conf it managed to create the tap connection to the bridge automatically. Sadly, it didn't allow me to connect through the VM yet.
I gave up and I'm using forwarding with iptables and VDE
Offline
If then NIC 'looks right' in the VM (correct MAC, correct driver, no errors in journal, etc.) then I would suspect a firewall issue. I don't know anything about iptables or firewalls in general, but I think you'd still need to do
iptables -I FORWARD -m physdev --physdev-is-bridge -j ACCEPT
(or something similar)
But whether the Constitution really be one thing, or another, this much is certain - that it has either authorized such a government as we have had, or has been powerless to prevent it. In either case, it is unfit to exist.
-Lysander Spooner
Offline
I tried that, I can forward on the other NIC (that go into the network).
Some documentation on-line said it's possible the ISP blocks connection this type of connection as they can see the routing (the DHCP tries to pull the IP from them). I don't know enough about networking to know if it's possible or not but it seem like an option as I can find no other issue.
Offline
I think the standard NIC (rtl8139) driver does not provide support for vlan, try using something else, for eg. -net nic,model=virtio
And what were the changes you have made on file permissions, because i have similar problem, i cant connect my guest to the bridge br0.
My net part for qemu is:
-net nic,model=virtio,vlan=0,macaddr=DE:AD:BE:EF:23:77 \
-net bridge,vlan=0,br=0 \
and here's my output error:
access denied by acl file
failed to launch bridge helper
qemu-system-x86_64: -net bridge,vlan=0,br=0: Device 'bridge' could not be initialized
I am using gentoo and qemu 1.4.1
Last edited by radzior (2013-06-07 09:00:53)
Offline
radzior, these forums are for Arch support only. That said, the error suggests you need to look into your acl configuration. Just Google 'linux acl' if you don't know what acl is.. that's what I did.
But whether the Constitution really be one thing, or another, this much is certain - that it has either authorized such a government as we have had, or has been powerless to prevent it. In either case, it is unfit to exist.
-Lysander Spooner
Offline