Open Stack

This looks more or less right. We have been running a setup like you
are describing here for quite a while, and we've found it to be stable
(and easier to setup than a lot of the other network options, IMO).

When debugging this sort of setup, trunking setup problems on the
switch are often the culprit. Here is a list of things to verify after
firing up an instance on each project network:
on the nova-network server:
 - is there a vlanX for each project vlan
 - is the brXX interface configured with the appropriate gateway
address for the project network
 - is the bridging setup properly (ie does vlanXX belong to bridge brXX)
 - is there a dnsmasq process running for each project network (it
will be a pair of processes, iirc)

on the nova-compute node:
 - is there a vlanX interface for each project vlan that has an
instance on the local machine?
 - brXX should have no ip address settings
 - is vlanXX connected to brXX?
 - is vnetX connected to brXX?

Another thing to check is if the instance is getting an ip address
from dhcp or not.

If you suspect trunking setup problems, you can add an ip address on
the project network to brXX on the nova-compute node, and try pinging
the .1 gateway address. If that doesn't work, your trunking setup is
broken. Make sure that the vlan is setup tagged on the switch port the
compute node is attached to, and that it is also passed upstream
properly in your network.

You should also check your nova-network logs.

Hope this helps.
 -nld

On Sat, Nov 5, 2011 at 7:27 PM, Razique Mahroua
<razique.mahroua at gmail.com> wrote:
> Hi all,
> I'm trying to create an advanced architecture with Nova, that uses several
> projects per user, and multiple networks (one network per project)
> The networks have their own vlan :
> id   IPv4               IPv6           start address   DNS1           DNS2
>         VlanID         project         uuid
> 12   192.168.2.0/24     None           192.168.2.3     None           None
>         100             first_project   None
> 13   192.168.3.0/27     None           192.168.3.3     None           None
>         50             another_project None
> It looks like while the first project runs wells (creates instances have
> connectivity and can be reached), while the instances created via the second
> project are unreacheable.
> Both have the right SG rules, and both networks create the rights VLANS :
> # /proc/net/vlan/config
> VLAN Dev name | VLAN ID
> Name-Type: VLAN_NAME_TYPE_PLUS_VID_NO_PAD
> vlan100        | 100  | eth0
> vlan50         | 50  | eth0
> # brctl show
> br100 8000.02163e137a78 no vlan100
> br50 8000.02163e447ed8 no vlan50
> # ip route sh
> 192.168.3.0/27 dev br50  proto kernel  scope link  src 192.168.3.1
> 192.168.2.0/24 dev br100  proto kernel  scope link  src 192.168.2.1
>
> - Can I have several VLANS per physical interface ?
> - Do I need to create everytime a new project, or can I create all my
> networks and link them to the same project, but be able to specify which
> network to use everytime I spawn a new instance ?
> - Is it possible to allow some communication between the VLANS (for
> instance, hosts into the VLAN 50 should only be able to contact hosts into
> VLAN100 on port 443) ? Does the security groups can manage per VLAN rules ?
> Thanks, i'm a bit desperate here :)
>
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack at lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>
>