[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-discuss] Multiple VM's on Multiple VLANS

From: Mike Lovell
Subject: Re: [Qemu-discuss] Multiple VM's on Multiple VLANS
Date: Mon, 05 Nov 2012 12:02:47 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121028 Thunderbird/16.0.2

On 11/01/2012 06:03 AM, Brian Doyle wrote:
Your assumptions where correct i was using the vlan= settings with in the qemu command. I have setup the true vlan's and bridged my taps to them. With doing it this way do I need to use iptables to ensure that network traffic "flows" correctly? I ask this becuase if I take out the vlan= settin gfrom the qemu command I do not seem to have the connectivity that I am looking for? Here is my qemu-ifup script. There is a good chance my bridges are not configured correctly.

I run this script with: qemu-ifup tap0 tap1 tap2 tap3 tap4

i think you are getting closer. i think your script should connect the various interfaces. have you checked to make sure that the vms on each network can talk to each other? i.e. can vm1 and vm2 communicate between their 172.16.0.# addresses? can vm2 and vm3 communicate over their 10.0.0.# addresses? can the host communicate with the vms on the proper interfaces?

if the vms can talk to their local neighbor, then you need to configure routing between the networks. there are a couple ways you could do this and will vary based on what you are trying to accomplish. if you are wanting a quick and easy way for vm3 to talk to the 'real world,' then you could configure vm2 to act as a simple NAT router. there are many tutorials on the internet about how to do that but the basics are to allow ip forwarding in the kernel and adding an iptables MASQUERADE rule. `sysctl -w net.ipv4.ip_forward = ` can set ip forwarding and the iptables rule will probably be something like `iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE` where eth0 is the 172.16.0.# interface.

there are other ways to configure the networking but those topics get outside of the scope of qemu.

if the vms can not talk to their local neighbor, then the network devices probably are not getting configured properly and that needs additional troubleshooting.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]