Open Stack

Hi Narayan, 
thanks for your feedback, It took me hours to figure out, 
but thanks to vish, we found out that my fixed_ips tables had a lot of unused IP (with a project_id=NULL)
Thus, the nova-br50.conf (for my vlan50) was empty ; after a quick 'delete from fixed_ips where project_id=NULL' i've been able to run a new network, with it's own VLAN.
So, to your precious advices , I add : 
- Are there fixed_ips that are not linked to a project ; if so, 'delete from fixed_ips where project_id=NULL'
- Does a file called nova-br$VLAN-ID.conf is populated with the leases ?
- Check iptables rules (especially the rule for DHCP requests)

Razique

Le 6 nov. 2011 à 20:00, Narayan Desai a écrit :

> 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
>> 
>>