from:"Aaron Rosen"

Re: [Openstack] Call to API very slow [Grizzly]

2013-07-26 Thread Aaron Rosen

This is slower now because of the quantum metadata agent. In Essex when a
vm did a request for 169.254.169.254 the request would go straight to the
nova-metadata server and nova would determine which metadata to return
based on the instances source ip. With quantum you are allowed to have
overlapping ip addresses so this method does not work anymore. In order for
metadata to work with overlapping ip addresses the quantum metadata agent
intercepts the request and inserts a special header so that nova-metadata
can determine which instance this request belongs to (since ips can
overlap).  In order for the quantum metadata agent to determine which
header values to insert he needs to query quantum to determine the
device_id of the instance that made the request (which is an extra query).
My guess is this coupled with proxying the data is is why you are seeing an
extra second or so.  Is this presenting a problem for you? If you don't
want to allow overlapping ips you can disable that in quantum and still use
nova-metadata directly.

Thanks,

Aaron


On Thu, Jul 25, 2013 at 8:19 PM, Chu Duc Minh  wrote:

>
> On Thu, Jul 25, 2013 at 7:30 PM, Jay Pipes  wrote:
>
>> You will need to provide more details than "old" vs. "new" OpenStack.
>>
>> For example...
>>
>> 1) What is your network model in the old vs. new
>>
> Old: nova-network + FlatDHCP
> New: Quantum + OpenvSwitch + network-namespace + metadata-ns-proxy
>
> 2) What version of OpenStack is the old
>>
> Old: Essex
> New: Grizzly
>
> 3) Is Keystone used in old and new? If so, what drivers are used in
>> Keystone?
>>
> Yes, both use Keystone with SQL backend
>
> 4) Do you have errors in any of your log files (usually an indication that
>> something like a timeout or failure on
>
> RPC which may affect performance)
>>
> No, i didn't found it.
>
>
>> 5) Are you using nova-conductor in the new?
>>
> I have nova-conductor process run on Controller node, but seem
> nova-compute don't use this.
>
>
>> 6) What database backend are you using?
>>
> MySQL.
>
>
>> 7) Do a time keystone user-list on both old and new
>>
> # keystone user-list
> Old:
> Run 1st time:
> real*0m2.494s*
> user0m0.112s
> sys 0m0.040s
> 2nd time:
> real*0m0.279s*
> user0m0.112s
> sys 0m0.020s
>
>
> New:
> Run 1st time:
> real*0m1.687s*
> user0m0.176s
> sys 0m0.012s
> 2nd time:
> real*0m0.213s*
> user0m0.160s
> sys 0m0.040s
>
>
> 8) Pastebin your conf files, with passwords removed
>>
> My config files are quite large.
> I can sum up that all services & API are HA-ed using HAproxy, RabbitMQ
> Cluster, Database replication, v.v...
>
> This morning, i just do some tuning memcached for Dashboard service (HA-ed
> using HAProxy), then my Dashboard become faster significantly.
>
> The questions remain are:
> 1. Why metadata query so slow? Possible problems? ( "curl
> http://169.254.169.254/openstack"; took 2.5-5 seconds to complete,
> "ec2metadata" took 14-17 seconds to complete - i tested many times.)
> 2. Why API calls using *-client reduce time from 2nd time on my old Essex
> deployment, but not on my new Grizzly deployment? Maybe I need some "cache"
> settings?
>
> Thank you very much!
>
>
>> The more information you give, the better folks can help you.
>>
>> Best,
>> -jay
>>
>>
>> On 07/25/2013 07:14 AM, Chu Duc Minh wrote:
>>
>>> Check some more API (I run these command below from Controller node):
>>> # time quantum subnet-list
>>> (...have 4 subnet)
>>> real0m0.676s
>>> user0m0.196s
>>> sys 0m0.020s
>>>
>>> # time quantum router-list
>>> (...have 1 router)
>>> real0m0.496s
>>> user0m0.164s
>>> sys 0m0.052s
>>>
>>> # time nova list --all_tenants=1
>>> (...have 5 instances)
>>> real0m1.290s
>>> user0m0.308s
>>> sys 0m0.040s
>>>
>>> Compare with my old OpenStack deployment on weaker servers, it took 1/3
>>> in times.
>>>
>>>
>>>
>>> On Thu, Jul 25, 2013 at 5:43 PM, Peter Cheung >> **> wrote:
>>>
>>> I am having a problem about calling API speed is up and down,
>>> something need 0.1s, something it needs 3s
>>>
>>> Thanks
>>> from Peter
>>>
>>>
>>> --**--**
>>> 
>>>
>>> Date: Thu, 25 Jul 2013 17:41:11 +0700
>>> From: chu.ducm...@gmail.com 
>>> To: openstack@lists.launchpad.net
>>> >> >;
>>> openst...@lists.openstack.org >> openstack.org >
>>>
>>> Subject: [Openstack] Call to API very slow [Grizzly]
>>>
>>>
>>> All operations in my Openstack dashboard very slow (compare to my
>>> old Openstack deployment)
>>> Then i do some check on an instance:
>>>
>>> $ time curl 
>>> http://169.254.169.254/**openstack
>>> 2012-08-10
>>> 2013-04-04
>>> latest
>>> real0m*5.605s*
>>>
>>> user0m0.004s
>>> sys0m0.004s
>

Re: [Openstack] Tenant list

2013-07-25 Thread Aaron Rosen

nova  --os-tenant-name  

Aaron


On Thu, Jul 25, 2013 at 9:06 PM, Remo Mattei  wrote:

> Nell'ospedale what is the best way to list all instance of a tenant
> without having to ask for their password if I am the admin so I can check
> if there is ny problems with an instance
>
> Thanks
> ___
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] Grizzly GRE tunneling network set up problems

2013-07-10 Thread Aaron Rosen

You should follow the instructions here:
http://git.openvswitch.org/cgi-bin/gitweb.cgi?p=openvswitch;a=blob;f=INSTALL;h=5589fe7dd7203308bbec27a562cb9899d218577a;hb=a4fff9cc390b69bde1257b414212505a72c4b450


On Wed, Jul 10, 2013 at 10:27 AM, Haitao Jiang wrote:

> Aaron
>
> I followed instructions in
> http://n40lab.wordpress.com/2013/06/03/centos-6-4-openvswitch-installation/
> on my compute node as a test. Restarted OVS, but still see the same
> error in the ovs-vswitchd.log. This is what I have
>
> kmod-openvswitch.x86_64  1.10.0-1.el6
>  @/kmod-openvswitch-1.10.0-1.el6.x86_64
> openstack-quantum-openvswitch.noarch2013.1.2-1.el6
> @openstack-grizzly
> openvswitch.x86_641.10.0-1.el6
>   @openstack-grizzly
>
> filename:
>
> /lib/modules/2.6.32-358.111.1.openstack.el6.x86_64/extra/openvswitch/openvswitch.ko
> version:1.10.0
> license:GPL
> description:Open vSwitch switching datapath
> srcversion: 480D55A9BB0E8B000E32010
> depends:
> vermagic:   2.6.32-358.111.1.openstack.el6.x86_64 SMP mod_unload
> modversions
> parm:   vlan_tso:Enable TSO for VLAN packets (int)
>
> # find / -name openvswitch.ko | xargs ls -l
> -rw-r--r-- 1 ovswitch ovswitch 4948350 Jul  9 21:41
>
> /home/ovswitch/rpmbuild/BUILD/openvswitch-1.10.0/_default/datapath/linux/openvswitch.ko
> -rw-r--r-- 1 root root 4948350 Jul  9 21:41
>
> /lib/modules/2.6.32-358.111.1.openstack.el6.x86_64/extra/openvswitch/openvswitch.ko
> -rwxr--r-- 1 root root   77936 Jun 12 20:19
>
> /lib/modules/2.6.32-358.111.1.openstack.el6.x86_64/kernel/net/openvswitch/openvswitch.ko
> -rwxr--r-- 1 root root   72912 Jun 12 04:36
>
> /lib/modules/2.6.32-358.11.1.el6.x86_64/kernel/net/openvswitch/openvswitch.ko
> lrwxrwxrwx 1 root root  83 Jul  9 21:42
>
> /lib/modules/2.6.32-358.11.1.el6.x86_64/weak-updates/openvswitch/openvswitch.ko
> ->
> /lib/modules/2.6.32-358.111.1.openstack.el6.x86_64/extra/openvswitch/openvswitch.ko
>
> anything else I need to check? Does above looks right to you?
>
> Thanks
>
> Haitao
>
> On Tue, Jul 9, 2013 at 10:29 PM, Aaron Rosen  wrote:
> > You should be able to compile openvswitch from source here :
> > http://openvswitch.org/download/ and then you'll get tunnel support.
> >
> > Aaron
> >
> >
> > On Tue, Jul 9, 2013 at 10:21 PM, Haitao Jiang 
> wrote:
> >>
> >> Aaron & Chandler
> >>
> >> Thanks a lot for the help. I should have mentioned that the host OS is
> >> CentOS 6.4 (specifically the kernel from RedHat RDO). I googled and
> >> found that it may not have gre tunneling support. Is there anyone who
> >> has successfully set up gre with RDO's kernel or it is just can not be
> >> done and I should use the VLAN.
> >>
> >> As Aaron suspected, there are errprs in the OVS agent log:
> >>
> >> system@ovs-system: failed to add gre-3 as port: Address family not
> >> supported by protocol
> >>
> >> More details below
> >>
> >> Any pointer will be highly appreciated!
> >>
> >> Haitao
> >> ==
> >> Here are some outputs on my compute node (.46, .42 is the control node
> >> and .44 is the network node):
> >>
> >>
> >> # ovs-vsctl show
> >> 1d554b19-2a2b-493d-a123-0efb0aabc7d1
> >> Bridge br-int
> >> Port br-int
> >> Interface br-int
> >> type: internal
> >> Port "qvo8108425f-ef"
> >> tag: 1
> >> Interface "qvo8108425f-ef"
> >> Port patch-tun
> >> Interface patch-tun
> >> type: patch
> >> options: {peer=patch-int}
> >> Bridge br-tun
> >> Port br-tun
> >> Interface br-tun
> >> type: internal
> >> Port "gre-3"
> >> Interface "gre-3"
> >> type: gre
> >> options: {in_key=flow, out_key=flow,
> >> remote_ip="10.18.250.44"}
> >> Port "gre-4"
> >> Interface "gre-4"
> >> type: gre
> >> options: {in_key=flow, out_key=flow,
> >> remote_ip="10.18.250.42"}
> >> Port patch-int
> >> Interface patch-int
> >>

Re: [Openstack] Grizzly GRE tunneling network set up problems

2013-07-09 Thread Aaron Rosen

You should be able to compile openvswitch from source here :
http://openvswitch.org/download/ and then you'll get tunnel support.

Aaron


On Tue, Jul 9, 2013 at 10:21 PM, Haitao Jiang  wrote:

> Aaron & Chandler
>
> Thanks a lot for the help. I should have mentioned that the host OS is
> CentOS 6.4 (specifically the kernel from RedHat RDO). I googled and
> found that it may not have gre tunneling support. Is there anyone who
> has successfully set up gre with RDO's kernel or it is just can not be
> done and I should use the VLAN.
>
> As Aaron suspected, there are errprs in the OVS agent log:
>
> system@ovs-system: failed to add gre-3 as port: Address family not
> supported by protocol
>
> More details below
>
> Any pointer will be highly appreciated!
>
> Haitao
> ==
> Here are some outputs on my compute node (.46, .42 is the control node
> and .44 is the network node):
>
>
> # ovs-vsctl show
> 1d554b19-2a2b-493d-a123-0efb0aabc7d1
> Bridge br-int
> Port br-int
> Interface br-int
> type: internal
> Port "qvo8108425f-ef"
> tag: 1
> Interface "qvo8108425f-ef"
> Port patch-tun
> Interface patch-tun
> type: patch
> options: {peer=patch-int}
> Bridge br-tun
> Port br-tun
> Interface br-tun
> type: internal
> Port "gre-3"
> Interface "gre-3"
> type: gre
> options: {in_key=flow, out_key=flow,
> remote_ip="10.18.250.44"}
> Port "gre-4"
> Interface "gre-4"
> type: gre
> options: {in_key=flow, out_key=flow,
> remote_ip="10.18.250.42"}
> Port patch-int
> Interface patch-int
> type: patch
> options: {peer=patch-tun}
> ovs_version: "1.10.0"
>
> # ovs-ofctl dump-ports br-tun
> OFPST_PORT reply (xid=0x2): 2 ports
>   port  1: rx pkts=50, bytes=3300, drop=0, errs=0, frame=0, over=0, crc=0
>tx pkts=0, bytes=0, drop=0, errs=0, coll=0
>   port LOCAL: rx pkts=0, bytes=0, drop=0, errs=0, frame=0, over=0, crc=0
>tx pkts=140, bytes=9800, drop=0, errs=0, coll=0
>
> # uname -r
> 2.6.32-358.111.1.openstack.el6.x86_64
>
> # modinfo openvswitch
> filename:
>
> /lib/modules/2.6.32-358.111.1.openstack.el6.x86_64/extra/openvswitch/openvswitch.ko
> version:1.10.0
> license:GPL
> description:Open vSwitch switching datapath
> srcversion: 480D55A9BB0E8B000E32010
> depends:
> vermagic:   2.6.32-358.111.1.openstack.el6.x86_64 SMP mod_unload
> modversions
> parm:   vlan_tso:Enable TSO for VLAN packets (int)
>
> # tail ovs-vswitchd.log
>
> 2013-07-09T23:28:18Z|2|reconnect|INFO|unix:/var/run/openvswitch/db.sock:
> connecting...
>
> 2013-07-09T23:28:18Z|3|reconnect|INFO|unix:/var/run/openvswitch/db.sock:
> connected
> 2013-07-09T23:28:18Z|4|bridge|INFO|bridge br-int: added interface
> patch-tun on port 1
> 2013-07-09T23:28:18Z|5|bridge|INFO|bridge br-tun: added interface
> patch-int on port 1
> 2013-07-09T23:28:18Z|6|dpif|WARN|system@ovs-system: failed to add
> gre-3 as port: Address family not supported by protocol
> 2013-07-09T23:28:18Z|7|dpif|WARN|system@ovs-system: failed to add
> gre-4 as port: Address family not supported by protocol
> 2013-07-09T23:28:18Z|8|bridge|INFO|bridge br-int: using datapath
> ID dacb49a63448
> 2013-07-09T23:28:18Z|9|connmgr|INFO|br-int: added service
> controller "punix:/var/run/openvswitch/br-int.mgmt"
> 2013-07-09T23:28:18Z|00010|bridge|INFO|bridge br-tun: using datapath
> ID 9a14eee01941
> 2013-07-09T23:28:18Z|00011|connmgr|INFO|br-tun: added service
> controller "punix:/var/run/openvswitch/br-tun.mgmt"
> 2013-07-09T23:28:18Z|00012|bridge|INFO|ovs-vswitchd (Open vSwitch) 1.10.0
> 2013-07-09T23:28:28Z|00013|memory|INFO|7848 kB peak resident set size
> after 10.0 seconds
> 2013-07-09T23:28:28Z|00014|memory|INFO|ports:5 rules:11
> 2013-07-09T23:28:28Z|00015|ofproto|INFO|br-int: 2 flow_mods in the 4 s
> starting 10 s ago (1 adds, 1 deletes)
> 2013-07-09T23:28:28Z|00016|ofproto|INFO|br-tun: 5 flow_mods in the 3 s
> starting 10 s ago (5 adds)
> 2013-07-09T23:53:25Z|00017|netdev|WARN|failed to set flags for network
> device patch-int: Operation not supported
>
> On Tue, Jul 9, 2013 at 8:59 PM, Aaron Rosen  wrote:
> > I'd check the quantum openvswitch agent log files. I'd guess the reason

Re: [Openstack] Grizzly GRE tunneling network set up problems

2013-07-09 Thread Aaron Rosen

I'd check the quantum openvswitch agent log files. I'd guess the reason
this isn't working is because your kernel isn't using the openvswitch
kernel module that has tunnel support.

Aaron


On Tue, Jul 9, 2013 at 9:19 AM, Haitao Jiang  wrote:

> I just set up a multi-node Grizzly release 2013.2 with 1 controller
> node, 1 network node and 1 compute node. I use GRE tunneling.
>
> I create one VM on the compute node and was not able to ssh to it using
> netns.
>
> One thing I noticed is that on my compute node, I do not have br-int
> and br-tun in the list, nor do I find any GRE tunnels. Am I supposed
> to create the GRE tunnels manually or they should be set up
> automatically by Quantum? Any idea or suggestion to make it work?
>
> Thanks in advance!
>
> -- Compute node 
> -- /etc/quantum/plugins/openvswitch/ovs_quantum_plugin.ini  --
> tunnel_id_ranges=1:1000
> integration_bridge=br-int
> tunneling_bridge=br-tun
> tenant_network_type=gre
> enable_tunneling=True
> local_ip = 
>
> # brctl show
> bridge name bridge id   STP enabled interfaces
> qbr5a9800b9-26  8000.5242b197c3d3   no
>  qvb5a9800b9-26
> tap5a9800b9-26
> virbr0  8000.525400198a10   yes virbr0-nic
>
> # ovs-vsctl show
> 1d554b19-2a2b-493d-a123-0efb0aabc7d1
> Bridge br-tun
> Port patch-int
> Interface patch-int
> type: patch
> options: {peer=patch-tun}
> Port br-tun
> Interface br-tun
> type: internal
> Bridge br-int
> Port br-int
> Interface br-int
> type: internal
> Port patch-tun
> Interface patch-tun
> type: patch
> options: {peer=patch-int}
> Port "qvo5a9800b9-26"
> tag: 1
> Interface "qvo5a9800b9-26"
> ovs_version: "1.10.0"
>
>  network node ---
> # brctl show
> bridge name bridge id   STP enabled interfaces
>
> # ovs-vsctl show
> b9f0e822-cfc1-4b70-ac5b-abc4e5c258a4
> Bridge br-int
> Port br-int
> Interface br-int
> type: internal
> Port "tap9536e146-c2"
> Interface "tap9536e146-c2"
> Bridge br-ex
> Port br-ex
> Interface br-ex
> type: internal
> ovs_version: "1.10.0"
>
> ___
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] CLI command to figure out security-group's association to particular tenant/user

2013-06-28 Thread Aaron Rosen

On Thu, Jun 27, 2013 at 10:51 PM, Rahul Sharma wrote:

> Hi Aaron,
>
> Thanks for the CLI. I have a query related to that. I have a multinode
> openstack-deployment. To allow all the ports of VM accessible from outside,
> I need to add a rule "*TCP port-range 1-65535 Allow*" using Horizon
> dashboard. Now this rule is pushed to Quantum database as well as Nova
> database.
>

This is only stored in the quantum database. When querying nova for this
information it will query quantum.


> root@controller1:~# quantum security-group-rule-list --
> --tenant-id=40a7cd193a794161bfefd62364e64d03
>
> +--++---+--+--+--+
> | id   | security_group | direction |
> protocol | remote_ip_prefix | remote_group |
>
> +--++---+--+--+--+
> | 24cd1f88-8b50-45da-822c-e932178aeffd | default| egress
> |  |  |  |
> | 54e72726-61d5-4253-a92f-47a84d0ec882 | default| ingress
> |  |  | default  |
> | 977c7aff-9649-4037-af03-086d5db4955a | default| egress
> |  |  |  |
> *| d3e0d85c-b9c7-4fc3-9009-d14ed085876a | default| ingress   |
> tcp  | 0.0.0.0/0|  |*
> | e0887d63-bee2-4848-acce-c193aa03ef02 | default| ingress
> |  |  | default  |
>
> +--++---+--+--+--+
>
> root@controller1:~# nova --os-username test --os-password test
> --os-tenant-name "test" secgroup-list-rules default
> +-+---+-+---+--+
> | IP Protocol | From Port | To Port | IP Range  | Source Group |
> +-+---+-+---+--+
> | | -1| -1  |   | default  |
> | | -1| -1  |   | default  |
> *| tcp | 1 | 65535   | 0.0.0.0/0 |  |*
> +-+---+-+---+--+
>
> How can I do the same using CLI? Is there any single command which will do
> this task or I need to manually do this from UI? I tried adding rule using
> nova and quantum commands but its giving me error in taking parameters like
> 0.0.0.0/0 or due to something else which is not evident from the error
> message. I am using Grizzly release.
>
>
quantum security-group-rule-create --protocol tcp --ethertype IPv4
--port-range-min 1 --port-range-max 65535  --remote-ip-prefix 0.0.0.0/0
 default

or

nova secgroup-add-rule default tcp 1 65355 0.0.0.0/0


> Thanks and Regards
> Rahul Sharma
>
>
> On Thu, Jun 27, 2013 at 10:25 PM, Aaron Rosen  wrote:
>
>> Hi Rahul,
>>
>> The issue is that you are running as an admin user so it shows all the
>> security groups for every tenant. If you want to list the security groups
>> for just one particular tenant you can do this:
>>
>>
>>  quantum security-group-list  -- --tenant-id=
>>
>>
>> Aaron
>>
>>
>>
>> On Thu, Jun 27, 2013 at 5:54 AM, Rahul Sharma 
>> wrote:
>>
>>> Hi All,
>>>
>>> I have a query regarding the security-groups. Whenever I create a new
>>> tenant, a default security-group is created for that tenant. Now I want to
>>> find out which security-group is for which tenant? If I run "quantum
>>> security-group-list", then it shows me the security-groups is below format:-
>>> root@controller1:~# quantum security-group-list
>>>
>>> +--+-+-+
>>> | id   | name|
>>> description |
>>>
>>> +--+-+-+
>>> | 429f8e9e-edfc-4173-b599-9d91d9f7cb7d | default |
>>> default |
>>> | 47cbba23-6a73-44dc-b7c4-46794ed7aa5a | default |
>>> default |
>>> | 5ea93a09-6d96-4688-8005-99f8de4f20d7 | default |
>>> default |
>>> | 81cb819c-ffc2-4c26-b390-8e24b11f3443 | default |
>>> default |
>>> | 83778bc4-bbd2-4e02-9131-c5d4cf8a9e9b | default |
>>> default |
>>> | 9ca1438

Re: [Openstack] CLI command to figure out security-group's association to particular tenant/user

2013-06-27 Thread Aaron Rosen

Hi Rahul,

The issue is that you are running as an admin user so it shows all the
security groups for every tenant. If you want to list the security groups
for just one particular tenant you can do this:


 quantum security-group-list  -- --tenant-id=


Aaron



On Thu, Jun 27, 2013 at 5:54 AM, Rahul Sharma wrote:

> Hi All,
>
> I have a query regarding the security-groups. Whenever I create a new
> tenant, a default security-group is created for that tenant. Now I want to
> find out which security-group is for which tenant? If I run "quantum
> security-group-list", then it shows me the security-groups is below format:-
> root@controller1:~# quantum security-group-list
>
> +--+-+-+
> | id   | name|
> description |
>
> +--+-+-+
> | 429f8e9e-edfc-4173-b599-9d91d9f7cb7d | default |
> default |
> | 47cbba23-6a73-44dc-b7c4-46794ed7aa5a | default |
> default |
> | 5ea93a09-6d96-4688-8005-99f8de4f20d7 | default |
> default |
> | 81cb819c-ffc2-4c26-b390-8e24b11f3443 | default |
> default |
> | 83778bc4-bbd2-4e02-9131-c5d4cf8a9e9b | default |
> default |
> | 9ca14384-00f0-4597-acd4-00bdec10ab5c | default |
> default |
> | a0e42478-ff76-4513-a698-7d7b0450a878 | default |
> default |
> | da2cb126-520e-475b-81f3-5d0d2f05 | default |
> default |
>
> +--+-+-+
>
> How can I figure out the default security-group to a particular
> tenant/user? There is no option to show security-groups bound to particular
> tenant. Is there any CLI command to figure out the same?
>
> Thanks and Regards
> Rahul Sharma
>
> ___
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>
>
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] Security Groups Documentations - need some clarifications

2013-06-18 Thread Aaron Rosen

Hi Rami,


On Tue, Jun 18, 2013 at 11:36 PM, Rami Vaknin  wrote:

> Hi,
>
> I read the security groups documentation from the admin guide, I have few
> things that I'm not sure I fully understand, any clarification would be
> appreciated:
>
>
> i. http://docs.openstack.org/**trunk/openstack-network/admin/**
> content/securitygroups.html
>
> "If a security group is not specified the port will be associated with a
> 'default' security group. By default this group will drop all ingress
> traffic and allow all egress. Rules can be added to this group in order to
> change the behaviour"
>
> There is a small typo here: This should also add and allow traffic from
members of the default group.

The default behaviour is to allow all egress traffic, how do I make
> constraints on this traffic? it seems to me that the rules are kind of
> white list, how for instance can I disallow egress tcp traffic?


Correct, security groups are a white lists of what's allowed. The only way
you could disallow egress tcp traffic would be if you explicitly removed
all the egress rules and only added rules for traffic that you wanted
through. Stay tuned for the FWaaS stuff that will allow you to specifically
disallow all egress traffic rather than white list.


>
>
---
>
> ii. http://docs.openstack.org/**trunk/openstack-network/admin/**
> content/securitygroups.html
>
> "When a port is created in OpenStack Networking it is associated with a
> security group. If a security group is not specified the port will be
> associated with a 'default' security group"
>
> I'm adding a rule without denoting the security group and I get "quantum
> security-group-rule-create: error: too few arguments", when I add "default"
> to the exact same command - it works, is this a bug or am I missing
> something?
>
>
You need to specify the security group that you want the rule to be a part
of otherwise it doesn't know which group to put our rule in.

--
>
> iii. http://docs.openstack.org/**trunk/openstack-network/admin/**
> content/securitygroup_api_**abstractions.html
>
> I see that there are default values for the security group attributes,
> however, it's hard to derive what these default values means, for instance,
> "remote_ip_prefix" is the white list of the traffic source ip(s), what if I
> add a rule without denoting this "remote_ip_prefix" - does it mean that the
> traffic is allowed from any source ip(s)?
>
> Correct, if a value is not specified it is wild carded.  For example, if
one does: quantum security-group-rule-create --protocol tcp --ethertype
IPv4 default; that would allow all tcp traffic (on all ports).


-- 
>
> Thanks,
>
> Rami Vaknin.
>

Thanks,

Aaron

>
>
> __**_
> Mailing list: 
> https://launchpad.net/~**openstack
> Post to : openstack@lists.launchpad.net
> Unsubscribe : 
> https://launchpad.net/~**openstack
> More help   : 
> https://help.launchpad.net/**ListHelp
>
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] Security Group of Quantum ovs plugin (Folsom) is not working

2013-06-17 Thread Aaron Rosen

Hi,

I think it would also be helpful if you attached the output of:

nova secgroup-list
then: nova secgroup-list-rules for each group so we could see what rules
you have set in nova.

Aaron


On Mon, Jun 17, 2013 at 6:22 PM, Chandler Li wrote:

> Hi Aaron,
>
> Thanks for your reply!
>
> Yes, I have set /etc/nova/nova.conf as follows, but it seems not working.
>
> libvirt_vif_driver=nova.virt.libvirt.vif.LibvirtHybridOVSBridgeDriver
> firewall_driver=nova.virt.libvirt.firewall.IptablesFirewallDriver
> libvirt_use_virtio_for_bridges=True
>
> I can't figure out why network packets didn't follow the rules of
> iptables created by nova.
>
> There are no traffic in FORWARD chain rule and nova-compute-local chain
> rule as I posted before.
>
> Thanks again!
>
> Chandler
>
>
>
> 2013/6/18 Aaron Rosen 
>
>> Do you have:
>>
>>  firewall_driver=nova.virt.firewall.IptablesFirewallDriver
>>
>> in your nova.conf? In folsom, quantum leveraged nova security groups
>> implementation directly so you need that.  (looks like you have that set
>> though by your output).
>>
>> Aaron
>>
>>
>>
>> On Sun, Jun 16, 2013 at 7:38 PM, Chandler Li wrote:
>>
>>> Hi,
>>> I checked the compute node's iptables rules and found out the
>>> nova-compute-inst-xxx have no traffic flow.
>>> The traffic flow stopped at nova-filter-top chain rule, so security
>>> group is not working.
>>> Any idea how to resolve this problem?
>>>
>>> Thanks,
>>> Chandler
>>>
>>> [root@compute1 ~]# iptables -L -v -n
>>> Chain INPUT (policy ACCEPT 714 packets, 335K bytes)
>>>  pkts bytes target prot opt in out source
>>> destination
>>>   369  117K nova-compute-INPUT  all  --  *  *   0.0.0.0/0
>>>  0.0.0.0/0
>>> 0 0 ACCEPT udp  --  virbr0 *   0.0.0.0/0
>>> 0.0.0.0/0   udp dpt:53
>>> 0 0 ACCEPT tcp  --  virbr0 *   0.0.0.0/0
>>> 0.0.0.0/0   tcp dpt:53
>>> 0 0 ACCEPT udp  --  virbr0 *   0.0.0.0/0
>>> 0.0.0.0/0   udp dpt:67
>>> 0 0 ACCEPT tcp  --  virbr0 *   0.0.0.0/0
>>> 0.0.0.0/0   tcp dpt:67
>>> 0 0 ACCEPT tcp  --  *  *   0.0.0.0/0
>>> 0.0.0.0/0   tcp dpt:5900
>>>
>>> Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
>>>  pkts bytes target prot opt in out source
>>> destination
>>> 0 0 nova-filter-top  all  --  *  *   0.0.0.0/0
>>>0.0.0.0/0
>>> 0 0 nova-compute-FORWARD  all  --  *  *   0.0.0.0/0
>>>0.0.0.0/0
>>> 0 0 ACCEPT all  --  *  virbr0  0.0.0.0/0
>>> 192.168.122.0/24state RELATED,ESTABLISHED
>>> 0 0 ACCEPT all  --  virbr0 *   192.168.122.0/24
>>> 0.0.0.0/0
>>> 0 0 ACCEPT all  --  virbr0 virbr0  0.0.0.0/0
>>> 0.0.0.0/0
>>> 0 0 REJECT all  --  *  virbr0  0.0.0.0/0
>>> 0.0.0.0/0   reject-with icmp-port-unreachable
>>> 0 0 REJECT all  --  virbr0 *   0.0.0.0/0
>>> 0.0.0.0/0   reject-with icmp-port-unreachable
>>>
>>> Chain OUTPUT (policy ACCEPT 779 packets, 378K bytes)
>>>  pkts bytes target prot opt in out source
>>> destination
>>>   437  233K nova-filter-top  all  --  *  *   0.0.0.0/0
>>>0.0.0.0/0
>>>   396  216K nova-compute-OUTPUT  all  --  *  *   0.0.0.0/0
>>>0.0.0.0/0
>>>
>>> Chain nova-compute-FORWARD (1 references)
>>>  pkts bytes target prot opt in out source
>>> destination
>>>
>>> Chain nova-compute-INPUT (1 references)
>>>  pkts bytes target prot opt in out source
>>> destination
>>>
>>> Chain nova-compute-OUTPUT (1 references)
>>>  pkts bytes target prot opt in out source
>>> destination
>>>
>>> Chain nova-compute-inst-767 (1 references)
>>>  pkts bytes target prot opt in out source
>>> destination
>>> 0 0 DROP   all  --  *  *   0.0.0.0/0
>>> 0.0.0.0/0   state INVALID
>>> 0 0 ACCEPT all  --  *  *   0.0.0.0/0
>>> 0.0.0.0/0   state RELATED,ESTABLISHED
>>> 0 0 nova-compute-provider  all  --  *  *   0.0.0.0/0
>>>  0.0.0.0/0
>>> 0 0 ACCEPT udp  --

Re: [Openstack] To run Openstack, stack.sh is required to execute after every reboot ?

2013-06-17 Thread Aaron Rosen

If you run rejoin-stack.sh it should start all the openstack processes that
were running before reboot.

Aaron


On Mon, Jun 17, 2013 at 12:15 PM, Vivek Satpute wrote:

> Hi,
>
> I recently setup a openstack on one node, which is hosting all the services
> like keystone, nova, glance, cinder, etc. Using Dashboard, I could create
> the VM instances and volumes too. But if I rebooted my host machine where
> openstack is configured, once machine comes up, horizon cannot
> retrieve any data.
>
> I realised that, there is no services running on host setup. (Checked
> using ps -ef command).
> I again did ./stack.sh and then I could create new instances, volumes, etc.
>
> How can I configure openstack such a that it would get started after
> reboot automatically ?
> Or Am I missing something here ?
>
>
> Thanks in advance,
> Vivek Satpute
>
> ___
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] Security Group of Quantum ovs plugin (Folsom) is not working

2013-06-17 Thread Aaron Rosen

Do you have:

 firewall_driver=nova.virt.firewall.IptablesFirewallDriver

in your nova.conf? In folsom, quantum leveraged nova security groups
implementation directly so you need that.  (looks like you have that set
though by your output).

Aaron



On Sun, Jun 16, 2013 at 7:38 PM, Chandler Li wrote:

> Hi,
> I checked the compute node's iptables rules and found out the
> nova-compute-inst-xxx have no traffic flow.
> The traffic flow stopped at nova-filter-top chain rule, so security group
> is not working.
> Any idea how to resolve this problem?
>
> Thanks,
> Chandler
>
> [root@compute1 ~]# iptables -L -v -n
> Chain INPUT (policy ACCEPT 714 packets, 335K bytes)
>  pkts bytes target prot opt in out source
> destination
>   369  117K nova-compute-INPUT  all  --  *  *   0.0.0.0/0
>0.0.0.0/0
> 0 0 ACCEPT udp  --  virbr0 *   0.0.0.0/0
> 0.0.0.0/0   udp dpt:53
> 0 0 ACCEPT tcp  --  virbr0 *   0.0.0.0/0
> 0.0.0.0/0   tcp dpt:53
> 0 0 ACCEPT udp  --  virbr0 *   0.0.0.0/0
> 0.0.0.0/0   udp dpt:67
> 0 0 ACCEPT tcp  --  virbr0 *   0.0.0.0/0
> 0.0.0.0/0   tcp dpt:67
> 0 0 ACCEPT tcp  --  *  *   0.0.0.0/0
> 0.0.0.0/0   tcp dpt:5900
>
> Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
>  pkts bytes target prot opt in out source
> destination
> 0 0 nova-filter-top  all  --  *  *   0.0.0.0/0
> 0.0.0.0/0
> 0 0 nova-compute-FORWARD  all  --  *  *   0.0.0.0/0
>  0.0.0.0/0
> 0 0 ACCEPT all  --  *  virbr0  0.0.0.0/0
> 192.168.122.0/24state RELATED,ESTABLISHED
> 0 0 ACCEPT all  --  virbr0 *   192.168.122.0/24
> 0.0.0.0/0
> 0 0 ACCEPT all  --  virbr0 virbr0  0.0.0.0/0
> 0.0.0.0/0
> 0 0 REJECT all  --  *  virbr0  0.0.0.0/0
> 0.0.0.0/0   reject-with icmp-port-unreachable
> 0 0 REJECT all  --  virbr0 *   0.0.0.0/0
> 0.0.0.0/0   reject-with icmp-port-unreachable
>
> Chain OUTPUT (policy ACCEPT 779 packets, 378K bytes)
>  pkts bytes target prot opt in out source
> destination
>   437  233K nova-filter-top  all  --  *  *   0.0.0.0/0
> 0.0.0.0/0
>   396  216K nova-compute-OUTPUT  all  --  *  *   0.0.0.0/0
>  0.0.0.0/0
>
> Chain nova-compute-FORWARD (1 references)
>  pkts bytes target prot opt in out source
> destination
>
> Chain nova-compute-INPUT (1 references)
>  pkts bytes target prot opt in out source
> destination
>
> Chain nova-compute-OUTPUT (1 references)
>  pkts bytes target prot opt in out source
> destination
>
> Chain nova-compute-inst-767 (1 references)
>  pkts bytes target prot opt in out source
> destination
> 0 0 DROP   all  --  *  *   0.0.0.0/0
> 0.0.0.0/0   state INVALID
> 0 0 ACCEPT all  --  *  *   0.0.0.0/0
> 0.0.0.0/0   state RELATED,ESTABLISHED
> 0 0 nova-compute-provider  all  --  *  *   0.0.0.0/0
>0.0.0.0/0
> 0 0 ACCEPT udp  --  *  *   30.0.0.2
> 0.0.0.0/0   udp spt:67 dpt:68
> 0 0 ACCEPT all  --  *  *   30.0.0.0/24
> 0.0.0.0/0
> 0 0 ACCEPT tcp  --  *  *   0.0.0.0/0
> 0.0.0.0/0   tcp dpt:22
> 0 0 ACCEPT icmp --  *  *   0.0.0.0/0
> 0.0.0.0/0
> 0 0 nova-compute-sg-fallback  all  --  *  *   0.0.0.0/0
>  0.0.0.0/0
>
> Chain nova-compute-local (1 references)
>  pkts bytes target prot opt in out source
> destination
> 0 0 nova-compute-inst-767  all  --  *  *   0.0.0.0/0
>30.0.0.5
>
> Chain nova-compute-provider (1 references)
>  pkts bytes target prot opt in out source
> destination
>
> Chain nova-compute-sg-fallback (1 references)
>  pkts bytes target prot opt in out source
> destination
> 0 0 DROP   all  --  *  *   0.0.0.0/0
> 0.0.0.0/0
>
> Chain nova-filter-top (2 references)
>  pkts bytes target prot opt in out source
> destination
>   396  216K nova-compute-local  all  --  *  *   0.0.0.0/0
>0.0.0.0/0
>
>
>
> 2013/6/14 Chandler Li 
>
>> Hello,
>>
>> I'm trying to use security group of Quantum ovs plugin(Folsom) in CentOS
>> 6.3 (2012.2.3-1.el6@epel).
>>
>> Everything looks good, except security group,
>>
>> and there are no error message in /var/log/nova/compute.log file.
>>
>> After I created VM, I can see the bridges and interfaces have been
>> created normally.
>>
>>  [root@compute1 ~]# brctl show
>>  bridge name bridge id   STP enabled interfaces
>>  br-int  .3eca2e714b4d   no
>>  qvo756ead5d-32
>>  br-tun  .824651aab541   no
>>  qbr756ead5d-32  .ca57ea41484c   no
>>  qvb756ead5d-32
>>  vnet0
>>
>> T

Re: [Openstack] quantum l2 networks

2013-06-08 Thread Aaron Rosen

Hi Joe,

Just curious what's your use case, why do you need to disable these?

Aaron


On Sat, Jun 8, 2013 at 12:01 PM, Joe Breu  wrote:

>  Hi Aaron,
>
>  Thanks for the response.  It looks like it is the nwfilters in
> nova-compute that are making this a pain for me.
>
>
>
>  On Jun 7, 2013, at 11:11 PM, Aaron Rosen wrote:
>
>  Hi Joe,
>
>  I thought setting firewall_driver =
> quantum.agent.firewall.NoopFirewallDriver would do the trick? Also, the ovs
> plugin does not do any mac spoof filtering at the OVS level. Those are all
> done in iptables.
>
> Aaron
>
> On Fri, Jun 7, 2013 at 8:22 PM, Joe Breu wrote:
>
>> Hello,
>>
>> Is there a way to create a quantum l2 network using OVS that does not
>> have MAC and IP spoofing enabled either in iptables or OVS?  One workaround
>> that we found was to set the OVS plugin firewall_driver =
>> quantum.agent.firewall.NoopFirewallDriver to security_group_api=nova
>> however this is far from ideal and doesn't solve the problem of MAC spoof
>> filtering at the OVS level.
>>
>> Thanks for any help
>>
>>
>> ___
>> Mailing list: https://launchpad.net/~openstack
>> Post to : openstack@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~openstack
>> More help   : https://help.launchpad.net/ListHelp
>>
>
>
>
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] quantum l2 networks

2013-06-08 Thread Aaron Rosen

Settting this in nova.conf should disable that but then your security
groups won't work.
firewall_driver = nova.virt.firewall.NoopFirewallDriver



On Sat, Jun 8, 2013 at 12:01 PM, Joe Breu  wrote:

>  Hi Aaron,
>
>  Thanks for the response.  It looks like it is the nwfilters in
> nova-compute that are making this a pain for me.
>
>
>
>  On Jun 7, 2013, at 11:11 PM, Aaron Rosen wrote:
>
>  Hi Joe,
>
>  I thought setting firewall_driver =
> quantum.agent.firewall.NoopFirewallDriver would do the trick? Also, the ovs
> plugin does not do any mac spoof filtering at the OVS level. Those are all
> done in iptables.
>
> Aaron
>
> On Fri, Jun 7, 2013 at 8:22 PM, Joe Breu wrote:
>
>> Hello,
>>
>> Is there a way to create a quantum l2 network using OVS that does not
>> have MAC and IP spoofing enabled either in iptables or OVS?  One workaround
>> that we found was to set the OVS plugin firewall_driver =
>> quantum.agent.firewall.NoopFirewallDriver to security_group_api=nova
>> however this is far from ideal and doesn't solve the problem of MAC spoof
>> filtering at the OVS level.
>>
>> Thanks for any help
>>
>>
>> ___
>> Mailing list: https://launchpad.net/~openstack
>> Post to : openstack@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~openstack
>> More help   : https://help.launchpad.net/ListHelp
>>
>
>
>
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] quantum l2 networks

2013-06-08 Thread Aaron Rosen

Hi Daniel,

That's for finding this! This is a bug. The code wasn't accounting if the
plugin didn't implement port_security_enabled.  Here's a patch that fixes
the issue in the meantime.

Best,

Aaron

--- a/nova/network/security_group/quantum_driver.py
+++ b/nova/network/security_group/quantum_driver.py
@@ -340,8 +340,9 @@ class
SecurityGroupAPI(security_group_base.SecurityGroupBase):
 has_ip = port.get('fixed_ips')
 if port_security_enabled and has_ip:
 return True
-else:
-return False
+elif 'port_security_enabled' not in port and has_ip:
+return True
+return False

 @wrap_check_security_groups_policy
 def add_to_instance(self, context, instance, security_group_name):



On Sat, Jun 8, 2013 at 2:14 AM, daniels cai  wrote:

>
> nova add-secgroup 24891d97-8d0e-4e99-9537-c8f8291913d0 d11
>
> ERROR: Network requires port_security_enabled and subnet associated in
> order to apply security groups. (HTTP 400) (Request-ID:
> req-94cb2d54-858b-4843-af53-b373c88bcdc0)
>
>
> security group is exists
>
> # quantum security-group-list
> +--+-+--+
> | id   | name| description  |
> +--+-+--+
> | 0acc8258-bd9f-4f87-b051-a94dbc1504eb | default | default  |
> | 5902febc-e793-4b09-8073-567226d83d79 | d11 | des for firewall |
> +--+-+--+
>
>
>
> Daniels Cai
> http://dnscai.com
>
>
> 2013/6/8 Aaron Rosen 
>
>> You said:
>>
>> >it works, but when i try to attach a security group to an exist vm , api
>> throw an error :"Network requires >port_security_enabled and subnet
>> associated in order to apply security groups."
>>
>> What command are you running to generate that error?
>>
>>
>>
>> On Sat, Jun 8, 2013 at 1:45 AM, daniels cai  wrote:
>>
>>> Aaron , thanks for you answers, i see it.
>>>
>>> we are not useing nvp in our environemnt
>>> yet.
>>>
>>> my vm is boot with a subnet_id specified
>>> .
>>> i am sure about it .
>>> here is more info:
>>>
>>> vm has an ip "192.168.6.100" , this ip belongs to subnet
>>> 83afd693-7e36-41e9-b896-9d8b0d89d255
>>> , this subnet belongs to network "iaas-net", network id is
>>> 5332f0f7-3156-4961-aa67-0b8507265fa5
>>>
>>> # nova list
>>>
>>> | 24891d97-8d0e-4e99-9537-c8f8291913d0 | ubuntu-1304-server-amd64 |
>>> ACTIVE  | iaas-net=192.168.6.100
>>>
>>> here is quantum network info :
>>>
>>> # quantum net-list
>>>
>>> +--+--+---+
>>> | id   | name | subnets
>>>   |
>>>
>>> +--+--+---+
>>> |
>>> 5332f0f7-3156-4961-aa67-0b8507265fa5 | iaas-net |
>>> 329ca377-6193-4a0c-9320-471cd5ff762f 192.168.202.0/24 |
>>> |  |  |
>>> 83afd693-7e36-41e9-b896-9d8b0d89d255 192.168.6.0/24   |
>>> |  |  |
>>> bb1afb2d-ab59-4ba4-8a76-8b5b426b8e33 192.168.7.0/24   |
>>> |  |  |
>>> d59794df-bb49-4924-a19f-cbdec0ce24df 192.168.188.0/24 |
>>> |  |  |
>>> dca45033-e506-42e4-bf05-aaccd0591c55 192.168.193.0/24 |
>>> |  |  |
>>> e8a9be74-2f39-4d7e-9287-c5b85b573cca 192.168.192.0/24 |
>>>
>>>
>>> i enabled the following features in quantum
>>> 1. namespace
>>> 2. overlap ips
>>>
>>> if any more info needed for debug, i will attach
>>>
>>>
>>>
>>> Daniels Cai
>>> http://dnscai.com
>>>
>>>
>>> 2013/6/8 Aaron Rosen 
>>> >
>>> > There is no port_security_enabled config option. This is an attribute
>>> on a port that is used if the plugin you are using implements the
>>> port_security_extension (which is only nvp at the time).
>>> >
>>> > I'm guessing your issue is t

Re: [Openstack] quantum l2 networks

2013-06-08 Thread Aaron Rosen

You said:

>it works, but when i try to attach a security group to an exist vm , api
throw an error :"Network requires >port_security_enabled and subnet
associated in order to apply security groups."

What command are you running to generate that error?



On Sat, Jun 8, 2013 at 1:45 AM, daniels cai  wrote:

> Aaron , thanks for you answers, i see it.
>
> we are not useing nvp in our environemnt
> yet.
>
> my vm is boot with a subnet_id specified
> .
> i am sure about it .
> here is more info:
>
> vm has an ip "192.168.6.100" , this ip belongs to subnet
> 83afd693-7e36-41e9-b896-9d8b0d89d255
> , this subnet belongs to network "iaas-net", network id is
> 5332f0f7-3156-4961-aa67-0b8507265fa5
>
> # nova list
>
> | 24891d97-8d0e-4e99-9537-c8f8291913d0 | ubuntu-1304-server-amd64 | ACTIVE
>  | iaas-net=192.168.6.100
>
> here is quantum network info :
>
> # quantum net-list
>
> +--+--+---+
> | id   | name | subnets
> |
>
> +--+--+---+
> |
> 5332f0f7-3156-4961-aa67-0b8507265fa5 | iaas-net |
> 329ca377-6193-4a0c-9320-471cd5ff762f 192.168.202.0/24 |
> |  |  |
> 83afd693-7e36-41e9-b896-9d8b0d89d255 192.168.6.0/24   |
> |  |  |
> bb1afb2d-ab59-4ba4-8a76-8b5b426b8e33 192.168.7.0/24   |
> |  |  |
> d59794df-bb49-4924-a19f-cbdec0ce24df 192.168.188.0/24 |
> |  |  |
> dca45033-e506-42e4-bf05-aaccd0591c55 192.168.193.0/24 |
> |  |  |
> e8a9be74-2f39-4d7e-9287-c5b85b573cca 192.168.192.0/24 |
>
>
> i enabled the following features in quantum
> 1. namespace
> 2. overlap ips
>
> if any more info needed for debug, i will attach
>
>
>
> Daniels Cai
> http://dnscai.com
>
>
> 2013/6/8 Aaron Rosen 
> >
> > There is no port_security_enabled config option. This is an attribute on
> a port that is used if the plugin you are using implements the
> port_security_extension (which is only nvp at the time).
> >
> > I'm guessing your issue is the network you are trying to boot an
> instance on does not have a subnet associated with it.
> >
> > Aaron
> >
> >
> > On Sat, Jun 8, 2013 at 12:37 AM, daniels cai  wrote:
> >>
> >> hi Aaron
> >> i set the following in nova.conf
> >>
> >> security_group_api=quantum
> >> firewall_driver=nova.virt.firewall.NoopFirewallDriver
> >>
> >> it works, but when i try to attach a security group to an exist vm ,
> api throw an error :
> >>
> >> "Network requires port_security_enabled and subnet associated in order
> to apply security groups."
> >>
> >> the i add port_security_enabled in quantum.conf in all nodes.
> >> "port_security_enabled=True"
> >>
> >>  with no luck, it still doesn't work .
> >>
> >> Any advice ? does quantum security group support this feature?
> >>
> >> Daniels Cai
> >> http://dnscai.com
> >>
> >>
> >> 2013/6/8 Aaron Rosen 
> >>>
> >>> Hi Joe,
> >>>
> >>> I thought setting firewall_driver =
> quantum.agent.firewall.NoopFirewallDriver would do the trick? Also, the ovs
> plugin does not do any mac spoof filtering at the OVS level. Those are all
> done in iptables.
> >>>
> >>> Aaron
> >>>
> >>> On Fri, Jun 7, 2013 at 8:22 PM, Joe Breu 
> wrote:
> >>>>
> >>>> Hello,
> >>>>
> >>>> Is there a way to create a quantum l2 network using OVS that does not
> have MAC and IP spoofing enabled either in iptables or OVS?  One workaround
> that we found was to set the OVS plugin firewall_driver =
> quantum.agent.firewall.NoopFirewallDriver to security_group_api=nova
> however this is far from ideal and doesn't solve the problem of MAC spoof
> filtering at the OVS level.
> >>>>
> >>>> Thanks for any help
> >>>>
> >>>>
> >>>> ___
> >>>> Mailing list: https://launchpad.net/~openstack
> >>>> Post to : openstack@lists.launchpad.net
> >>>> Unsubscribe : https://launchpad.net/~openstack
> >>>> More help   : https://help.launchpad.net/ListHelp
> >>>
> >>>
> >>>
> >>> ___
> >>> Mailing list: https://launchpad.net/~openstack
> >>> Post to : openstack@lists.launchpad.net
> >>> Unsubscribe : https://launchpad.net/~openstack
> >>> More help   : https://help.launchpad.net/ListHelp
> >>>
> >>
> >
>
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] quantum l2 networks

2013-06-08 Thread Aaron Rosen

There is no port_security_enabled config option. This is an attribute on a
port that is used if the plugin you are using implements the
port_security_extension (which is only nvp at the time).

I'm guessing your issue is the network you are trying to boot an instance
on does not have a subnet associated with it.

Aaron


On Sat, Jun 8, 2013 at 12:37 AM, daniels cai  wrote:

> hi Aaron
> i set the following in nova.conf
>
> security_group_api=quantum
> firewall_driver=nova.virt.firewall.NoopFirewallDriver
>
> it works, but when i try to attach a security group to an exist vm , api
> throw an error :
>
> "Network requires port_security_enabled and subnet associated in order to
> apply security groups."
>
> the i add port_security_enabled in quantum.conf in all nodes.
> "port_security_enabled=True"
>
>  with no luck, it still doesn't work .
>
> Any advice ? does quantum security group support this feature?
>
> Daniels Cai
> http://dnscai.com
>
>
> 2013/6/8 Aaron Rosen 
>
>> Hi Joe,
>>
>> I thought setting firewall_driver =
>> quantum.agent.firewall.NoopFirewallDriver would do the trick? Also, the ovs
>> plugin does not do any mac spoof filtering at the OVS level. Those are all
>> done in iptables.
>>
>> Aaron
>>
>> On Fri, Jun 7, 2013 at 8:22 PM, Joe Breu wrote:
>>
>>> Hello,
>>>
>>> Is there a way to create a quantum l2 network using OVS that does not
>>> have MAC and IP spoofing enabled either in iptables or OVS?  One workaround
>>> that we found was to set the OVS plugin firewall_driver =
>>> quantum.agent.firewall.NoopFirewallDriver to security_group_api=nova
>>> however this is far from ideal and doesn't solve the problem of MAC spoof
>>> filtering at the OVS level.
>>>
>>> Thanks for any help
>>>
>>>
>>> ___
>>> Mailing list: https://launchpad.net/~openstack
>>> Post to : openstack@lists.launchpad.net
>>> Unsubscribe : https://launchpad.net/~openstack
>>> More help   : https://help.launchpad.net/ListHelp
>>>
>>
>>
>> ___
>> Mailing list: https://launchpad.net/~openstack
>> Post to : openstack@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~openstack
>> More help   : https://help.launchpad.net/ListHelp
>>
>>
>
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] quantum l2 networks

2013-06-07 Thread Aaron Rosen

Hi Joe,

I thought setting firewall_driver =
quantum.agent.firewall.NoopFirewallDriver would do the trick? Also, the ovs
plugin does not do any mac spoof filtering at the OVS level. Those are all
done in iptables.

Aaron

On Fri, Jun 7, 2013 at 8:22 PM, Joe Breu  wrote:

> Hello,
>
> Is there a way to create a quantum l2 network using OVS that does not have
> MAC and IP spoofing enabled either in iptables or OVS?  One workaround that
> we found was to set the OVS plugin firewall_driver =
> quantum.agent.firewall.NoopFirewallDriver to security_group_api=nova
> however this is far from ideal and doesn't solve the problem of MAC spoof
> filtering at the OVS level.
>
> Thanks for any help
>
>
> ___
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] Quantum VLAN tag mismatch between Network-node and Compute-node

2013-06-05 Thread Aaron Rosen

Hi,

Those vlan tags you are showing are not the actual tags that will be seen
on the wire. Those tags are auto incremented and used for each new port
that lands on a server that is in a different network. If you run ovs-ofctl
dump-flows br-int you'll see those vlan tags are stripped off and the
correct one is added.


Look here
https://github.com/openstack/quantum/blob/master/quantum/plugins/openvswitch/agent/ovs_quantum_agent.py#L326
if
your curious about what's going on.

Aaron


On Wed, Jun 5, 2013 at 2:25 AM, Chu Duc Minh  wrote:

> Hi, i'm converting from GRE tunnel to VLAN tagging, and deleted all old
> project/user/net/subnet.
>
> in file /etc/quantum/plugins/openvswitch/ovs_quantum_plugin.ini @ all
> nodes, I already set:
> network_vlan_ranges = physnet1:2:4094
> When I create a new net:
> +---+--+
> | Field | Value|
> +---+--+
> | admin_state_up| True |
> | id| 6d7b116e-be0b-4019-8769-a50a9ca13406 |
> | name  | net_proj_one |
> | provider:network_type | vlan |
> | provider:physical_network | physnet1 |
> *| provider:segmentation_id  | 2  *  |
> | router:external   | False|
> | shared| False|
> | status| ACTIVE   |
> | subnets   | 959fe9e0-a79d-4d0f-8040-ebfab26d8182 |
> | tenant_id | 29ba82e97f374492a4ca02c62eb0a953 |
> +---+--+
>
> But when i show in network-node:
> # ovs-vsctl show
> ...
> Bridge br-int
> Port "tapdddef664-ee"
> *tag: 1*
> Interface "tapdddef664-ee"
> type: internal
> Port "qr-f9ba0308-2c"
> *tag: 1*
> Interface "qr-f9ba0308-2c"
> type: internal
> Port "int-br-eth0"
> Interface "int-br-eth0"
> Port br-int
> Interface br-int
> type: internal
> Bridge "br-eth0"
> Port "br-eth0"
> Interface "br-eth0"
> type: internal
> Port "phy-br-eth0"
> Interface "phy-br-eth0"
> Port "eth0"
> Interface "eth0"
>
> interface for router & dhcp created are created in VLAN 1 (wrong! it
> should be created with VLAN 2)
> I try to find in config and database, but i can't found which setting that
> start with VLAN 1.
>
> Because of VLAN tag mismatch, I can't access to VM instance.
> Another weird thing is on compute node, tag is not constant when i
> create/terminate new instance:
> # ovs-vsctl show
> a9900940-f882-42f8-9b7c-9b42393ed8a4
> Bridge "qbred613362-fe"
> Port "qvbed613362-fe"
> Interface "qvbed613362-fe"
> Port "qbred613362-fe"
> Interface "qbred613362-fe"
> type: internal
> Port "taped613362-fe"
> Interface "taped613362-fe"
> Bridge "br-eth1"
> Port "eth1"
> Interface "eth1"
> Port "br-eth1"
> Interface "br-eth1"
> type: internal
> Port "phy-br-eth1"
> Interface "phy-br-eth1"
> Bridge br-int
> Port br-int
> Interface br-int
> type: internal
> Port "qvo9816466e-22"
> *tag: 5*
> Interface "qvo9816466e-22"
> Port "int-br-eth1"
> Interface "int-br-eth1"
> Port "qvoed613362-fe"
> *tag: 5*
> Interface "qvoed613362-fe"
> Bridge "qbr9816466e-22"
> Port "qbr9816466e-22"
> Interface "qbr9816466e-22"
> type: internal
> Port "tap9816466e-22"
> Interface "tap9816466e-22"
> Port "qvb9816466e-22"
> Interface "qvb9816466e-22"
> Bridge "virbr0"
> Port "virbr0"
> Interface "virbr0"
> type: internal
>
> Do you know why it happen?
>
> When everything is ok, *tag* on both Network-node & Compute-node should
> equal *2 *(for first VM network) when I configured "*network_vlan_ranges
> = physnet1:2:4094*" ??
>
> Thank you very much!
>
> ___
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>
>
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://hel

Re: [Openstack] [Quantum] second tenant's several VMs' floating ip can't be accessed.

2013-06-03 Thread Aaron Rosen

You are probably running quantum commands as an admin user that's why you
got the error:
Multiple security_group matches found for name 'default', use an ID to be
more specific.

If you run quantum security-group-list

and then:

quantum security-group-rule-create --protocol icmp --direction ingress


for each default security group.

I'm guessing the security group for your second tenant does not have this
rule as I don't see two icmp rules in the security-group-rule-list output
you pasted.

Aaron



On Mon, Jun 3, 2013 at 7:05 PM, Li, Leon  wrote:

> Aaron,
>
> ** **
>
> Thanks for helping.
>
> Actually I already have had this rule:
>
> (quantum)  security-group-rule-list
>
>
> +--++---+--+--+--+
> 
>
> | id   | security_group | direction |
> protocol | remote_ip_prefix | remote_group |
>
>
> +--++---+--+--+--+
> 
>
> | 1a5867db-864b-4ae9-a423-092f3c25d710 | default| ingress
> |  |  | default  |
>
> | 5449c312-00ba-4625-813f-1d7f06bb8259 | default| ingress   |
> tcp  | 0.0.0.0/0|  |
>
> | 59166d99-0901-4c58-8bf3-ff46cfd4bb01 | default| egress
> |  |  |  |
>
> | 79708fb2-50b1-4c7b-82a5-5cd0275603ad | default| egress
> |  |  |  |
>
> | 940a2743-859a-444c-9c3c-0204995e87ba | default| ingress
> |  |  | default  |
>
> | a7812053-a913-4288-bbd3-c5f225f38d13 | default| ingress
> |  |  | default  |
>
> | b160a8cf-7ca0-4da6-b238-68315b199314 | default| egress
> |  |  |  |
>
> | bce886e7-74d2-46bc-aba6-5928a17b2c74 | default| ingress
> |  |  | default  |
>
> | c3ccbe23-5d44-4cbc-991d-a5df29aa5300 | default| ingress
> |  |  | default  |
>
> | c86af4d4-d6eb-4b15-a23c-1d84d8b27716 | default| egress
> |  |  |  |
>
> | c9b96941-c652-4b24-9162-4a1dcd999088 | default| ingress   |
> icmp | 0.0.0.0/0|  |
>
> | dd26aab7-7641-4ad8-ac53-fe443f41ab5f | default| ingress
> |  |  | default  |
>
> | f87eeaea-4b97-4995-968e-34f127d09bd3 | default| egress
> |  |  |  |
>
> | fc7d35d0-d2b6-4df1-a03b-ca28c5e5c487 | default| egress
> |  |  |  |
>
>
> +--++---+--+--+--+
> 
>
> (quantum) security-group-rule-create --protocol icmp --direction ingress
> default
>
> Multiple security_group matches found for name 'default', use an ID to be
> more specific.
>
> (quantum)
>
> ** **
>
> Actualy my first tenant’s several VMs don’t have network issue. Can ping
> their’s floating IP from Internet.
>
> However my second tenant’s several VMs have same network issue: can ping
> Internet from vm, but can’t ping their floating IP from Internet.
>
> ** **
>
> Leon
>
> ** **
>
> *From:* Aaron Rosen [mailto:aro...@nicira.com]
> *Sent:* 2013年6月4日 9:03
> *To:* Li, Leon
> *Cc:* openstack-operat...@lists.openstack.org;
> openstack@lists.launchpad.net (openstack@lists.launchpad.net)
> *Subject:* Re: [Openstack] [Quantum] second tenant VM's floating ip can't
> be accessed.
>
> ** **
>
> Hi Li, 
>
> ** **
>
> If you can ping out to the internet from your second vm but not back in
> it's most likely related to security groups. 
>
> ** **
>
> I'd try running: quantum security-group-rule-create --protocol icmp
> --direction ingress default 
>
> ** **
>
> and see if that allows ping from the internet to be received. 
>
> ** **
>
> Aaron
>
> ** **
>
> On Mon, Jun 3, 2013 at 2:43 AM, Li, Leon  wrote:
>
> Hi all,
>
>  
>
> I set up an openstack recently. My first tenant’s VMs’ floating IP work
> fine. All of them is pingable from “Internet”.
>
> However on second tenant, via GUI or CLI I can successfully assign
> floating IPs to VMs, but they are not pingable. Meanwhile, I can ping
> Internet from VM’s private network(IP).***

Re: [Openstack] [Quantum] second tenant VM's floating ip can't be accessed.

2013-06-03 Thread Aaron Rosen

Hi Li,

If you can ping out to the internet from your second vm but not back in
it's most likely related to security groups.

I'd try running: quantum security-group-rule-create --protocol icmp
--direction ingress default

and see if that allows ping from the internet to be received.

Aaron


On Mon, Jun 3, 2013 at 2:43 AM, Li, Leon  wrote:

> Hi all,
>
> ** **
>
> I set up an openstack recently. My first tenant’s VMs’ floating IP work
> fine. All of them is pingable from “Internet”.
>
> However on second tenant, via GUI or CLI I can successfully assign
> floating IPs to VMs, but they are not pingable. Meanwhile, I can ping
> Internet from VM’s private network(IP).
>
> My environment: Grizzly. Quantum. 3 physical servers. One is controller;
> one is network; and the other is compute node. GRE tunnel.
>
> Anyone has idea? Thanks for your help.
>
> ** **
>
> Leon
>
> ___
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>
>
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] How to assign External ip to vm without quantum L3 agent

2013-05-30 Thread Aaron Rosen

Sure, let us know if there is something unclear with the doc:
http://docs.openstack.org/trunk/openstack-network/admin/content/provider_networks.html



On Thu, May 30, 2013 at 11:24 PM, balaji patnala wrote:

> Hi Aron,
>
> Do we have any sample provider network extension available in Grizzly
> Release. If so, Can you please share that information.
>
> Any other information on this will be appreciated.
>
> Thanks,
> Balaji.P
>
>
> On Thu, May 30, 2013 at 11:37 AM, Aaron Rosen  wrote:
>
>> No but the provider network extention does provide a way to do this that
>> might work for your usecase:
>> http://docs.openstack.org/trunk/openstack-network/admin/content/provider_networks.html
>>
>>
>> On Wed, May 29, 2013 at 11:02 PM, Veera Reddy wrote:
>>
>>> Hi,
>>>
>>> IS there any way to access VM from external network without using
>>> quantum l3 agent.
>>>
>>> --
>>> Regards,
>>> VeeraReddy.B
>>>
>>>
>>> ___
>>> Mailing list: https://launchpad.net/~openstack
>>> Post to : openstack@lists.launchpad.net
>>> Unsubscribe : https://launchpad.net/~openstack
>>> More help   : https://help.launchpad.net/ListHelp
>>>
>>>
>>
>> ___
>> Mailing list: https://launchpad.net/~openstack
>> Post to : openstack@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~openstack
>> More help   : https://help.launchpad.net/ListHelp
>>
>>
>
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] Can I create a VM with 2 NICs while there is only one network?

2013-05-30 Thread Aaron Rosen

Yes, I understand you can do this without causing a loop. Why not use the
same interface to send and receive traffic?


On Thu, May 30, 2013 at 1:16 AM, Liu Wenmao  wrote:

> Rosen:
>
> I want to implement a virutal IPS(intrusion protection system) on L2
> layer, so the input interface and the output interface should be on the
> same network.
>
> Now I manually modify the packet vlan using OpenFlow protocol at the two
> NICs, so that the loop won't happen.
>
>
> On Thu, May 30, 2013 at 2:11 PM, Aaron Rosen  wrote:
>
>> I still don't see why you want to have two nics on the same L2?  We don't
>> allow this because we don't want  to allow a tenants to bridge them
>> creating a loop in the network.
>>
>> Aaron
>>
>>
>> On Thu, May 23, 2013 at 8:18 PM, Liu Wenmao  wrote:
>>
>>> Hello:
>>>
>>> I have a network with a subnet, I want create a VM with one NIC
>>> connected with this subnet, with one or two extra NIC left, because I want
>>> to do some more things such as intrusion protection
>>>
>>> I wonder is it possible to create a VM with more NICs than its connected
>>> network?
>>>
>>> ___
>>> Mailing list: https://launchpad.net/~openstack
>>> Post to : openstack@lists.launchpad.net
>>> Unsubscribe : https://launchpad.net/~openstack
>>> More help   : https://help.launchpad.net/ListHelp
>>>
>>>
>>
>
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] Reg: Nova System Architecture

2013-05-30 Thread Aaron Rosen

No, you would have to start several instances one on each compute node and
implement that distribution in your application.


On Thu, May 30, 2013 at 6:46 AM, Dhanasekaran Anbalagan
wrote:

> HI Salvatore,
>
> It's possible start an instance which is distributed across several
> nodes. it's my goal.
>
> please guide me.
>
> -Dhanasekaran.
>
> Did I learn something today? If not, I wasted it.
>
>
> On Thu, May 30, 2013 at 9:33 AM, Salvatore Orlando wrote:
>
>> Hi Dhanasekaran,
>>
>> It seems to me that the 'shared nothing' architecture [1] probably has
>> little to do with your need, as it refers to the various nova nodes, rather
>> than instances.
>> It looks like you want to start an instance which is distributed across
>> several nodes. Is this your goal?
>>
>> Salvatore
>>
>> [1] http://en.wikipedia.org/wiki/Shared_nothing_architecture
>>
>>
>> On 30 May 2013 14:20, Dhanasekaran Anbalagan  wrote:
>>
>>> Hi Guys,
>>>
>>> Nova actually developed based on sharing nothing arch. But in my
>>> question is I have five computer node. each compute node 8 cores.
>>>
>>> It's possible can I  start instance with  32 core machine.
>>>
>>> Please guide me.
>>>
>>> -Dhanasekaran
>>> Did I learn something today? If not, I wasted it.
>>>
>>> ___
>>> Mailing list: https://launchpad.net/~openstack
>>> Post to : openstack@lists.launchpad.net
>>> Unsubscribe : https://launchpad.net/~openstack
>>> More help   : https://help.launchpad.net/ListHelp
>>>
>>>
>>
>
> ___
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>
>
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] Can I create a VM with 2 NICs while there is only one network?

2013-05-29 Thread Aaron Rosen

Hi,

I still don't see why you want to have two nics on the same L2?  We don't
allow this because we don't want  to allow a tenants to bridge them
creating a loop in the network.

Aaron


On Thu, May 23, 2013 at 8:18 PM, Liu Wenmao  wrote:

> Hello:
>
> I have a network with a subnet, I want create a VM with one NIC connected
> with this subnet, with one or two extra NIC left, because I want to do some
> more things such as intrusion protection
>
> I wonder is it possible to create a VM with more NICs than its connected
> network?
>
> ___
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>
>
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] How to assign External ip to vm without quantum L3 agent

2013-05-29 Thread Aaron Rosen

No but the provider network extention does provide a way to do this that
might work for your usecase:
http://docs.openstack.org/trunk/openstack-network/admin/content/provider_networks.html


On Wed, May 29, 2013 at 11:02 PM, Veera Reddy  wrote:

> Hi,
>
> IS there any way to access VM from external network without using quantum
> l3 agent.
>
> --
> Regards,
> VeeraReddy.B
>
>
> ___
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>
>
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] more info on this raise exception.NoValidHost

2013-05-20 Thread Aaron Rosen

Usually means that the instance trying to be launched can't be scheduled to
any nova-compute nodes. The log message should include a reason why though.




On Mon, May 20, 2013 at 12:06 PM, Remo Mattei  wrote:

> Hello everyone,
>
> I wonder if someone can give me a more detail overview about the raise
> exception.NoValidHost
> on what does raise mean.
>
> Thanks
> Remo
>
> ___
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>
>
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] Cannot start nova-api service

2013-05-15 Thread Aaron Rosen

Weird looks fine to me. What happens if you do:

sudo service nova-api stop;

and then run nova-api in the foreground. $ nova-api

Aaron


On Wed, May 15, 2013 at 10:58 AM, Sam Su  wrote:

> Sure, here are my nova-api.log file and nova.conf file:
> nova-api.loghttp://pastebin.com/24a7ucy1
> nova.conf   http://pastebin.com/wnZAr0Ga
>
> Thanks,
> Sam
>
>
> On Wed, May 15, 2013 at 10:39 AM, Schwartz, Philip Marc (RIS-BCT) <
> philip.schwa...@lexisnexis.com> wrote:
>
>>  Mind sharing your nova.conf with us. You have a misconfiguration of
>> which api’s should be exposed which is causing 2 to use the same port.***
>> *
>>
>> ** **
>>
>> **-**Philip
>>
>> ** **
>>
>> *From:* Openstack [mailto:openstack-bounces+philip.schwartz=
>> lexisnexis@lists.launchpad.net] *On Behalf Of *Aaron Rosen
>> *Sent:* Wednesday, May 15, 2013 1:33 PM
>> *To:* Sam Su
>> *Cc:* openstack
>> *Subject:* Re: [Openstack] Cannot start nova-api service
>>
>> ** **
>>
>> Looks like something is already binding on 8774 (probably nova-api :)  )
>> What does  lsof -i :8774 say?  Then see what process is running.
>>
>> For example:
>>
>> arosen@arosen-desktop:~$ lsof -i :8774
>> COMMAND   PID   USER   FD   TYPE   DEVICE SIZE/OFF NODE NAME
>> python  13936 arosen6u  IPv4 32808940  0t0  TCP *:8774 (LISTEN)
>> python  13945 arosen6u  IPv4 32808940  0t0  TCP *:8774 (LISTEN)
>> python  13946 arosen6u  IPv4 32808940  0t0  TCP *:8774 (LISTEN)
>> arosen@arosen-desktop:~$ ps -eaf | grep 13936
>> arosen4822 14986  0 10:27 pts/62   00:00:00 grep --color=auto 13936
>> arosen   13936 13797  0 May14 pts/68   00:00:00 python bin/nova-api
>> arosen   13944 13936  0 May14 pts/68   00:00:00 python bin/nova-api
>> arosen   13945 13936  0 May14 pts/68   00:00:00 python bin/nova-api
>> arosen   13946 13936  0 May14 pts/68   00:00:00 python bin/nova-api
>>
>> ** **
>>
>> On Wed, May 15, 2013 at 10:24 AM, Sam Su  wrote:
>>
>> Hi,
>>
>> ** **
>>
>> I installed an Openstack Grizzly cluster based on Ubuntu 12.04, there are
>> 1 control node, 1 database node, 1 quantum network node and 1 compute node,
>> I list all installed services at the control node and the database node.*
>> ***
>>
>> Control node: nova-api, nova-scheduler, nova-consoleauth,
>> nova-novncproxy, nova-conductor, rabbitmq, quantum-server, keystone,
>> horizon, glance
>>
>> Database node: mysql
>>
>> ** **
>>
>> All of the nova services are running, however, nova-api is not running.
>> When I manually start nova-api service, I will get an error as below. Can
>> someone give me some advises?
>>
>> ** **
>>
>> Any help is appreciated.
>>
>> ** **
>>
>> ** **
>>
>> >>> From /etc/log/nova/nova-api.log
>>
>> *2013-05-15 09:53:53.920 7233 INFO nova.network.driver [-] Loading
>> network driver 'nova.network.linux_net'*
>>
>> *2013-05-15 09:53:53.922 7239 INFO nova.osapi_compute.wsgi.server [-]
>> (7239) wsgi starting up on http://0.0.0.0:8774/*
>>
>> *2013-05-15 09:53:53.928 7233 CRITICAL nova [-] [Errno 99] Cannot assign
>> requested address*
>>
>> *2013-05-15 09:53:53.928 7233 TRACE nova Traceback (most recent call
>> last):*
>>
>> *2013-05-15 09:53:53.928 7233 TRACE nova   File "/usr/bin/nova-api",
>> line 61, in *
>>
>> *2013-05-15 09:53:53.928 7233 TRACE nova server =
>> service.WSGIService(api, use_ssl=should_use_ssl)*
>>
>> *2013-05-15 09:53:53.928 7233 TRACE nova   File
>> "/usr/lib/python2.7/dist-packages/nova/service.py", line 608, in __init__
>> *
>>
>> *2013-05-15 09:53:53.928 7233 TRACE nova max_url_len=max_url_len)
>> *
>>
>> *2013-05-15 09:53:53.928 7233 TRACE nova   File
>> "/usr/lib/python2.7/dist-packages/nova/wsgi.py", line 120, in __init__***
>> **
>>
>> *2013-05-15 09:53:53.928 7233 TRACE nova self._socket =
>> eventlet.listen(bind_addr, family, backlog=backlog)*
>>
>> *2013-05-15 09:53:53.928 7233 TRACE nova   File
>> "/usr/lib/python2.7/dist-packages/eventlet/convenience.py", line 38, in
>> listen*
>>
>> *2013-05-15 09:53:53.928 7233 TRACE nova sock.bind(addr)*
>>
>> *2013-05-15 09:53:53.928 7233 TRACE nova   File
>> "/usr/lib/python2.7/socket.py", line 224, in meth*
>>
&

Re: [Openstack] Cannot start nova-api service

2013-05-15 Thread Aaron Rosen

Looks like something is already binding on 8774 (probably nova-api :)  )
What does  lsof -i :8774 say?  Then see what process is running.

For example:

arosen@arosen-desktop:~$ lsof -i :8774
COMMAND   PID   USER   FD   TYPE   DEVICE SIZE/OFF NODE NAME
python  13936 arosen6u  IPv4 32808940  0t0  TCP *:8774 (LISTEN)
python  13945 arosen6u  IPv4 32808940  0t0  TCP *:8774 (LISTEN)
python  13946 arosen6u  IPv4 32808940  0t0  TCP *:8774 (LISTEN)
arosen@arosen-desktop:~$ ps -eaf | grep 13936
arosen4822 14986  0 10:27 pts/62   00:00:00 grep --color=auto 13936
arosen   13936 13797  0 May14 pts/68   00:00:00 python bin/nova-api
arosen   13944 13936  0 May14 pts/68   00:00:00 python bin/nova-api
arosen   13945 13936  0 May14 pts/68   00:00:00 python bin/nova-api
arosen   13946 13936  0 May14 pts/68   00:00:00 python bin/nova-api



On Wed, May 15, 2013 at 10:24 AM, Sam Su  wrote:

> Hi,
>
> I installed an Openstack Grizzly cluster based on Ubuntu 12.04, there are
> 1 control node, 1 database node, 1 quantum network node and 1 compute node,
> I list all installed services at the control node and the database node.
> Control node: nova-api, nova-scheduler, nova-consoleauth, nova-novncproxy,
> nova-conductor, rabbitmq, quantum-server, keystone, horizon, glance
> Database node: mysql
>
> All of the nova services are running, however, nova-api is not running.
> When I manually start nova-api service, I will get an error as below. Can
> someone give me some advises?
>
> Any help is appreciated.
>
>
> >>> From /etc/log/nova/nova-api.log
> *2013-05-15 09:53:53.920 7233 INFO nova.network.driver [-] Loading
> network driver 'nova.network.linux_net'*
> *2013-05-15 09:53:53.922 7239 INFO nova.osapi_compute.wsgi.server [-]
> (7239) wsgi starting up on http://0.0.0.0:8774/*
> *2013-05-15 09:53:53.928 7233 CRITICAL nova [-] [Errno 99] Cannot assign
> requested address*
> *2013-05-15 09:53:53.928 7233 TRACE nova Traceback (most recent call
> last):*
> *2013-05-15 09:53:53.928 7233 TRACE nova   File "/usr/bin/nova-api", line
> 61, in *
> *2013-05-15 09:53:53.928 7233 TRACE nova server =
> service.WSGIService(api, use_ssl=should_use_ssl)*
> *2013-05-15 09:53:53.928 7233 TRACE nova   File
> "/usr/lib/python2.7/dist-packages/nova/service.py", line 608, in __init__*
> *2013-05-15 09:53:53.928 7233 TRACE nova max_url_len=max_url_len)*
> *2013-05-15 09:53:53.928 7233 TRACE nova   File
> "/usr/lib/python2.7/dist-packages/nova/wsgi.py", line 120, in __init__*
> *2013-05-15 09:53:53.928 7233 TRACE nova self._socket =
> eventlet.listen(bind_addr, family, backlog=backlog)*
> *2013-05-15 09:53:53.928 7233 TRACE nova   File
> "/usr/lib/python2.7/dist-packages/eventlet/convenience.py", line 38, in
> listen*
> *2013-05-15 09:53:53.928 7233 TRACE nova sock.bind(addr)*
> *2013-05-15 09:53:53.928 7233 TRACE nova   File
> "/usr/lib/python2.7/socket.py", line 224, in meth*
> *2013-05-15 09:53:53.928 7233 TRACE nova return
> getattr(self._sock,name)(*args)*
> *2013-05-15 09:53:53.928 7233 TRACE nova error: [Errno 99] Cannot assign
> requested address*
> *2013-05-15 09:53:53.928 7233 TRACE nova *
> *2013-05-15 09:53:54.023 7239 INFO nova.service [-] Parent process has
> died unexpectedly, exiting*
> *2013-05-15 09:53:54.023 7238 INFO nova.service [-] Parent process has
> died unexpectedly, exiting*
> *2013-05-15 09:53:54.024 7238 INFO nova.wsgi [-] Stopping WSGI server.*
> *2013-05-15 09:53:54.024 7239 INFO nova.wsgi [-] Stopping WSGI server.*
>
> I also post my nova-api.log file and nova.conf file at pastebin.com, here
> are the links:
> nova-api.loghttp://pastebin.com/24a7ucy1
> nova.conf   http://pastebin.com/wnZAr0Ga
>
> Thanks,
> Sam
>
>
> ___
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>
>
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] openstack with one NIC (possible?)

2013-05-08 Thread Aaron Rosen

Sure, just use the ip addresses off of the one interface you have.
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] vm can't connect to remote host (169.254.169.254)

2013-05-08 Thread Aaron Rosen

Is the network you are trying to boot on attached to a router (i.e and can
you ping the default gw)?


On Tue, May 7, 2013 at 11:59 PM, zengshan2008 wrote:

> **
> **
>
> Hi all,
>
> I've installed openstack using quantum by the guide
> https://github.com/mseknibilel/OpenStack-Folsom-Install-guide/blob/master/OpenStack_Folsom_Install_Guide_WebVersion.rst
> In my environment, I have a controller node, a network node and a compute 
> node, I am using openvswitch plugin and everything looks fine, but the 
> following logs in the vm console make me crazy. can anybody help me out?
>
> May  8 00:45:57 cirros kern.info kernel: [2.468239] eth0: IPv6 duplicate 
> address fe80::f816:3eff:fe80:636f detected!
>  debug end   ##
> cloud-setup: failed to read iid from metadata. tried 30
> WARN: /etc/rc3.d/S45-cloud-setup failed
> Starting dropbear sshd: generating rsa key... generating dsa key... OK
> = cloud-final: system completely up in 41.24 seconds 
> wget: can't connect to remote host (169.254.169.254): Network is unreachable
> wget: can't connect to remote host (169.254.169.254): Network is unreachable
> wget: can't connect to remote host (169.254.169.254): Network is unreachable
>   instance-id:
>   public-ipv4:
>   local-ipv4 :
> wget: can't connect to remote host (169.254.169.254): Network is unreachable
> cloud-userdata: failed to read instance id
> WARN: /etc/rc3.d/S99-cloud-userdata failed
>
>
> 2013-05-08
> --
>  zengshan2008
> **
>
> ___
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>
>
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] Nested Open vSwitch Bridges

2013-04-30 Thread Aaron Rosen

Also, the security group stuff locks down the port to be the mac+ip of the
quantum port mac+ip. If you create a new bridge and add ethX to it you'll
also have to set the mac on your bridge to be the same as ethX (which is
the mac that quantum handed out).

Aaron


On Tue, Apr 30, 2013 at 4:25 PM, Salvatore Orlando wrote:

> Hi Joe,
>
> are you using the OVS plugin with GRE overlays?
> In that case your problem might be the fact that the plugin pushes a OVS
> flow entry which applies the 'local' vlan tag only to packet directed to
> the VM's mac [1]
>
> To me, this does not look like a bug; it's probably intended behaviour, as
> it kind of implements mac spoofing prevention. In the future we might also
> expect stricter anti-spoof checking; on the other side a change
> for administratively enabling promiscuos mode might be welcome - this
> should allow you to do nested OVS.
>
> Salvatore
>
> [1]
> https://github.com/openstack/quantum/blob/master/quantum/plugins/openvswitch/agent/ovs_quantum_agent.py#L448
>
>
>
> On 30 April 2013 22:08, Joe Topjian  wrote:
>
>> Hello,
>>
>> I have OpenStack (Grizzly) up and running with Quantum. I'm using the
>> Open vSwitch plugin, per-tenant routing, and network namespaces. As far as
>> I'm aware, this is all set up correctly as instances that I create are able
>> to retrieve an IP address via DHCP, reach the metadata server, and reach
>> the outside internet.
>>
>> The issue that I'm running into is that when I install Open vSwitch on
>> the instance itself, I'm unable to create working bridges. For example:
>>
>> ovs-vsctl add-br br-eth0
>> ovs-vsctl add-port br-eth0 eth0
>> (swap IPs from eth0 to br-eth0, kill dhcp, etc etc)
>>
>> Traffic isn't flowing properly, though.
>>
>> If I run a continuous ping and run tcpdump on both the instance and the
>> tap interface on the controller, I see arp requests going out of the
>> instance, being received on the tap interface, the tap interface sending a
>> reply, but the reply never reaching the instance.
>>
>> However, I have found that if I create a bridge with the same MAC as the
>> interface that I'm adding to the bridge, traffic flows correctly:
>>
>> ovs-vsctl set bridge br-eth0 other-config:hwaddr=aa:bb:cc:00:11:22
>>
>> My best guess is that there's something (L2) blocking the flow of
>> traffic, but I'm not exactly sure where to start looking. I think it's safe
>> to assume that Open vSwitch on the OpenStack servers is doing the blocking
>> but I think it's Quantum that's implementing the blocking since if I use
>> Open vSwitch with nova-network, this problem doesn't happen.
>>
>> Does anyone have any pointers? Or even a fix?
>>
>> Thanks,
>> Joe
>>
>> --
>> Joe Topjian
>> Systems Administrator
>> Cybera Inc.
>>
>> www.cybera.ca
>>
>> Cybera is a not-for-profit organization that works to spur and support
>> innovation, for the economic benefit of Alberta, through the use
>> of cyberinfrastructure.
>>
>> ___
>> Mailing list: https://launchpad.net/~openstack
>> Post to : openstack@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~openstack
>> More help   : https://help.launchpad.net/ListHelp
>>
>>
>
> ___
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>
>
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] error while spawning vm

2013-04-29 Thread Aaron Rosen

>From this error it looks  you don't have brctl in any of the filters in
/etc/nova/*filters:


2013-04-29 19:17:33.640 7974 TRACE nova.virt.libvirt.vif [instance:
b5317dbd-bd85-4cf7-bbf0-cc653fa8c425] Stdout: '/usr/bin/nova-rootwrap:
Unauthorized command: brctl delif qbr8b7fa98b-60 qvb8b7fa98b-60 (no filter
matched)\n'

What's the output of:

# sudo grep brctl /etc/nova/rootwrap.d/*   # <-- should match mine
/etc/nova/rootwrap.d/compute.filters:# nova/network/linux_net.py: 'brctl',
'addbr', bridge
/etc/nova/rootwrap.d/compute.filters:# nova/network/linux_net.py: 'brctl',
'setfd', bridge, 0
/etc/nova/rootwrap.d/compute.filters:# nova/network/linux_net.py: 'brctl',
'stp', bridge, 'off'
/etc/nova/rootwrap.d/compute.filters:# nova/network/linux_net.py: 'brctl',
'addif', bridge, interface
/etc/nova/rootwrap.d/compute.filters:brctl: CommandFilter, brctl, root
/etc/nova/rootwrap.d/network.filters:# nova/network/linux_net.py: 'brctl',
'addbr', bridge
/etc/nova/rootwrap.d/network.filters:# nova/network/linux_net.py: 'brctl',
'setfd', bridge, 0
/etc/nova/rootwrap.d/network.filters:# nova/network/linux_net.py: 'brctl',
'stp', bridge, 'off'
/etc/nova/rootwrap.d/network.filters:# nova/network/linux_net.py: 'brctl',
'addif', bridge, interface
/etc/nova/rootwrap.d/network.filters:brctl: CommandFilter, brctl, root





On Mon, Apr 29, 2013 at 10:21 AM, Arindam Choudhury wrote:

> Hi,
>
> My setup is:
> # nova-manage service list
> Binary   Host Zone
> Status State Updated_At
> nova-conductor   aopcsos  internal
> enabled:-)   2013-04-29 17:10:58
> nova-console aopcsos  internal
> enabled:-)   2013-04-29 17:10:58
> nova-scheduler   aopcsos  internal
> enabled:-)   2013-04-29 17:10:58
> nova-certaopcso1  internal
> enabled:-)   2013-04-29 17:11:03
> nova-compute aopcso1  nova
> enabled:-)   2013-04-29 17:10:55
>
> but when i try to spawn a vm, I always get an error:
>
> 32ae03ff9b44a85426] [instance: b5317dbd-bd85-4cf7-bbf0-cc653fa8c425]
> Starting instance...
> 2013-04-29 19:17:27.433 AUDIT nova.compute.claims
> [req-909247fd-b461-46d6-8b90-bfb0617c7b3a d73c9e93ac3a40d693b4864b73496fdd
> b6d37008724b4a32ae03ff9b44a85426] [instance:
> b5317dbd-bd85-4cf7-bbf0-cc653fa8c425] Attempting claim: memory 512 MB, disk
> 0 GB, VCPUs 1
> 2013-04-29 19:17:27.434 AUDIT nova.compute.claims
> [req-909247fd-b461-46d6-8b90-bfb0617c7b3a d73c9e93ac3a40d693b4864b73496fdd
> b6d37008724b4a32ae03ff9b44a85426] [instance:
> b5317dbd-bd85-4cf7-bbf0-cc653fa8c425] Total Memory: 7984 MB, used: 512 MB
> 2013-04-29 19:17:27.434 AUDIT nova.compute.claims
> [req-909247fd-b461-46d6-8b90-bfb0617c7b3a d73c9e93ac3a40d693b4864b73496fdd
> b6d37008724b4a32ae03ff9b44a85426] [instance:
> b5317dbd-bd85-4cf7-bbf0-cc653fa8c425] Memory limit: 11976 MB, free: 11464 MB
> 2013-04-29 19:17:27.435 AUDIT nova.compute.claims
> [req-909247fd-b461-46d6-8b90-bfb0617c7b3a d73c9e93ac3a40d693b4864b73496fdd
> b6d37008724b4a32ae03ff9b44a85426] [instance:
> b5317dbd-bd85-4cf7-bbf0-cc653fa8c425] Total Disk: 18 GB, used: 0 GB
> 2013-04-29 19:17:27.435 AUDIT nova.compute.claims
> [req-909247fd-b461-46d6-8b90-bfb0617c7b3a d73c9e93ac3a40d693b4864b73496fdd
> b6d37008724b4a32ae03ff9b44a85426] [instance:
> b5317dbd-bd85-4cf7-bbf0-cc653fa8c425] Disk limit not specified, defaulting
> to unlimited
> 2013-04-29 19:17:27.436 AUDIT nova.compute.claims
> [req-909247fd-b461-46d6-8b90-bfb0617c7b3a d73c9e93ac3a40d693b4864b73496fdd
> b6d37008724b4a32ae03ff9b44a85426] [instance:
> b5317dbd-bd85-4cf7-bbf0-cc653fa8c425] Total CPU: 8 VCPUs, used: 0 VCPUs
> 2013-04-29 19:17:27.436 AUDIT nova.compute.claims
> [req-909247fd-b461-46d6-8b90-bfb0617c7b3a d73c9e93ac3a40d693b4864b73496fdd
> b6d37008724b4a32ae03ff9b44a85426] [instance:
> b5317dbd-bd85-4cf7-bbf0-cc653fa8c425] CPU limit not specified, defaulting
> to unlimited
> 2013-04-29 19:17:27.436 AUDIT nova.compute.claims
> [req-909247fd-b461-46d6-8b90-bfb0617c7b3a d73c9e93ac3a40d693b4864b73496fdd
> b6d37008724b4a32ae03ff9b44a85426] [instance:
> b5317dbd-bd85-4cf7-bbf0-cc653fa8c425] Claim successful
> 2013-04-29 19:17:30.663 INFO nova.virt.libvirt.driver
> [req-909247fd-b461-46d6-8b90-bfb0617c7b3a d73c9e93ac3a40d693b4864b73496fdd
> b6d37008724b4a32ae03ff9b44a85426] [instance:
> b5317dbd-bd85-4cf7-bbf0-cc653fa8c425] Creating image
> 2013-04-29 19:17:30.841 INFO nova.virt.libvirt.firewall
> [req-909247fd-b461-46d6-8b90-bfb0617c7b3a d73c9e93ac3a40d693b4864b73496fdd
> b6d37008724b4a32ae03ff9b44a85426] [instance:
> b5317dbd-bd85-4cf7-bbf0-cc653fa8c425] Called setup_basic_filtering in
> nwfilter
> 2013-04-29 19:17:30.842 INFO nova.virt.libvirt.firewall
> [req-909247fd-b461-46d6-8b90-bfb0617c7b3a d73c9e93ac3a40d693b4864b73496fdd
> b6d37008724b4a32ae03ff9b44a85426] [instance:
> b5317dbd-bd85-4cf7-bbf0-cc653fa8c425] Ensuring static filters
> 2013-04-29 19

Re: [Openstack] [openstack][quantum] stuck subnet

2013-04-25 Thread Aaron Rosen

You should be able to delete the floating ip via an admin user and then
delete the subnet.

Aaron


On Thu, Apr 25, 2013 at 12:13 PM, Steve Heistand wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> so I had a tenant that was assigned a floating IP. I deleted the project
> before
> I freed up the floating IP. Now I cant clean up a subnet as it still thinks
> there is an IP attached to it.
> any ideas how to get rid of a subnet when it thinks there is a float
> assigned to it that is owned by a tenant that doesnt exist?
>
> thanks
> s
>
> - --
> 
>  Steve Heistand  NASA Ames Research Center
>  email: steve.heist...@nasa.gov  Steve Heistand/Mail Stop 258-6
>  ph: (650) 604-4369  Bldg. 258, Rm. 232-5
>  Scientific & HPC ApplicationP.O. Box 1
>  Development/OptimizationMoffett Field, CA 94035-0001
> 
>  "Any opinions expressed are those of our alien overlords, not my own."
>
> # For Remedy#
> #Action: Resolve#
> #Resolution: Resolved   #
> #Reason: No Further Action Required #
> #Tier1: User Code   #
> #Tier2: Other   #
> #Tier3: Assistance  #
> #Notification: None #
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v2.0.14 (GNU/Linux)
>
> iEYEARECAAYFAlF5gEQACgkQoBCTJSAkVrHFOgCg6rIHRsD2BAoi5xrq5eM553qD
> accAoOcRHeSXdmJ8HlDAYGgHRpKYuEXm
> =zq/V
> -END PGP SIGNATURE-
>
> ___
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] [OpenStack] Grizzly: Does metadata service work when overlapping IPs is enabled

2013-04-24 Thread Aaron Rosen

 |
> | net1 network| 192.168.2.3, 10.5.12.23
>|
> | progress| 0
>|
> | OS-EXT-STS:power_state  | 1
>|
> | OS-EXT-AZ:availability_zone | nova
>   |
> | config_drive|
>|
>
> +-+--+
> root@openstack-dev:~# ip netns
> qdhcp-c4a7475e-e33f-47d0-a6ff-d0cf50c012d7
> qrouter-d9e87e85-8410-4398-9ddd-2dbc36f4b593
>
> root@openstack-dev:~# ip netns exec
> qrouter-d9e87e85-8410-4398-9ddd-2dbc36f4b593 route -n
> Kernel IP routing table
> Destination Gateway Genmask Flags Metric RefUse
> Iface
> 0.0.0.0 10.5.12.1   0.0.0.0 UG0  00
> qg-193bb8ee-f5
> 10.5.12.0   0.0.0.0 255.255.255.0   U 0  00
> qg-193bb8ee-f5
> 192.168.2.0 0.0.0.0 255.255.255.0   U 0  00
> qr-59e69986-6e
> root@openstack-dev:~# ip netns exec
> qrouter-d9e87e85-8410-4398-9ddd-2dbc36f4b593 ifconfig
> loLink encap:Local Loopback
>   inet addr:127.0.0.1  Mask:255.0.0.0
>   inet6 addr: ::1/128 Scope:Host
>   UP LOOPBACK RUNNING  MTU:16436  Metric:1
>   RX packets:0 errors:0 dropped:0 overruns:0 frame:0
>   TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
>   collisions:0 txqueuelen:0
>   RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
>
> qg-193bb8ee-f5 Link encap:Ethernet  HWaddr fa:16:3e:91:3d:c0
>   inet addr:10.5.12.21  Bcast:10.5.12.255  Mask:255.255.255.0
>   inet6 addr: fe80::f816:3eff:fe91:3dc0/64 Scope:Link
>   UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>   RX packets:121097 errors:0 dropped:104 overruns:0 frame:0
>   TX packets:38777 errors:0 dropped:0 overruns:0 carrier:0
>   collisions:0 txqueuelen:0
>   RX bytes:88797723 (88.7 MB)  TX bytes:3112197 (3.1 MB)
>
> qr-59e69986-6e Link encap:Ethernet  HWaddr fa:16:3e:91:ee:76
>   inet addr:192.168.2.1  Bcast:192.168.2.255  Mask:255.255.255.0
>   inet6 addr: fe80::f816:3eff:fe91:ee76/64 Scope:Link
>   UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>   RX packets:101615 errors:0 dropped:0 overruns:0 frame:0
>   TX packets:68028 errors:0 dropped:0 overruns:0 carrier:0
>   collisions:0 txqueuelen:0
>   RX bytes:12476279 (12.4 MB)  TX bytes:83025755 (83.0 MB)
>
> root@openstack-dev:~#
>
> Regards,
> Balu
>
>
>
> On Wed, Apr 24, 2013 at 11:32 PM, Aaron Rosen  wrote:
>
>> Can you show us a quantum subnet-show for the subnet your vm has an ip
>> on. Is it possible that you added a host_route to the subnet for
>> 169.254/16?
>>
>> Or could you try this image:
>> http://cloud-images.ubuntu.com/precise/current/precise-server-cloudimg-amd64-disk1.img
>>
>>
>> On Wed, Apr 24, 2013 at 1:06 AM, Balamurugan V G > > wrote:
>>
>>> I booted a Ubuntu Image in which I had made sure that there was no
>>> pre-existing route for 169,254.0.0/16. But its getting the route from DHCP
>>> once its boots up. So its the DHCP server which is sending this route to
>>> the VM.
>>>
>>> Regards,
>>> Balu
>>>
>>>
>>> On Wed, Apr 24, 2013 at 12:47 PM, Balamurugan V G <
>>> balamuruga...@gmail.com> wrote:
>>>
>>>> Hi Salvatore,
>>>>
>>>> Thanks for the response. I do not have enable_isolated_metadata_proxy
>>>> anywhere under /etc/quantum and /etc/nova. The closest I see is
>>>> 'enable_isolated_metadata' in /etc/quantum/dhcp_agent.ini and even that is
>>>> commented out. What do you mean by link-local address?
>>>>
>>>> Like you said, I suspect that the image has the route. This was was a
>>>> snapshot taken in a Folsom setup. So its possible that Folsom has injected
>>>> this route and when I took the snapshot, it became part of the snapshot. I
>>>> then copied over this snapshot to a new Grizzly setup. Let me check the
>>>> image and remove it from the image if it has the route. Thanks for the hint
>>>> again.
>>>>
>>>> Regards,
>>>> Balu
>>>>
>>>>
>>>>
>>>> On Wed, Apr 24, 2013 at 12:38 PM, Salvatore Orlando <
>>>> sorla...@nicira.com> wrote:
>>>>

Re: [Openstack] [OpenStack] Grizzly: Does metadata service work when overlapping IPs is enabled

2013-04-24 Thread Aaron Rosen

Can you show us a quantum subnet-show for the subnet your vm has an ip on.
Is it possible that you added a host_route to the subnet for 169.254/16?

Or could you try this image:
http://cloud-images.ubuntu.com/precise/current/precise-server-cloudimg-amd64-disk1.img


On Wed, Apr 24, 2013 at 1:06 AM, Balamurugan V G wrote:

> I booted a Ubuntu Image in which I had made sure that there was no
> pre-existing route for 169,254.0.0/16. But its getting the route from DHCP
> once its boots up. So its the DHCP server which is sending this route to
> the VM.
>
> Regards,
> Balu
>
>
> On Wed, Apr 24, 2013 at 12:47 PM, Balamurugan V G  > wrote:
>
>> Hi Salvatore,
>>
>> Thanks for the response. I do not have enable_isolated_metadata_proxy
>> anywhere under /etc/quantum and /etc/nova. The closest I see is
>> 'enable_isolated_metadata' in /etc/quantum/dhcp_agent.ini and even that is
>> commented out. What do you mean by link-local address?
>>
>> Like you said, I suspect that the image has the route. This was was a
>> snapshot taken in a Folsom setup. So its possible that Folsom has injected
>> this route and when I took the snapshot, it became part of the snapshot. I
>> then copied over this snapshot to a new Grizzly setup. Let me check the
>> image and remove it from the image if it has the route. Thanks for the hint
>> again.
>>
>> Regards,
>> Balu
>>
>>
>>
>> On Wed, Apr 24, 2013 at 12:38 PM, Salvatore Orlando 
>> wrote:
>>
>>> The dhcp agent will set a route to 169.254.0.0/16 if
>>> enable_isolated_metadata_proxy=True.
>>> In that case the dhcp port ip will be the nexthop for that route.
>>>
>>> Otherwise, it might be your image might have a 'builtin' route to such
>>> cidr.
>>> What's your nexthop for the link-local address?
>>>
>>> Salvatore
>>>
>>>
>>> On 24 April 2013 08:00, Balamurugan V G  wrote:
>>>
>>>> Thanks for the hint Aaron. When I deleted the route for 169.254.0.0/16from 
>>>> the VMs routing table, I could access the metadata service!
>>>>
>>>> The route for 169.254.0.0/16 is added automatically when the instance
>>>> boots up, so I assume its coming from the DHCP. Any idea how this can be
>>>> suppressed?
>>>>
>>>> Strangely though, I do not see this route in a WindowsXP VM booted in
>>>> the same network as the earlier Ubuntu VM and the Windows VM can reach the
>>>> metadata service with out me doing anything. The issue is with the Ubuntu
>>>> VM.
>>>>
>>>> Thanks,
>>>> Balu
>>>>
>>>>
>>>>
>>>> On Wed, Apr 24, 2013 at 12:18 PM, Aaron Rosen wrote:
>>>>
>>>>> The vm should not have a routing table entry for 169.254.0.0/16  if
>>>>> it does i'm not sure how it got there unless it was added by something
>>>>> other than dhcp. It seems like that is your problem as the vm is arping
>>>>> directly for that address rather than the default gw.
>>>>>
>>>>>
>>>>> On Tue, Apr 23, 2013 at 11:34 PM, Balamurugan V G <
>>>>> balamuruga...@gmail.com> wrote:
>>>>>
>>>>>> Thanks Aaron.
>>>>>>
>>>>>> I am perhaps not configuring it right then. I am using Ubuntu 12.04
>>>>>> host and even my guest(VM) is Ubuntu 12.04 but metadata not working. I 
>>>>>> see
>>>>>> that the VM's routing table has an entry for 169.254.0.0/16 but I
>>>>>> cant ping 169.254.169.254 from the VM. I am using a single node setup 
>>>>>> with
>>>>>> two NICs.10.5.12.20 is the public IP, 10.5.3.230 is the management IP
>>>>>>
>>>>>> These are my metadata related configurations.
>>>>>>
>>>>>> */etc/nova/nova.conf *
>>>>>> metadata_host = 10.5.12.20
>>>>>> metadata_listen = 127.0.0.1
>>>>>> metadata_listen_port = 8775
>>>>>> metadata_manager=nova.api.manager.MetadataManager
>>>>>> service_quantum_metadata_proxy = true
>>>>>> quantum_metadata_proxy_shared_secret = metasecret123
>>>>>>
>>>>>> */etc/quantum/quantum.conf*
>>>>>> allow_overlapping_ips = True
>>>>>>
>>>>>> */etc/quantum/l3_agent.ini*
>>>>>> use_namespac

Re: [Openstack] [OpenStack] Grizzly: Does metadata service work when overlapping IPs is enabled

2013-04-24 Thread Aaron Rosen

Yup,  That's only if your subnet does not have a default gateway set.
Providing the output of route -n would be helpful .


On Wed, Apr 24, 2013 at 12:08 AM, Salvatore Orlando wrote:

> The dhcp agent will set a route to 169.254.0.0/16 if
> enable_isolated_metadata_proxy=True.
> In that case the dhcp port ip will be the nexthop for that route.
>
> Otherwise, it might be your image might have a 'builtin' route to such
> cidr.
> What's your nexthop for the link-local address?
>
> Salvatore
>
>
> On 24 April 2013 08:00, Balamurugan V G  wrote:
>
>> Thanks for the hint Aaron. When I deleted the route for 169.254.0.0/16from 
>> the VMs routing table, I could access the metadata service!
>>
>> The route for 169.254.0.0/16 is added automatically when the instance
>> boots up, so I assume its coming from the DHCP. Any idea how this can be
>> suppressed?
>>
>> Strangely though, I do not see this route in a WindowsXP VM booted in the
>> same network as the earlier Ubuntu VM and the Windows VM can reach the
>> metadata service with out me doing anything. The issue is with the Ubuntu
>> VM.
>>
>> Thanks,
>> Balu
>>
>>
>>
>> On Wed, Apr 24, 2013 at 12:18 PM, Aaron Rosen  wrote:
>>
>>> The vm should not have a routing table entry for 169.254.0.0/16  if it
>>> does i'm not sure how it got there unless it was added by something other
>>> than dhcp. It seems like that is your problem as the vm is arping directly
>>> for that address rather than the default gw.
>>>
>>>
>>> On Tue, Apr 23, 2013 at 11:34 PM, Balamurugan V G <
>>> balamuruga...@gmail.com> wrote:
>>>
>>>> Thanks Aaron.
>>>>
>>>> I am perhaps not configuring it right then. I am using Ubuntu 12.04
>>>> host and even my guest(VM) is Ubuntu 12.04 but metadata not working. I see
>>>> that the VM's routing table has an entry for 169.254.0.0/16 but I cant
>>>> ping 169.254.169.254 from the VM. I am using a single node setup with two
>>>> NICs.10.5.12.20 is the public IP, 10.5.3.230 is the management IP
>>>>
>>>> These are my metadata related configurations.
>>>>
>>>> */etc/nova/nova.conf *
>>>> metadata_host = 10.5.12.20
>>>> metadata_listen = 127.0.0.1
>>>> metadata_listen_port = 8775
>>>> metadata_manager=nova.api.manager.MetadataManager
>>>> service_quantum_metadata_proxy = true
>>>> quantum_metadata_proxy_shared_secret = metasecret123
>>>>
>>>> */etc/quantum/quantum.conf*
>>>> allow_overlapping_ips = True
>>>>
>>>> */etc/quantum/l3_agent.ini*
>>>> use_namespaces = True
>>>> auth_url = http://10.5.3.230:35357/v2.0
>>>> auth_region = RegionOne
>>>> admin_tenant_name = service
>>>> admin_user = quantum
>>>> admin_password = service_pass
>>>> metadata_ip = 10.5.12.20
>>>>
>>>> */etc/quantum/metadata_agent.ini*
>>>> auth_url = http://10.5.3.230:35357/v2.0
>>>> auth_region = RegionOne
>>>> admin_tenant_name = service
>>>> admin_user = quantum
>>>> admin_password = service_pass
>>>> nova_metadata_ip = 127.0.0.1
>>>> nova_metadata_port = 8775
>>>> metadata_proxy_shared_secret = metasecret123
>>>>
>>>>
>>>> I see that /usr/bin/quantum-ns-metadata-proxy process is running. When
>>>> I ping 169.254.169.254 from VM, in the host's router namespace, I see the
>>>> ARP request but no response.
>>>>
>>>> root@openstack-dev:~# ip netns exec
>>>> qrouter-d9e87e85-8410-4398-9ddd-2dbc36f4b593 route -n
>>>> Kernel IP routing table
>>>> Destination Gateway Genmask Flags Metric RefUse
>>>> Iface
>>>> 0.0.0.0 10.5.12.1   0.0.0.0 UG0  00
>>>> qg-193bb8ee-f5
>>>> 10.5.12.0   0.0.0.0 255.255.255.0   U 0  00
>>>> qg-193bb8ee-f5
>>>> 192.168.2.0 0.0.0.0 255.255.255.0   U 0  00
>>>> qr-59e69986-6e
>>>> root@openstack-dev:~# ip netns exec
>>>> qrouter-d9e87e85-8410-4398-9ddd-2dbc36f4b593 tcpdump -i qr-59e69986-6e
>>>> tcpdump: verbose output suppressed, use -v or -vv for full protocol
>>>> decode
>>>> listening on qr-59e69986-6e, link-type EN10MB (Ethernet), capture size
&

Re: [Openstack] [OpenStack] Grizzly: Does metadata service work when overlapping IPs is enabled

2013-04-24 Thread Aaron Rosen

Hrm, I'd do quantum subnet-list and see if you happened to create a subnet
169.254.0.0/16? Otherwise I think there is probably some software in your
vm image that is adding this route. One thing to test is if you delete this
route and then rerun dhclient to see if it's added again via dhcp.


On Wed, Apr 24, 2013 at 12:00 AM, Balamurugan V G
wrote:

> Thanks for the hint Aaron. When I deleted the route for 169.254.0.0/16from 
> the VMs routing table, I could access the metadata service!
>
> The route for 169.254.0.0/16 is added automatically when the instance
> boots up, so I assume its coming from the DHCP. Any idea how this can be
> suppressed?
>
> Strangely though, I do not see this route in a WindowsXP VM booted in the
> same network as the earlier Ubuntu VM and the Windows VM can reach the
> metadata service with out me doing anything. The issue is with the Ubuntu
> VM.
>
> Thanks,
> Balu
>
>
>
> On Wed, Apr 24, 2013 at 12:18 PM, Aaron Rosen  wrote:
>
>> The vm should not have a routing table entry for 169.254.0.0/16  if it
>> does i'm not sure how it got there unless it was added by something other
>> than dhcp. It seems like that is your problem as the vm is arping directly
>> for that address rather than the default gw.
>>
>>
>> On Tue, Apr 23, 2013 at 11:34 PM, Balamurugan V G <
>> balamuruga...@gmail.com> wrote:
>>
>>> Thanks Aaron.
>>>
>>> I am perhaps not configuring it right then. I am using Ubuntu 12.04 host
>>> and even my guest(VM) is Ubuntu 12.04 but metadata not working. I see that
>>> the VM's routing table has an entry for 169.254.0.0/16 but I cant ping
>>> 169.254.169.254 from the VM. I am using a single node setup with two
>>> NICs.10.5.12.20 is the public IP, 10.5.3.230 is the management IP
>>>
>>> These are my metadata related configurations.
>>>
>>> */etc/nova/nova.conf *
>>> metadata_host = 10.5.12.20
>>> metadata_listen = 127.0.0.1
>>> metadata_listen_port = 8775
>>> metadata_manager=nova.api.manager.MetadataManager
>>> service_quantum_metadata_proxy = true
>>> quantum_metadata_proxy_shared_secret = metasecret123
>>>
>>> */etc/quantum/quantum.conf*
>>> allow_overlapping_ips = True
>>>
>>> */etc/quantum/l3_agent.ini*
>>> use_namespaces = True
>>> auth_url = http://10.5.3.230:35357/v2.0
>>> auth_region = RegionOne
>>> admin_tenant_name = service
>>> admin_user = quantum
>>> admin_password = service_pass
>>> metadata_ip = 10.5.12.20
>>>
>>> */etc/quantum/metadata_agent.ini*
>>> auth_url = http://10.5.3.230:35357/v2.0
>>> auth_region = RegionOne
>>> admin_tenant_name = service
>>> admin_user = quantum
>>> admin_password = service_pass
>>> nova_metadata_ip = 127.0.0.1
>>> nova_metadata_port = 8775
>>> metadata_proxy_shared_secret = metasecret123
>>>
>>>
>>> I see that /usr/bin/quantum-ns-metadata-proxy process is running. When I
>>> ping 169.254.169.254 from VM, in the host's router namespace, I see the ARP
>>> request but no response.
>>>
>>> root@openstack-dev:~# ip netns exec
>>> qrouter-d9e87e85-8410-4398-9ddd-2dbc36f4b593 route -n
>>> Kernel IP routing table
>>> Destination Gateway Genmask Flags Metric RefUse
>>> Iface
>>> 0.0.0.0 10.5.12.1   0.0.0.0 UG0  00
>>> qg-193bb8ee-f5
>>> 10.5.12.0   0.0.0.0 255.255.255.0   U 0  00
>>> qg-193bb8ee-f5
>>> 192.168.2.0 0.0.0.0 255.255.255.0   U 0  00
>>> qr-59e69986-6e
>>> root@openstack-dev:~# ip netns exec
>>> qrouter-d9e87e85-8410-4398-9ddd-2dbc36f4b593 tcpdump -i qr-59e69986-6e
>>> tcpdump: verbose output suppressed, use -v or -vv for full protocol
>>> decode
>>> listening on qr-59e69986-6e, link-type EN10MB (Ethernet), capture size
>>> 65535 bytes
>>> ^C23:32:09.638289 ARP, Request who-has 192.168.2.3 tell 192.168.2.1,
>>> length 28
>>> 23:32:09.650043 ARP, Reply 192.168.2.3 is-at fa:16:3e:4f:ad:df (oui
>>> Unknown), length 28
>>> 23:32:15.768942 ARP, Request who-has 169.254.169.254 tell 192.168.2.3,
>>> length 28
>>> 23:32:16.766896 ARP, Request who-has 169.254.169.254 tell 192.168.2.3,
>>> length 28
>>> 23:32:17.766712 ARP, Request who-has 169.254.169.254 tell 192.168.2.3,
>>> length 28
>>> 23:32:18.784195 ARP, Req

Re: [Openstack] [OpenStack] Grizzly: Does metadata service work when overlapping IPs is enabled

2013-04-23 Thread Aaron Rosen

The vm should not have a routing table entry for 169.254.0.0/16  if it does
i'm not sure how it got there unless it was added by something other than
dhcp. It seems like that is your problem as the vm is arping directly for
that address rather than the default gw.


On Tue, Apr 23, 2013 at 11:34 PM, Balamurugan V G
wrote:

> Thanks Aaron.
>
> I am perhaps not configuring it right then. I am using Ubuntu 12.04 host
> and even my guest(VM) is Ubuntu 12.04 but metadata not working. I see that
> the VM's routing table has an entry for 169.254.0.0/16 but I cant ping
> 169.254.169.254 from the VM. I am using a single node setup with two
> NICs.10.5.12.20 is the public IP, 10.5.3.230 is the management IP
>
> These are my metadata related configurations.
>
> */etc/nova/nova.conf *
> metadata_host = 10.5.12.20
> metadata_listen = 127.0.0.1
> metadata_listen_port = 8775
> metadata_manager=nova.api.manager.MetadataManager
> service_quantum_metadata_proxy = true
> quantum_metadata_proxy_shared_secret = metasecret123
>
> */etc/quantum/quantum.conf*
> allow_overlapping_ips = True
>
> */etc/quantum/l3_agent.ini*
> use_namespaces = True
> auth_url = http://10.5.3.230:35357/v2.0
> auth_region = RegionOne
> admin_tenant_name = service
> admin_user = quantum
> admin_password = service_pass
> metadata_ip = 10.5.12.20
>
> */etc/quantum/metadata_agent.ini*
> auth_url = http://10.5.3.230:35357/v2.0
> auth_region = RegionOne
> admin_tenant_name = service
> admin_user = quantum
> admin_password = service_pass
> nova_metadata_ip = 127.0.0.1
> nova_metadata_port = 8775
> metadata_proxy_shared_secret = metasecret123
>
>
> I see that /usr/bin/quantum-ns-metadata-proxy process is running. When I
> ping 169.254.169.254 from VM, in the host's router namespace, I see the ARP
> request but no response.
>
> root@openstack-dev:~# ip netns exec
> qrouter-d9e87e85-8410-4398-9ddd-2dbc36f4b593 route -n
> Kernel IP routing table
> Destination Gateway Genmask Flags Metric RefUse
> Iface
> 0.0.0.0 10.5.12.1   0.0.0.0 UG0  00
> qg-193bb8ee-f5
> 10.5.12.0   0.0.0.0 255.255.255.0   U 0  00
> qg-193bb8ee-f5
> 192.168.2.0 0.0.0.0 255.255.255.0   U 0  00
> qr-59e69986-6e
> root@openstack-dev:~# ip netns exec
> qrouter-d9e87e85-8410-4398-9ddd-2dbc36f4b593 tcpdump -i qr-59e69986-6e
> tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
> listening on qr-59e69986-6e, link-type EN10MB (Ethernet), capture size
> 65535 bytes
> ^C23:32:09.638289 ARP, Request who-has 192.168.2.3 tell 192.168.2.1,
> length 28
> 23:32:09.650043 ARP, Reply 192.168.2.3 is-at fa:16:3e:4f:ad:df (oui
> Unknown), length 28
> 23:32:15.768942 ARP, Request who-has 169.254.169.254 tell 192.168.2.3,
> length 28
> 23:32:16.766896 ARP, Request who-has 169.254.169.254 tell 192.168.2.3,
> length 28
> 23:32:17.766712 ARP, Request who-has 169.254.169.254 tell 192.168.2.3,
> length 28
> 23:32:18.784195 ARP, Request who-has 169.254.169.254 tell 192.168.2.3,
> length 28
>
> 6 packets captured
> 6 packets received by filter
> 0 packets dropped by kernel
> root@openstack-dev:~#
>
>
> Any help will be greatly appreciated.
>
> Thanks,
> Balu
>
>
> On Wed, Apr 24, 2013 at 11:48 AM, Aaron Rosen  wrote:
>
>> Yup, If your host supports namespaces this can be done via the
>> quantum-metadata-agent.  The following setting is also required in your
>>  nova.conf: service_quantum_metadata_proxy=True
>>
>>
>> On Tue, Apr 23, 2013 at 10:44 PM, Balamurugan V G <
>> balamuruga...@gmail.com> wrote:
>>
>>> Hi,
>>>
>>> In Grizzly, when using quantum and overlapping IPs, does metadata
>>> service work? This wasnt working in Folsom.
>>>
>>> Thanks,
>>> Balu
>>>
>>> ___
>>> Mailing list: https://launchpad.net/~openstack
>>> Post to : openstack@lists.launchpad.net
>>> Unsubscribe : https://launchpad.net/~openstack
>>> More help   : https://help.launchpad.net/ListHelp
>>>
>>>
>>
>
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] [OpenStack] Grizzly: Does metadata service work when overlapping IPs is enabled

2013-04-23 Thread Aaron Rosen

Yup, If your host supports namespaces this can be done via the
quantum-metadata-agent.  The following setting is also required in your
 nova.conf: service_quantum_metadata_proxy=True

On Tue, Apr 23, 2013 at 10:44 PM, Balamurugan V G
wrote:

> Hi,
>
> In Grizzly, when using quantum and overlapping IPs, does metadata service
> work? This wasnt working in Folsom.
>
> Thanks,
> Balu
>
> ___
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>
>
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] How to hot-plug network interface for a running instance

2013-04-22 Thread Aaron Rosen

Hi,

I tested this as well and was also able to reproduce the same issue. I
filed a bug here: https://bugs.launchpad.net/nova/+bug/1171636

Thanks,

Aaron


On Sun, Apr 21, 2013 at 11:00 PM, 陈雷  wrote:

> Hi, All
>
> I'm testing hot-plug network interface, I can successfully hot-add an
> interface to a running instance by using command 'nova interface-attach
> --net-id xx ', but the network of the interface must has
> been specified to instance when you  create it. For a new network, I can't
> attach it to the instance and got errors from nova-api.log:
>
> ==
> 2013-04-22 13:27:38.484 ERROR nova.api.openstack
> [req-73c7fcb6-5137-43c0-aa4f-c3ba3509df64 3745e52df7864de79f912d7a9479e182
> 67b78b4656cf4affa49fc75b847e8914] Caught error:
> u'e4eca07f-bf8e-435a-84e2-628f89067623' is not in list
> Traceback (most recent call last):
>
>   File
> "/usr/lib/python2.7/dist-packages/nova/openstack/common/rpc/amqp.py", line
> 430, in _process_data
> rval = self.proxy.dispatch(ctxt, version, method, **args)
>
>   File
> "/usr/lib/python2.7/dist-packages/nova/openstack/common/rpc/dispatcher.py",
> line 133, in dispatch
> return getattr(proxyobj, method)(ctxt, **kwargs)
>
>   File "/usr/lib/python2.7/dist-packages/nova/compute/manager.py", line
> 2969, in attach_interface
> self.conductor_api)
>
>   File "/usr/lib/python2.7/dist-packages/nova/network/api.py", line 46, in
> wrapper
> res = f(self, context, *args, **kwargs)
>
>   File "/usr/lib/python2.7/dist-packages/nova/network/quantumv2/api.py",
> line 335, in allocate_port_for_instance
> conductor_api=conductor_api)
>
>   File "/usr/lib/python2.7/dist-packages/nova/network/api.py", line 46, in
> wrapper
> res = f(self, context, *args, **kwargs)
>
>   File "/usr/lib/python2.7/dist-packages/nova/network/quantumv2/api.py",
> line 285, in allocate_for_instance
> nw_info = self._get_instance_nw_info(context, instance, networks=nets)
>
>   File "/usr/lib/python2.7/dist-packages/nova/network/quantumv2/api.py",
> line 367, in _get_instance_nw_info
> nw_info = self._build_network_info_model(context, instance, networks)
>
>   File "/usr/lib/python2.7/dist-packages/nova/network/quantumv2/api.py",
> line 788, in _build_network_info_model
> [n['id'] for n in networks])
>
>   File "/usr/lib/python2.7/dist-packages/nova/network/quantumv2/api.py",
> line 945, in _ensure_requested_network_ordering
> unordered.sort(key=lambda i: preferred.index(accessor(i)))
>
>   File "/usr/lib/python2.7/dist-packages/nova/network/quantumv2/api.py",
> line 945, in 
> unordered.sort(key=lambda i: preferred.index(accessor(i)))
>
> ValueError: u'e4eca07f-bf8e-435a-84e2-628f89067623' is not in list
> 2013-04-22 13:27:38.484 22571 TRACE nova.api.openstack Traceback (most
> recent call last):
> 2013-04-22 13:27:38.484 22571 TRACE nova.api.openstack   File
> "/usr/lib/python2.7/dist-packages/nova/api/openstack/__init__.py", line 81,
> in __call__
> 2013-04-22 13:27:38.484 22571 TRACE nova.api.openstack return
> req.get_response(self.application)
> 2013-04-22 13:27:38.484 22571 TRACE nova.api.openstack   File
> "/usr/lib/python2.7/dist-packages/webob/request.py", line 1296, in send
> 2013-04-22 13:27:38.484 22571 TRACE nova.api.openstack application,
> catch_exc_info=False)
> 2013-04-22 13:27:38.484 22571 TRACE nova.api.openstack   File
> "/usr/lib/python2.7/dist-packages/webob/request.py", line 1260, in
> call_application
> 2013-04-22 13:27:38.484 22571 TRACE nova.api.openstack app_iter =
> application(self.environ, start_response)
> 2013-04-22 13:27:38.484 22571 TRACE nova.api.openstack   File
> "/usr/lib/python2.7/dist-packages/webob/dec.py", line 144, in __call__
> 2013-04-22 13:27:38.484 22571 TRACE nova.api.openstack return
> resp(environ, start_response)
> 2013-04-22 13:27:38.484 22571 TRACE nova.api.openstack   File
> "/usr/lib/python2.7/dist-packages/keystoneclient/middleware/auth_token.py",
> line 450, in __call__
> 2013-04-22 13:27:38.484 22571 TRACE nova.api.openstack return
> self.app(env, start_response)
> 2013-04-22 13:27:38.484 22571 TRACE nova.api.openstack   File
> "/usr/lib/python2.7/dist-packages/webob/dec.py", line 144, in __call__
> 2013-04-22 13:27:38.484 22571 TRACE nova.api.openstack return
> resp(environ, start_response)
> 2013-04-22 13:27:38.484 22571 TRACE nova.api.openstack   File
> "/usr/lib/python2.7/dist-packages/webob/dec.py", line 144, in __call__
> 2013-04-22 13:27:38.484 22571 TRACE nova.api.openstack return
> resp(environ, start_response)
> 2013-04-22 13:27:38.484 22571 TRACE nova.api.openstack   File
> "/usr/lib/python2.7/dist-packages/webob/dec.py", line 144, in __call__
> 2013-04-22 13:27:38.484 22571 TRACE nova.api.openstack return
> resp(environ, start_response)
> 2013-04-22 13:27:38.484 22571 TRACE nova.api.openstack   File
> "/usr/lib/python2.7/dist-packages/routes/middleware.py", line 131, in
> __call__
> 2013-04-22 13:27:3

Re: [Openstack] [Quantum][Grizzly] Second NIC is not getting IP address from the network

2013-04-17 Thread Aaron Rosen

Yes, it will get the same ip from the dhcp server.


On Wed, Apr 17, 2013 at 12:09 PM, Anil Vishnoi wrote:

> Thanks Aaron for quick response.
>
> OS dashboard shows that both the NIC got their IP addresses from
> respective DHCP servers. It also shows the second IP address which actually
> is requested by Cirros VM image. If i run udhcp manually from the VM, will
> it get the same IP address from its DHCP server? If yes, than i think there
> is no issue, but if not then i think it will create inconsistency on what
> dashboard is showing and what actual IP address it got assigned.
>
>
>
>
> On Thu, Apr 18, 2013 at 12:21 AM, Aaron Rosen  wrote:
>
>> Hi,
>>
>> The cirros image only starts the dhcp client on the eth0 interface. If
>> you have a vm with multiple interfaces you need to manually run udhcp -i
>>  or change the network configuration file in order to start the
>> dhcp client for you .
>>
>> Aaron
>>
>>
>> On Wed, Apr 17, 2013 at 11:44 AM, Anil Vishnoi wrote:
>>
>>> Hi All,
>>>
>>> I created two network, one private network for project (say
>>> 'TestProject'), and second network at admin level, but its shared network.
>>>
>>> I spawned one VM and connected it to private network. VM successfully
>>> boots up and get the IP address from its respective private network DHCP.
>>>
>>> I spawned second VM and connected it to the shared network, and it boots
>>> up successfully and gets IP address from the shared network DHCP.
>>>
>>> I spawned third VM and connected it to both the network, and the order
>>> was 1.Private Network 2. Shared Network. VM boots up successfully but only
>>> gets the IP address from the private network DHCP and second NIC didn't
>>> receive any ip from shared network DHCP.
>>>
>>> Next i spawned fourth VM and this time i changed the ordering of NIC, 1.
>>> Shared Network 2.Private Network. VM gets the IP address from shared
>>> network DHCP but not from private network DHCP. Looks like whatever first
>>> network you add while creating VM, it will just make DHCP request for the
>>> first network only. Is this expected behavior ? My understanding is both
>>> the NIC should get IP address if DHCP is enabled for the connected networks.
>>>
>>> Few point i want to mention
>>>
>>> * I am using cirros VM image
>>> * Meta data service is running on my network node, but i am still not
>>> able to reach the mata data service.
>>>
>>> Please let me know if further details are needed for debugging this
>>> issue. Thanks in advance!!!
>>>
>>> --
>>> Thanks
>>> Anil
>>>
>>> ___
>>> Mailing list: https://launchpad.net/~openstack
>>> Post to : openstack@lists.launchpad.net
>>> Unsubscribe : https://launchpad.net/~openstack
>>> More help   : https://help.launchpad.net/ListHelp
>>>
>>>
>>
>
>
> --
> Thanks
> Anil
>
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] [Quantum][Grizzly] Second NIC is not getting IP address from the network

2013-04-17 Thread Aaron Rosen

Hi,

The cirros image only starts the dhcp client on the eth0 interface. If you
have a vm with multiple interfaces you need to manually run udhcp -i
 or change the network configuration file in order to start the
dhcp client for you .

Aaron


On Wed, Apr 17, 2013 at 11:44 AM, Anil Vishnoi wrote:

> Hi All,
>
> I created two network, one private network for project (say
> 'TestProject'), and second network at admin level, but its shared network.
>
> I spawned one VM and connected it to private network. VM successfully
> boots up and get the IP address from its respective private network DHCP.
>
> I spawned second VM and connected it to the shared network, and it boots
> up successfully and gets IP address from the shared network DHCP.
>
> I spawned third VM and connected it to both the network, and the order was
> 1.Private Network 2. Shared Network. VM boots up successfully but only gets
> the IP address from the private network DHCP and second NIC didn't receive
> any ip from shared network DHCP.
>
> Next i spawned fourth VM and this time i changed the ordering of NIC, 1.
> Shared Network 2.Private Network. VM gets the IP address from shared
> network DHCP but not from private network DHCP. Looks like whatever first
> network you add while creating VM, it will just make DHCP request for the
> first network only. Is this expected behavior ? My understanding is both
> the NIC should get IP address if DHCP is enabled for the connected networks.
>
> Few point i want to mention
>
> * I am using cirros VM image
> * Meta data service is running on my network node, but i am still not able
> to reach the mata data service.
>
> Please let me know if further details are needed for debugging this issue.
> Thanks in advance!!!
>
> --
> Thanks
> Anil
>
> ___
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>
>
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] [DevStack] Does Devstack support grizilly already?

2013-04-17 Thread Aaron Rosen

See: https://wiki.openstack.org/wiki/Quantum/LBaaS/HowToRun


On Tue, Apr 16, 2013 at 8:38 PM, HuYanrui  wrote:

> I just installed a new devstack with "git clone git://
> github.com/openstack-dev/devstack.git".
> But did not see anything related with Loadbanlance in dashboard.
> It should contain LBaas in dashboard of grizzily, right?
>
> - Original Message -
> From: "Jeremy Stanley" 
> To: "OpenStack Users List" 
> Sent: Tuesday, April 16, 2013 1:41 AM
> Subject: Re: [Openstack] [DevStack] Does Devstack support grizilly already?
>
>
> > On 2013-04-15 10:19:26 +0100 (+0100), Filipe Manco wrote:
> >> I've been testing grizzly with devstack and it works just fine.
> >
> > And in fact, every commit which went into Grizzly was independently
> > deployed (multiple times) on DevStack via devstack-gate and
> > exercised with Tempest. It's essentially what we use to perform
> > integration testing, to make sure patches to one component of
> > OpenStack don't result in adverse interactions with another
> > component.
> > --
> > Jeremy Stanley
> >
> > ___
> > Mailing list: https://launchpad.net/~openstack
> > Post to : openstack@lists.launchpad.net
> > Unsubscribe : https://launchpad.net/~openstack
> > More help   : https://help.launchpad.net/ListHelp
> ___
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] error in quantum in folsom

2013-04-12 Thread Aaron Rosen

if you do quantum -v net-create --tenant-id 112a75ab04224fa3b44109a6c4859c28
net1 , you'll see the end host your client is trying to connect to. I'd
check that this is the right IP of your quantum box and that your client
has ip connectivity to that client.

Aaron


On Fri, Apr 12, 2013 at 4:13 AM, Arindam Choudhury  wrote:

> Hi,
>
> I am new to openstack and I am trying to install openstack folsom on
> fedora 18. any help will be highly appreciated.
>
> while installing quantum I got this error:
>
> [(keystone_admin)]$ quantum net-create --tenant-id
> 112a75ab04224fa3b44109a6c4859c28 net1
> [Errno 110] Connection timed out
>
>  /var/log/quantum/server.log
> 2013-04-12 12:43:53 INFO [quantum.common.config] Logging enabled!
> 2013-04-12 12:43:53 INFO [quantum.common.config] Config paste file:
> /etc/quantum/api-paste.ini
> 2013-04-12 12:43:53 INFO [quantum.manager] Loading Plugin:
> quantum.plugins.openvswitch.ovs_quantum_plugin.OVSQuantumPluginV2
> 2013-04-12 12:43:53 INFO
> [quantum.plugins.openvswitch.ovs_quantum_plugin] Network VLAN ranges: {}
> 2013-04-12 12:43:53 INFO [quantum.openstack.common.rpc.impl_qpid]
> Connected to AMQP server on 158.109.65.21:5672
> 2013-04-12 12:43:53 INFO [quantum.api.extensions] Initializing
> extension manager.
> 2013-04-12 12:43:53 INFO [quantum.api.extensions] Loading extension
> file: __init__.pyc
> 2013-04-12 12:43:53 INFO [quantum.api.extensions] Loading extension
> file: extensions.pyo
> 2013-04-12 12:43:53 INFO [quantum.api.extensions] Loading extension
> file: _quotav2_model.py
> 2013-04-12 12:43:53 INFO [quantum.api.extensions] Loading extension
> file: l3.py
> 2013-04-12 12:43:53  WARNING [quantum.api.extensions] Loaded extension:
> router
> 2013-04-12 12:43:53 INFO [quantum.api.extensions] Loading extension
> file: _quotav2_model.pyc
> 2013-04-12 12:43:53 INFO [quantum.api.extensions] Loading extension
> file: _quotav2_driver.pyo
> 2013-04-12 12:43:53 INFO [quantum.api.extensions] Loading extension
> file: quotasv2.pyo
> 2013-04-12 12:43:53 INFO [quantum.api.extensions] Loading extension
> file: providernet.pyc
> 2013-04-12 12:43:53 INFO [quantum.api.extensions] Loading extension
> file: flavor.pyo
> 2013-04-12 12:43:53 INFO [quantum.api.extensions] Loading extension
> file: l3.pyo
> 2013-04-12 12:43:53 INFO [quantum.api.extensions] Loading extension
> file: quotasv2.pyc
> 2013-04-12 12:43:53 INFO [quantum.api.extensions] Loading extension
> file: l3.pyc
> 2013-04-12 12:43:53 INFO [quantum.api.extensions] Loading extension
> file: extensions.pyc
> 2013-04-12 12:43:53 INFO [quantum.api.extensions] Loading extension
> file: providernet.pyo
> 2013-04-12 12:43:53 INFO [quantum.api.extensions] Loading extension
> file: quotasv2.py
> 2013-04-12 12:43:53  WARNING [quantum.api.extensions] Exception loading
> extension: Invalid extension environment: quota driver
> quantum.extensions._quotav2_driver.DbQuotaDriver is needed.
> 2013-04-12 12:43:53 INFO [quantum.api.extensions] Loading extension
> file: extensions.py
> 2013-04-12 12:43:53  WARNING [quantum.api.extensions] Did not find
> expected name "Extensions" in
> /usr/lib/python2.7/site-packages/quantum/extensions/extensions.py
> 2013-04-12 12:43:53 INFO [quantum.api.extensions] Loading extension
> file: __init__.py
> 2013-04-12 12:43:53 INFO [quantum.api.extensions] Loading extension
> file: flavor.py
> 2013-04-12 12:43:53  WARNING [quantum.api.extensions] extension flavor not
> supported by plugin
>  at 0x39a4450>
> 2013-04-12 12:43:53 INFO [quantum.api.extensions] Loading extension
> file: __init__.pyo
> 2013-04-12 12:43:53 INFO [quantum.api.extensions] Loading extension
> file: _quotav2_driver.pyc
> 2013-04-12 12:43:53 INFO [quantum.api.extensions] Loading extension
> file: flavor.pyc
> 2013-04-12 12:43:53 INFO [quantum.api.extensions] Loading extension
> file: providernet.py
> 2013-04-12 12:43:53  WARNING [quantum.api.extensions] Loaded extension:
> provider
> 2013-04-12 12:43:53 INFO [quantum.api.extensions] Loading extension
> file: _quotav2_model.pyo
> 2013-04-12 12:43:53 INFO [quantum.api.extensions] Loading extension
> file: _quotav2_driver.py
> 2013-04-12 12:43:53 INFO [keystone.middleware.auth_token] Starting
> keystone auth_token middleware
> 2013-04-12 12:43:53 INFO [keystone.middleware.auth_token] Using
> /var/lib/quantum/keystone-signing as cache directory for signing certificate
> 2013-04-12 13:08:07 INFO [quantum.openstack.common.rpc.impl_qpid]
> Connected to AMQP server on 158.109.65.21:5672
> 2013-04-12 13:09:05 INFO [quantum.common.config] Logging enabled!
> 2013-04-12 13:09:05 INFO [quantum.common.config] Config paste file:
> /etc/quantum/api-paste.ini
> 2013-04-12 13:09:05 INFO [quantum.manager] Loading Plugin:
> quantum.plugins.openvswitch.ovs_quantum_plugin.OVSQuantumPluginV2
> 2013-04-12 13:09:05 INFO
> [quantum.plugins.openvswitch.ovs_quantum_pl

Re: [Openstack] Fwd: Re: [openStack] instance status

2013-04-11 Thread Aaron Rosen

Do you have NTP configured? If the nodes running nova-compute have clocks
that differ from each other the status shows XXX . (Not sure why it's done
this way though).

Aaron


On Thu, Apr 11, 2013 at 10:44 PM, Deepak A.P wrote:

>
>
> -- Forwarded message --
> From: Deepak A.P 
> Date: Tue, Apr 9, 2013 at 2:25 PM
> Subject: Re: Re: [Openstack] [openStack] instance status
> To: Wangpan 
>
>
> Hello,
>
> The output of 'nova-manage service list'command is
>
>
>
> * Binary   Host  Zone
>   StatusState  Updated_At*
>
> nova-computeopenStack   nova
>  Enabled   XXX   2012-04-03
>
> nova-network openStack   nova
>Enabled   XXX  2012-04-03
>
> nova-scheduler   openStack  nova
>  Enabled  XXX2012-04-05
>
>  nova-cert  openStack   nova
>  Enabled   XXX   2012-04-05
>
>
>
>
>
>
> On Tue, Apr 9, 2013 at 12:21 PM, Wangpan wrote:
>
>> **
>> What the result of running 'nova-manage service list'， 'sudo' may be
>> needed by non-root user.
>>
>> 2013-04-09
>>  --
>>  Wangpan
>>  --
>>  *发件人：*Deepak A.P
>> *发送时间：*2013-04-09 13:54
>> *主题：*Re: [Openstack] [openStack] instance status
>> *收件人：*"sachin tripathi"
>> *抄送：*"OpenStack Mailing List"
>>
>>  Below is output which i got on running '*nova console-log*'
>>
>> nova console-log *d46530e2-.*
>>
>> Error: The server has either erred or either incapable of performing the
>> requested operation. HTTP(500) (Request-ID: req-be41c539...)
>>
>> i tried the other nova commands like 'nova reboot' , ' nova reload' but
>> got the similar error,
>>
>> and logs are not created under '/var/log/nova/'
>>
>> stuck with the above issue
>>
>>
>>
>> On Tue, Apr 9, 2013 at 10:32 AM, sachin tripathi 
>> wrote:
>>
>>>Hello,
>>> You can check the console logs
>>> nova console-log 
>>>
>>> On the api node, you can find /var/log/nova/nova-*.log,
>>>
>>> And from "nova  show  " get the hypervisor hostname and
>>> check the hypervisor compute-log too.
>>>
>>> Hope, this will give some info to start troubleshoot.
>>>
>>> +Sachin
>>>
>>>
>>>
>>>  On Tue, Apr 9, 2013 at 10:03 AM, Deepak A.P 
>>> wrote:
>>>
  Hello,

 After launching the instance i waited for long time , but still
 the status of the instance  shows 'BUILD' , the flavor of the image is
 'm1.small' . Is there any work around to know what's happening with the

 instance ?. Are there any logs where i can check the instance
 launch status ?





 On Sat, Apr 6, 2013 at 12:01 AM, Lloyd Dewolf wrote:

>  On Fri, Apr 5, 2013 at 4:18 AM, Deepak A.P  > wrote:
>
>>
>> Hi ,
>>
>>  i have a list of instances created using the below command
>>
>>  nova boot myInstance --image
>> 0e2f43a8-e614-48ff-92bd-be0c68da19f4
>>
>>--flavor 2 --key_name openstack
>>
>>
>>i ran the below command to check the status of instances
>>
>>
>> nova list
>>
>>
>> all the instances show status as  "*BUILD*" , how to se the status of 
>> the image to
>>
>> "ACTIVE " , i tried rebooting the instance am getting the below error
>>
>>
> Once the instance finishes building then it will be in the "active"
> state. Depending on the image, flavor and configuration starting an
> instance can take a long time. I would suggest first trying with a small
> image like Cirrus and using a "tiny" flavor.
>
> http://docs.openstack.org/trunk/openstack-compute/admin/content/starting-images.html
>
> Hope that helps,
> --
> @lloyddewolf
> http://www.pistoncloud.com/
>



 --
 Cheers,
 Deepak

 ___
 Mailing list: https://launchpad.net/~openstack
 Post to : openstack@lists.launchpad.net
 Unsubscribe : https://launchpad.net/~openstack
 More help   : https://help.launchpad.net/ListHelp


>>>
>>
>>
>> --
>> Cheers,
>> Deepak
>>
>
>
>
> --
> Cheers,
> Deepak
>
>
>
> --
> Cheers,
> Deepak
>
> ___
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>
>
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] [Quantum] Anybody implemented DMZ?

2013-04-04 Thread Aaron Rosen

In my reply I suggested you to create two quantum routers which I believe
should solve this for you.


quantum net-create DMZ-net --external=True
quantum subnet-create --name DMZ-Subnet1 DMZ-net # Public ip
pool
quantum net-create non-DMZ  --external=True
quantum subnet-create --name nonDMZ-Subnet1 non-DMZ  #
Public ip pool


quantum router-create DMZ-router
quantum router-create non-DMZ-router
quantum router-interface-add DMZ-router DMZ DMZ-Subnet1
quantum router-interface-add non-DMZ-router  nonDMZ-Subnet1

quantum router-gateway-set  DMZ-router DMZ-net
quantum router-gateway-set   non-DMZ-router  non-DMZ


On Thu, Apr 4, 2013 at 10:51 AM, David Kang  wrote:

>
>
>  Hi Aron,
>
>  Thank you for your reply.
>
>  We deploy one (quantum) subnet as a DMZ network and the other (quantum)
> subnet
> as a non-DMZ network.
> They are routed to the network node where quantum services (dhcp, l3,
> linuxbridge)
> are running.
> They can talk each other through network node, now.
>
>  However, we do not want to the network node to route the traffic between
> them directly.
> Instead we want them to be routed to different (external) routers such that
> we can apply filtering/firewall/etc. on the traffic from DMZ network.
>
>  Do you think is it possible using two l3-agents or any other way?
> Currently, I manually set up routings for those two subnets.
>
>  Thanks,
>  David
>
> - Original Message -
> > Hi David,
> >
> >
> > The quantum network node would route traffic between the non-DMZ-DMZ
> > network if both of those subnets are uplinked to the same quantum
> > router. I believe if you create another router for your dmz hosts then
> > traffic in/out of that network should route our to your physical
> > infrastructure which will go through your router to do filtering.
> >
> >
> > Thanks,
> >
> >
> > Aaron
> >
> >
> >
> > On Wed, Apr 3, 2013 at 8:26 AM, David Kang < dk...@isi.edu > wrote:
> >
> >
> >
> > Hi,
> >
> > We are trying to set up Quantum network for non-DMZ and DMZ networks.
> > The cloud has both non-DMZ networks and a DMZ network.
> > We need to route traffic from DMZ network to a specific router before
> > it reaches
> > anywhere else in non-DMZ networks.
> > However, Quantum Network Node routes the traffic between DMZ network
> > and
> > non-DMZ network within itself by default.
> > Have anybody configured Quantum for this case?
> > Any help will be appreciated.
> > We are using Quantum linuxbridge-agent.
> >
> > Thanks,
> > David
> >
> > --
> > --
> > Dr. Dong-In "David" Kang
> > Computer Scientist
> > USC/ISI
> >
> > ___
> > Mailing list: https://launchpad.net/~openstack
> > Post to : openstack@lists.launchpad.net
> > Unsubscribe : https://launchpad.net/~openstack
> > More help : https://help.launchpad.net/ListHelp
>
> --
> --
> Dr. Dong-In "David" Kang
> Computer Scientist
> USC/ISI
>
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] [Quantum] Anybody implemented DMZ?

2013-04-04 Thread Aaron Rosen

Hi David,

The quantum network node would route traffic between the non-DMZ-DMZ
network if both of those subnets are uplinked to the same quantum router. I
believe if you create another router for your dmz hosts then traffic in/out
of that network should route our to your physical infrastructure which will
go through your router to do filtering.

Thanks,

Aaron


On Wed, Apr 3, 2013 at 8:26 AM, David Kang  wrote:

>
>  Hi,
>
>  We are trying to set up Quantum network for non-DMZ and DMZ networks.
> The cloud has both non-DMZ networks and a DMZ network.
> We need to route traffic from DMZ network to a specific router before it
> reaches
> anywhere else in non-DMZ networks.
> However, Quantum Network Node routes the traffic between DMZ network and
> non-DMZ network within itself by default.
> Have anybody configured Quantum for this case?
> Any help will be appreciated.
> We are using Quantum linuxbridge-agent.
>
>  Thanks,
>  David
>
> --
> --
> Dr. Dong-In "David" Kang
> Computer Scientist
> USC/ISI
>
> ___
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] nova calls libvirt but failed:Operation not supported

2013-04-01 Thread Aaron Rosen

I believe that with older versions of libvirt you need to uncomment the
following lines in /etc/libvirt/qemu.conf

# The user ID for QEMU processes run by the system instance.
user = "root"

# The group ID for QEMU processes run by the system instance.
group = "root"


I'd also check what's in /var/log/libvirt/libvirtd.log
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] nova calls libvirt but failed:Operation not supported

2013-04-01 Thread Aaron Rosen

Do you have the following line (bolded) in /etc/libvirt/qemu.conf  ?

cgroup_device_acl = [
"/dev/null", "/dev/full", "/dev/zero",
"/dev/random", "/dev/urandom",
"/dev/ptmx", "/dev/kvm", "/dev/kqemu",
"/dev/rtc", "/dev/hpet"*,"/dev/net/tun",*
]



On Mon, Apr 1, 2013 at 8:42 PM, Liu Wenmao  wrote:

> Hi all:
>
> I use github to install nova and quantum, but when I launch an instance,
> nova-compute fails:
>
> 2013-04-02 11:00:15DEBUG [nova.openstack.common.lockutils] Released
> file lock "iptables" at /var/lock/nova/nova-iptables for method "_apply"...
> 2013-04-02 11:00:17ERROR [nova.compute.manager] Instance failed to
> spawn
> Traceback (most recent call last):
>   File
> "/usr/local/lib/python2.7/dist-packages/nova-2013.2.a89.ge9912c6-py2.7.egg/nova/compute/manager.py",
> line 1069, in _spawn
> block_device_info)
>   File
> "/usr/local/lib/python2.7/dist-packages/nova-2013.2.a89.ge9912c6-py2.7.egg/nova/virt/libvirt/driver.py",
> line 1520, in spawn
> block_device_info)
>   File
> "/usr/local/lib/python2.7/dist-packages/nova-2013.2.a89.ge9912c6-py2.7.egg/nova/virt/libvirt/driver.py",
> line 2435, in _create_domain_and_network
> domain = self._create_domain(xml, instance=instance)
>   File
> "/usr/local/lib/python2.7/dist-packages/nova-2013.2.a89.ge9912c6-py2.7.egg/nova/virt/libvirt/driver.py",
> line 2396, in _create_domain
> domain.createWithFlags(launch_flags)
>   File "/usr/local/lib/python2.7/dist-packages/eventlet/tpool.py", line
> 187, in doit
> result = proxy_call(self._autowrap, f, *args, **kwargs)
>   File "/usr/local/lib/python2.7/dist-packages/eventlet/tpool.py", line
> 147, in proxy_call
> rv = execute(f,*args,**kwargs)
>   File "/usr/local/lib/python2.7/dist-packages/eventlet/tpool.py", line
> 76, in tworker
> rv = meth(*args,**kwargs)
>   File "/usr/lib/python2.7/dist-packages/libvirt.py", line 581, in
> createWithFlags
> if ret == -1: raise libvirtError ('virDomainCreateWithFlags() failed',
> dom=self)
> libvirtError: Unable to add bridge br-int port tap89ed2dc0-2e: Operation
> not supported
> 2013-04-02 11:00:17DEBUG [nova.openstack.common.lockutils] Got
> semaphore "compute_resources" for method "abort"...
> 2013-04-02 11:00:17DEBUG [nova.compute.claims] Aborting claim: [Claim:
> 512 MB memory, 0 GB disk, 1 VCPUS]
>
> Is it because user nova call libvirt to create a port so it has not enough
> permission?
>
> note1:I set up sudoer:
> root@node1:~# cat /etc/sudoers.d/nova_sudoers
> Defaults:nova !requiretty
>
> nova ALL = (root) NOPASSWD: /usr/local/bin/nova-rootwrap
>
>
> note2:I login as root, execute " ovs-vsctl add-port", and succeed.
>
> root@node1:~# ovs-vsctl add-port br-int  tap89ed2dc0-2e
> root@node1:~# ovs-vsctl show
> f3f4cdc0-1391-45fd-a535-1947d5aea488
> Bridge "br0"
> Port "eth0"
> Interface "eth0"
> Port "br0"
> Interface "br0"
> type: internal
> Bridge br-int
> Port br-int
> Interface br-int
> type: internal
> Port patch-tun
> Interface patch-tun
> type: patch
> options: {peer=patch-int}
> Port "tap89ed2dc0-2e"
> Interface "tap89ed2dc0-2e"
> Bridge br-tun
> Port patch-int
> Interface patch-int
> type: patch
> options: {peer=patch-tun}
> Port "gre-1"
> Interface "gre-1"
> type: gre
> options: {in_key=flow, out_key=flow,
> remote_ip="192.168.19.1"}
> Port br-tun
> Interface br-tun
> type: internal
> ovs_version: "1.4.0+build0"
>
>
> ___
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>
>
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] [OpenStack] Re-using VLAN ranges acorss physnet in OVS Quantum plugin based setup

2013-03-31 Thread Aaron Rosen

Yes, this is fine because the vlans don't conflict on the same physical
interface.

Aaron


On Sun, Mar 31, 2013 at 10:22 PM, Balamurugan V G
wrote:

> Hi,
>
> While using a OVS plugin based Quantum setup, will it be possible to go
> beyond 4095 vlans by re-using them across multiple physnets. For example,
> is something like the setting below possible?
>
> network_vlan_ranges = physnet1:1:4094, physnet2:1:4094,
>
> Or will this not be allowed due to conflicting VLANs?
>
> Thanks
> Balu
>
> ___
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>
>
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] nova-api-metadata on compute node with folsom

2013-03-29 Thread Aaron Rosen

Actually it looks like you shouldn't need the iptables rule and
nova-api-metadata running if you use this method
http://docs.openstack.org/folsom/openstack-network/admin/content/adv_cfg_l3_agent_metadata.html


On Fri, Mar 29, 2013 at 12:22 AM, Aaron Rosen  wrote:

> Hi,
>
> I believe you have this setup on the wrong node. When the VM does a
> request to 169.254.169.254 this will end up on the network node. On the
> network node you need that iptables rule  and nova-api-metadata installed
> and running.
>
> 
>> My questions are:
>>
>>- Am I missing something simple here?
>>- Is nova-api-metadata really functioning as metadata server on my
>>compute host? (seems not to be the cause of the problem but just 
>> checking).
>>- Is there any plan for Grizzly to have the routing of the metadata
>>request on the localhost automatically set when nova-api-metadata is
>>present ?
>>
>> Yup, in Grizzly there is a quantum metadata proxy agent that will proxy
> the request to your metadata server so you don't need nova-api-metadata
> running on localhost. It  will also allow metadata to work with overlapping
> ip.
>
>>
>>- Why my routing rule doesn't apply here?
>>
>> Quick question what type of networking are you using? VLAN/GRE/FLAT?
> I suspect you're using GRE(overlay) which is why this isn't working.
>
>>
>>
>> Regards,
>>
>>
>> *BUSSY Jean-Daniel*
>>
>>
>> ___
>> Mailing list: https://launchpad.net/~openstack
>> Post to : openstack@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~openstack
>> More help   : https://help.launchpad.net/ListHelp
>>
>>
>
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] How to get around bug 1135948

2013-03-29 Thread Aaron Rosen

I don't think that bug is preventing you from pinging your instances. That
bug just cleans up left over dnsmaq processes after a network has been
deleted while the quantum dhcp agent was down.

If you stop the quantum dhcp agent; sudo pkill dnsmaq ; start quantum-dhcp
agent that should do the clean up I believe. But I don't  think this is
stopping you from pinging.

Aaron

On Thu, Mar 28, 2013 at 7:46 AM, Mohammed Amine SAYA <
asaya.openst...@gmail.com> wrote:

> Hi All,
>
> I am trying to find out how to get around this bug :
> https://bugs.launchpad.net/quantum/+bug/1135948  in FOLSOM release.
>
> I saw in the bug's history that it was fixed and released on 2013-03-13,
> which means that it's has been included in grizzly-rc1 but unfortunately
> grizzly-rc1 packages are not available yet for DEBIAN.
>
> Do you know to get around this bug in FOLSOM or 2013.1~g3-1 packages?
>
> It's the last obstacle, I hope, which prevents me from pinging a VM.
>
> Thanks for your time and help.
> Amine.
>
> ___
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>
>
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] nova-api-metadata on compute node with folsom

2013-03-29 Thread Aaron Rosen

Hi,

I believe you have this setup on the wrong node. When the VM does a request
to 169.254.169.254 this will end up on the network node. On the network
node you need that iptables rule  and nova-api-metadata installed and
running.


> My questions are:
>
>- Am I missing something simple here?
>- Is nova-api-metadata really functioning as metadata server on my
>compute host? (seems not to be the cause of the problem but just checking).
>- Is there any plan for Grizzly to have the routing of the metadata
>request on the localhost automatically set when nova-api-metadata is
>present ?
>
> Yup, in Grizzly there is a quantum metadata proxy agent that will proxy
the request to your metadata server so you don't need nova-api-metadata
running on localhost. It  will also allow metadata to work with overlapping
ip.

>
>- Why my routing rule doesn't apply here?
>
> Quick question what type of networking are you using? VLAN/GRE/FLAT?
I suspect you're using GRE(overlay) which is why this isn't working.

>
>
> Regards,
>
>
> *BUSSY Jean-Daniel*
>
>
> ___
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>
>
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] Allocating dynamic IP to the VMs

2013-03-18 Thread Aaron Rosen

In that case you have two options:

1) use floating ips
2) create a provider network that bridges to the same physical of the hosts
that you want to be able to contact your vms.

Aaron

On Mon, Mar 18, 2013 at 10:02 AM, Chathura M. Sarathchandra Magurawalage <
77.chath...@gmail.com> wrote:

> Thanks Sylvain,
>
> There must be a way of doing this without having to do anything with my
> default gateway of my physical network? . Even if I have to I do not wan to
> do anything to the physical gateway. All I need is a way to let the VMs get
> a dynamic IP from the physical network. How can I do this. For example this
> can be done on virtual box using a bridge adapter which maps the VM in to
> the physical network.
>
> On 18 March 2013 16:05, Sylvain Bauza  wrote:
>
>>  Could you please tell me your "physical network" CIDR ?
>> Anyway, what you need is not requiring having a floating IP pool inside
>> the same network, you can also play with static routing : if your physical
>> host does have a default gw, you can create a static route from this gw to
>> the VM network gateway. And on the VM network gateway, do the same...
>>
>> -Sylvain
>>
>> Le 18/03/2013 16:53, Chathura M. Sarathchandra Magurawalage a écrit :
>>
>>   Hey Sylvain,
>>
>>  Basically what I need is to have the VMs mapped to my physical network
>> so that my physical hosts can directly access the VMs. How can I do this?
>>
>>  Thanks.
>>
>>
>> On 18 March 2013 15:50, Sylvain Bauza  wrote:
>>
>>>  Hi,
>>>
>>> I don't understand your business. Should you have a 192.168.1.0/24network 
>>> for management, you could also assign an external network with
>>> Quantum based on the same subnet (ie. 192.168.1.0/24).
>>> When creating a floating IP pool, Quantum does require at least 3 things
>>> :
>>>  - the CIDR
>>>  - the beginning and ending IPs
>>>  - the external gateway
>>>
>>> So, based on what I previously said, you only need to create a
>>> 192.168.1.0/24 in Quantum with .1-.100 (for example) as the range, .254
>>> being the external gateway.
>>>
>>> Thanks,
>>> -Sylvain
>>>
>>> Le 18/03/2013 16:29, Chathura M. Sarathchandra Magurawalage a écrit :
>>>
>>>  anyone?
>>>
>>> On 17 March 2013 21:33, Chathura M. Sarathchandra Magurawalage <
>>> 77.chath...@gmail.com> wrote:
>>>
 After reading a little bit more, I think I have found what I need. It
 is  a provider network that I need for the VMs so that they can get access
 to the other resources in my main network ( such as other physical hosts
 that are connected to the same network ).

  My question is, is it possible to do this alongside the use case that
 I have followed ( Provider router with private networks)?

  If so how can I do this?

  Thanks.


   On 16 March 2013 01:46, Chathura M. Sarathchandra Magurawalage <
 77.chath...@gmail.com> wrote:

>  Hello,
>
>  I want to know how I can allocate a dynamic IP to the VM from the
> same network as the openstack hosts (controller/network-node/compute node)
> network/management network . For example, in virtual box you can give your
> VM an IP from the host's network using a Bridge adapter. How can I do this
> in openstack?
>
>  From what I understand floating IP's are used when you have a public
> IP
>  (which is static) to be allocated to VM's.
>
> My openstack installation architecture:
>
> http://docs.openstack.org/folsom/basic-install/content/basic-install_architecture.html
>
>  Quantum use case:
>
> http://docs.openstack.org/trunk/openstack-network/admin/content/use_cases_single_router.html
>


>>>
>>>
>>>  ___
>>> Mailing list: https://launchpad.net/~openstack
>>> Post to : openstack@lists.launchpad.net
>>> Unsubscribe : https://launchpad.net/~openstack
>>> More help   : https://help.launchpad.net/ListHelp
>>>
>>>
>>>
>>
>>
>
> ___
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>
>
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] ssh from VM to VM

2013-03-15 Thread Aaron Rosen

I suspect that that host 10.5.5.6 has ssh configured for
PasswordAuthentication set to no and you don't have your public key of the
host you are on, in the authorized_key file of 10.5.5.6.

Aaron

On Fri, Mar 15, 2013 at 7:26 PM, Chathura M. Sarathchandra Magurawalage <
77.chath...@gmail.com> wrote:

> Hello,
>
> I can't ssh from Ubuntu cloud VM to other VM. I get following
>
> ubuntu@master:~$ ssh cirros@10.5.5.6 -v
> OpenSSH_5.9p1 Debian-5ubuntu1, OpenSSL 1.0.1 14 Mar 2012
> debug1: Reading configuration data /etc/ssh/ssh_config
> debug1: /etc/ssh/ssh_config line 19: Applying options for *
> debug1: Connecting to 10.5.5.6 [10.5.5.6] port 22.
> debug1: Connection established.
> debug1: identity file /home/ubuntu/.ssh/id_rsa type -1
> debug1: identity file /home/ubuntu/.ssh/id_rsa-cert type -1
> debug1: identity file /home/ubuntu/.ssh/id_dsa type -1
> debug1: identity file /home/ubuntu/.ssh/id_dsa-cert type -1
> debug1: identity file /home/ubuntu/.ssh/id_ecdsa type -1
> debug1: identity file /home/ubuntu/.ssh/id_ecdsa-cert type -1
> debug1: Remote protocol version 2.0, remote software version OpenSSH_5.9p1
> Debian-5ubuntu1
> debug1: match: OpenSSH_5.9p1 Debian-5ubuntu1 pat OpenSSH*
> debug1: Enabling compatibility mode for protocol 2.0
> debug1: Local version string SSH-2.0-OpenSSH_5.9p1 Debian-5ubuntu1
> debug1: SSH2_MSG_KEXINIT sent
> debug1: SSH2_MSG_KEXINIT received
> debug1: kex: server->client aes128-ctr hmac-md5 none
> debug1: kex: client->server aes128-ctr hmac-md5 none
> debug1: sending SSH2_MSG_KEX_ECDH_INIT
> debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
> debug1: Server host key: ECDSA
> 7b:8f:6a:ee:ba:e5:0a:c5:04:01:ca:bd:e5:38:69:55
> debug1: Host '10.5.5.6' is known and matches the ECDSA host key.
> debug1: Found key in /home/ubuntu/.ssh/known_hosts:4
> debug1: ssh_ecdsa_verify: signature correct
> debug1: SSH2_MSG_NEWKEYS sent
> debug1: expecting SSH2_MSG_NEWKEYS
> debug1: SSH2_MSG_NEWKEYS received
> debug1: Roaming not allowed by server
> debug1: SSH2_MSG_SERVICE_REQUEST sent
> debug1: SSH2_MSG_SERVICE_ACCEPT received
> debug1: Authentications that can continue: publickey
> debug1: Next authentication method: publickey
> debug1: Trying private key: /home/ubuntu/.ssh/id_rsa
> debug1: Trying private key: /home/ubuntu/.ssh/id_dsa
> debug1: Trying private key: /home/ubuntu/.ssh/id_ecdsa
> debug1: No more authentication methods to try.
> Permission denied (publickey).
>
> But I can ssh from to my Cirros VMs. Also I can ssh from Ubuntu VM to
> Cirros VM.
>
> Any Idea?
>
> Thanks.
>
> ___
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>
>
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] [QUANTUM] (Bug ?) L3 routing not correctly fragmenting packets ?

2013-03-08 Thread Aaron Rosen

Thanks Rick that makes sense. I've never run into this myself. I just
assumed that a host would by default just set packets at it's MTU size
and the network would handle the fragmentation for you. Good to know.

Aaron


On Fri, Mar 8, 2013 at 11:56 AM, Rick Jones  wrote:
> On 03/08/2013 11:49 AM, Aaron Rosen wrote:
>>
>> Hi Rick,
>>
>> You are right. I just ran curl to test for myself and it does set the
>> DF bit. Why is this? Any ideas why it specifies that the packet cannot
>> be fragmented?
>
>
> Because most, if not virtually all TCP stacks going back to the mid 1990s
> (RFC 1191 is from 1990 and I figured a couple years to propagate) enable
> Path MTU discovery by default for TCP.  At least those with which I have
> come into contact.
>
> I doubt that curl itself asked for it.  I suspect you will find the DF bit
> set in the IP datagrams carrying the TCP segments of any application on your
> system using TCP - even netperf :)  PathMTU discovery, for TCP at least, and
> perhaps other "reliable" transports, is considered a Best Practice (tm) and
> so enabled by default.  Where it may not be enabled by default is for UDP.
>
> rick

___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] [QUANTUM] (Bug ?) L3 routing not correctly fragmenting packets ?

2013-03-08 Thread Aaron Rosen

Hi Rick,

You are right. I just ran curl to test for myself and it does set the
DF bit. Why is this? Any ideas why it specifies that the packet cannot
be fragmented?

Thanks,

Aaron

On Fri, Mar 8, 2013 at 11:27 AM, Rick Jones  wrote:
> On 03/08/2013 09:55 AM, Aaron Rosen wrote:
>>
>> Hi Sylvain,
>>
>>
>> This seems very odd to me. The reason this should happen is if your
>> client is sending packets with the DF (don't fragment) bit set in the
>> TCP header of the packets you are sending. I'd confirm that  your
>> version of 'curl' is doing this (which it should definitely not do!).
>
>
> Why shouldn't a TCP connection initiated by curl (or anything else) have
> Path MTU discovery enabled? (ie the DF bit set in the IP datagrams carrying
> the TCP segments)
>
>
>> What should happen is the router should fragment the packets for you
>> and if a fragment is lost TCP will just re-transmit the full packet
>> again and things should eventually work
>
>
> Here I thought all the IETF demigods considered IP Fragmentation 'To Be
> Avoided (tm)' - hence the creation of Path MTU discovery in the first place.
> :)
>
> FWIW, in the IPv6 world, routers do not fragment.  That implies either
> functioning PathMTU discovery, or lowest common MTU...
>
>
>>
>> Aaron
>>
>>
>> On Fri, Mar 8, 2013 at 9:08 AM, Sylvain Bauza
>>  wrote:
>>>
>>> Hi,
>>>
>>> I recently observed a strange behaviour with L3 Quantum routing
>>> (Openvswitch
>>> setup with Provider Router). A simple curl to an external website is
>>> sometimes failing due to packet size  :
>>>
>>>  192.168.10.3 > X.X.X.X: ICMP 192.168.10.3 unreachable - need to frag
>>> (mtu 1454), length 556
>>>  IP (tos 0x0, ttl 48, id 25918, offset 0, flags [DF], proto TCP (6),
>>> length 1500)
>
>
> Why is the ICMP Destination Unreachable datagram being sent back so large?
> I would have expected it to be rather smaller - an Ethernet, IP and ICMP
> header, and then the original IP header and something like 8 bytes or so of
> the original IP datagram's payload.
>
> I take it that ICMP is not getting back to the original sender? Or is being
> ignored?
>
>
>
>>>
>>> Only changing the VM MTU to 1454 does the trick ('ifconfig eth0 mtu
>>> 1454').
>>>
>>> For info, 192.168.10.3 is the floating IP bound to 10.0.0.4 (private IP).
>
>
> I suppose if 10.0.0.4 doesn't explicitly know about 192.168.10.3 it might
> indeed ignore the ICMP message.  Assuming it isn't getting un-NATted on the
> way back.
>
> rick jones
>
>
>>>
>>> I can't provide the URL for reproducing, as the external website is
>>> actually
>>> an external corporate webservice.
>>> Do you have any idea on what could be the root cause, and how to fix it ?
>>>
>>> Thanks,
>>> -Sylvain
>>>
>>>
>>>
>>> ___
>>> Mailing list: https://launchpad.net/~openstack
>>> Post to : openstack@lists.launchpad.net
>>> Unsubscribe : https://launchpad.net/~openstack
>>> More help   : https://help.launchpad.net/ListHelp
>>
>>
>> ___
>> Mailing list: https://launchpad.net/~openstack
>> Post to : openstack@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~openstack
>> More help   : https://help.launchpad.net/ListHelp
>>
>

___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] [QUANTUM] (Bug ?) L3 routing not correctly fragmenting packets ?

2013-03-08 Thread Aaron Rosen

Hi Sylvain,


This seems very odd to me. The reason this should happen is if your
client is sending packets with the DF (don't fragment) bit set in the
TCP header of the packets you are sending. I'd confirm that  your
version of 'curl' is doing this (which it should definitely not do!).
What should happen is the router should fragment the packets for you
and if a fragment is lost TCP will just re-transmit the full packet
again and things should eventually work

Aaron


On Fri, Mar 8, 2013 at 9:08 AM, Sylvain Bauza
 wrote:
> Hi,
>
> I recently observed a strange behaviour with L3 Quantum routing (Openvswitch
> setup with Provider Router). A simple curl to an external website is
> sometimes failing due to packet size  :
>
> 192.168.10.3 > X.X.X.X: ICMP 192.168.10.3 unreachable - need to frag
> (mtu 1454), length 556
> IP (tos 0x0, ttl 48, id 25918, offset 0, flags [DF], proto TCP (6),
> length 1500)
>
> Only changing the VM MTU to 1454 does the trick ('ifconfig eth0 mtu 1454').
>
> For info, 192.168.10.3 is the floating IP bound to 10.0.0.4 (private IP).
>
> I can't provide the URL for reproducing, as the external website is actually
> an external corporate webservice.
> Do you have any idea on what could be the root cause, and how to fix it ?
>
> Thanks,
> -Sylvain
>
>
>
> ___
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp

___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] [quantum] LBaas work with nova-network

2013-03-04 Thread Aaron Rosen

No, you'll need to switch over to quantum to use this. Quantum,
implements the same use case as nova-network FlatDHCP via the provider
extension.

Aaron

On Mon, Mar 4, 2013 at 10:09 PM, gtt116  wrote:
> Hi all,
>
> I want to play LBaas from quantum, but I was used nova-network FlatDHCP
> to setup network.
>
> So can I continue to use nova-network, and setup an LBaas?
>
> --
> best regards,
> gtt
>
>
>
> ___
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp

___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] Rebooted, now can't ping my guest

2013-02-27 Thread Aaron Rosen

Hi Hsiao,

You are absolutely correct! If 192.168.0.254 is set as the gateway
traffic will not be routed correctly. I also believe there is another
bug as the ip addresses are being placed on the ethX interfaces and
not bridge interfaces. I'll create a patch fixing these issues
tomorrow morning.

Thanks for spotting this!

Aaron

On Wed, Feb 27, 2013 at 10:02 PM, Chuan-Heng Hsiao
 wrote:
> Hi Aaron,
>
> I am very sorry that I made the conclusion too early because of not
> having good understanding
> of everything, and it is with high probability that I may made wrong 
> conclusion.
>
> However, based on my hypothesis (and my few experiments.)
> The gateway setting is supposed to be corresponded to the ip
> connecting to the outer internet,
> and it is 7.7.7.x and is bundled with br-ex.
>
> By setting default gateway to 192.168.0.254 (which does not even
> exit), and bundled with eth0,
> I saw that (by netstat -r) the default gateway is set to 192.168.0.254
> and can't pass to the outer internet
> correctly.
>
> Or maybe it is not the real issue (and doesn't matter how the gateway is set).
> Maybe the real issue was that I can do pings, but I can't do ssh -i to the 
> VMs,
> and it was because I did not set
>
> route add -net 10.10.10.0/24 gw $router_proj_one_IP
>
> to the controller, and the VMs can't access the metadata from
> 192.168.0.1 or $router_proj_one_IP.
> (because the controller's IP is not with the VMs IP)
>
> Sincerely,
> Hsiao
>
>
> On Thu, Feb 28, 2013 at 12:15 PM, Aaron Rosen  wrote:
>>>
>>> DO NOT SET GATEWAY as 192.168.0.254.
>> Why do you say that. I don't see any problem with what the doc says:
>>
>> # Management Network
>> auto eth0
>> iface eth0 inet static
>> address 192.168.0.2
>> netmask 255.255.255.0
>> gateway 192.168.0.254
>> dns-nameservers 8.8.8.8
>>
>> # Data Network
>> auto eth1
>> iface eth1 inet static
>> address 10.10.10.1
>> netmask 255.255.255.0
>>
>> # Public Bridge
>> auto eth2
>> iface eth2 inet manual
>> up ifconfig $IFACE 0.0.0.0 up
>> up ip link set $IFACE promisc on
>> down ifconfig $IFACE down
>>>>
>>>> ___
>>>> Mailing list: https://launchpad.net/~openstack
>>>> Post to : openstack@lists.launchpad.net
>>>> Unsubscribe : https://launchpad.net/~openstack
>>>> More help   : https://help.launchpad.net/ListHelp

___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] Rebooted, now can't ping my guest

2013-02-27 Thread Aaron Rosen

On Wed, Feb 27, 2013 at 7:11 PM, Chuan-Heng Hsiao
 wrote:
> Hi Aaron and The King in Yellow,
>
> I also experienced this problem yesterday and I just solved.
>
> Besides ensuring  quantum-openvswitch-agent processes are all up
> (except the controller node),
> there is a typo in the network node in basic install doc:
>
> http://docs.openstack.org/folsom/basic-install/content/basic-install_network.html
>
> DO NOT SET GATEWAY as 192.168.0.254.
Why do you say that. I don't see any problem with what the doc says:

# Management Network
auto eth0
iface eth0 inet static
address 192.168.0.2
netmask 255.255.255.0
gateway 192.168.0.254
dns-nameservers 8.8.8.8

# Data Network
auto eth1
iface eth1 inet static
address 10.10.10.1
netmask 255.255.255.0

# Public Bridge
auto eth2
iface eth2 inet manual
up ifconfig $IFACE 0.0.0.0 up
up ip link set $IFACE promisc on
down ifconfig $IFACE down
>
> or the routing table would be messed up.
>
>
> Also, if you want to do ssh, based on the following doc:
>
> https://github.com/mseknibilel/OpenStack-Folsom-Install-guide/blob/stable/GRE/OpenStack_Folsom_Install_Guide_WebVersion.rst
>
> REMEMBER TO DO THE FOLLOWING IN YOUR CONTROLLER NODE:
>
> route add -net 10.10.10.0/24 gw $router_proj_one_IP
>
> Sincerely,
> Hsiao
>
>
> On Thu, Feb 28, 2013 at 7:57 AM, Aaron Rosen  wrote:
>> Hi
>>
>> response inline
>>
>> On Wed, Feb 27, 2013 at 3:22 PM, The King in Yellow
>>  wrote:
>>>
>>> I have been working on creating an OpenStack environment according to the
>>> Basic Install doc.  It was working fine last night!  In order to make sure I
>>> didn't mess anything up, I downed controller/network/compute nodes and
>>> cloned them (they are nested on ESXi 5.0u1).
>>>
>>> Upon coming back up, I can't ping my guests.  I'm on the network node,
>>> pinging 10.5.5.3, which is a running guest.  I'm guessing the GRE tunnel
>>> isn't coming between the compute and network node, since the br-* interfaces
>>> down?  (After this, I manually "ip link set up" all br-* interfaces on both
>>> compute and network-- nothing)
>>>
>>> I have no experience with either Quantum or Open vSwitch, so I don't know
>>> what this is telling me.  I'm rather at a loss-- can anybody point me in the
>>> right direction here?  I don't see anything in the quantum logs right now
>>> that seems to indicate an error-- openvswitch-agent.log is cycling through
>>> things like the following, though:
>>>
>>> 2013-02-27 18:19:43DEBUG [quantum.agent.linux.utils] Running command:
>>> sudo /usr/bin/quantum-rootwrap /etc/quantum/rootwrap.conf ovs-vsctl
>>> --timeout=2 get Interface qr-9f9041ce-65 external_ids
>>> 2013-02-27 18:19:43DEBUG [quantum.agent.linux.utils]
>>> Command: ['sudo', '/usr/bin/quantum-rootwrap', '/etc/quantum/rootwrap.conf',
>>> 'ovs-vsctl', '--timeout=2', 'get', 'Interface', 'qr-9f9041ce-65',
>>> 'external_ids']
>>> Exit code: 0
>>> Stdout: '{attached-mac="fa:16:3e:e2:38:da",
>>> iface-id="9f9041ce-654d-4706-a208-60cf5fca5d90", iface-status=active}\n'
>>> Stderr: ''
>>> 2013-02-27 18:19:43DEBUG [quantum.agent.linux.utils] Running command:
>>> sudo /usr/bin/quantum-rootwrap /etc/quantum/rootwrap.conf ovs-vsctl
>>> --timeout=2 get Interface tap45ffdc5f-da external_ids
>>> 2013-02-27 18:19:43DEBUG [quantum.agent.linux.utils]
>>> Command: ['sudo', '/usr/bin/quantum-rootwrap', '/etc/quantum/rootwrap.conf',
>>> 'ovs-vsctl', '--timeout=2', 'get', 'Interface', 'tap45ffdc5f-da',
>>> 'external_ids']
>>> Exit code: 0
>>> Stdout: '{attached-mac="fa:16:3e:36:2e:54",
>>> iface-id="45ffdc5f-dad9-444a-aff4-3d39b607f828", iface-status=active}\n'
>>> Stderr: ''
>>> 2013-02-27 18:19:45DEBUG [quantum.agent.linux.utils] Running command:
>>> sudo /usr/bin/quantum-rootwrap /etc/quantum/rootwrap.conf ovs-vsctl
>>> --timeout=2 list-ports br-int
>>> 2013-02-27 18:19:45DEBUG [quantum.agent.linux.utils]
>>> Command: ['sudo', '/usr/bin/quantum-rootwrap', '/etc/quantum/rootwrap.conf',
>>> 'ovs-vsctl', '--timeout=2', 'list-ports', 'br-int']
>>> Exit code: 0
&g

Re: [Openstack] Rebooted, now can't ping my guest

2013-02-27 Thread Aaron Rosen

Hi

response inline

On Wed, Feb 27, 2013 at 3:22 PM, The King in Yellow
 wrote:
>
> I have been working on creating an OpenStack environment according to the
> Basic Install doc.  It was working fine last night!  In order to make sure I
> didn't mess anything up, I downed controller/network/compute nodes and
> cloned them (they are nested on ESXi 5.0u1).
>
> Upon coming back up, I can't ping my guests.  I'm on the network node,
> pinging 10.5.5.3, which is a running guest.  I'm guessing the GRE tunnel
> isn't coming between the compute and network node, since the br-* interfaces
> down?  (After this, I manually "ip link set up" all br-* interfaces on both
> compute and network-- nothing)
>
> I have no experience with either Quantum or Open vSwitch, so I don't know
> what this is telling me.  I'm rather at a loss-- can anybody point me in the
> right direction here?  I don't see anything in the quantum logs right now
> that seems to indicate an error-- openvswitch-agent.log is cycling through
> things like the following, though:
>
> 2013-02-27 18:19:43DEBUG [quantum.agent.linux.utils] Running command:
> sudo /usr/bin/quantum-rootwrap /etc/quantum/rootwrap.conf ovs-vsctl
> --timeout=2 get Interface qr-9f9041ce-65 external_ids
> 2013-02-27 18:19:43DEBUG [quantum.agent.linux.utils]
> Command: ['sudo', '/usr/bin/quantum-rootwrap', '/etc/quantum/rootwrap.conf',
> 'ovs-vsctl', '--timeout=2', 'get', 'Interface', 'qr-9f9041ce-65',
> 'external_ids']
> Exit code: 0
> Stdout: '{attached-mac="fa:16:3e:e2:38:da",
> iface-id="9f9041ce-654d-4706-a208-60cf5fca5d90", iface-status=active}\n'
> Stderr: ''
> 2013-02-27 18:19:43DEBUG [quantum.agent.linux.utils] Running command:
> sudo /usr/bin/quantum-rootwrap /etc/quantum/rootwrap.conf ovs-vsctl
> --timeout=2 get Interface tap45ffdc5f-da external_ids
> 2013-02-27 18:19:43DEBUG [quantum.agent.linux.utils]
> Command: ['sudo', '/usr/bin/quantum-rootwrap', '/etc/quantum/rootwrap.conf',
> 'ovs-vsctl', '--timeout=2', 'get', 'Interface', 'tap45ffdc5f-da',
> 'external_ids']
> Exit code: 0
> Stdout: '{attached-mac="fa:16:3e:36:2e:54",
> iface-id="45ffdc5f-dad9-444a-aff4-3d39b607f828", iface-status=active}\n'
> Stderr: ''
> 2013-02-27 18:19:45DEBUG [quantum.agent.linux.utils] Running command:
> sudo /usr/bin/quantum-rootwrap /etc/quantum/rootwrap.conf ovs-vsctl
> --timeout=2 list-ports br-int
> 2013-02-27 18:19:45DEBUG [quantum.agent.linux.utils]
> Command: ['sudo', '/usr/bin/quantum-rootwrap', '/etc/quantum/rootwrap.conf',
> 'ovs-vsctl', '--timeout=2', 'list-ports', 'br-int']
> Exit code: 0
> Stdout: 'patch-tun\nqr-9f9041ce-65\ntap45ffdc5f-da\n'
> Stderr: ''
> 2013-02-27 18:19:45DEBUG [quantum.agent.linux.utils] Running command:
> sudo /usr/bin/quantum-rootwrap /etc/quantum/rootwrap.conf ovs-vsctl
> --timeout=2 get Interface patch-tun external_ids
> 2013-02-27 18:19:45DEBUG [quantum.agent.linux.utils]
> Command: ['sudo', '/usr/bin/quantum-rootwrap', '/etc/quantum/rootwrap.conf',
> 'ovs-vsctl', '--timeout=2', 'get', 'Interface', 'patch-tun', 'external_ids']
> Exit code: 0
> Stdout: '{}\n'
> Stderr: ''
>
>
> Here are the output of ifconfig -a, ovs-vsctl show, and ovs-cfctl of each
> bridge on the network node:
>
> root@os-network:~# ifconfig -a
> br-ex Link encap:Ethernet  HWaddr 00:50:56:81:66:d8
>   BROADCAST MULTICAST  MTU:1500  Metric:1
>   RX packets:23 errors:0 dropped:0 overruns:0 frame:0
>   TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
>   collisions:0 txqueuelen:0
>   RX bytes:1380 (1.3 KB)  TX bytes:0 (0.0 B)
>
> br-intLink encap:Ethernet  HWaddr 5e:5a:c3:07:44:42
>   BROADCAST MULTICAST  MTU:1500  Metric:1
>   RX packets:0 errors:0 dropped:0 overruns:0 frame:0
>   TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
>   collisions:0 txqueuelen:0
>   RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
>
> br-tunLink encap:Ethernet  HWaddr 56:2d:9f:6c:ac:4f
>   BROADCAST MULTICAST  MTU:1500  Metric:1
>   RX packets:0 errors:0 dropped:0 overruns:0 frame:0
>   TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
>   collisions:0 txqueuelen:0
>   RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
>
> eth0  Link encap:Ethernet  HWaddr 00:50:56:81:28:f4
>   inet addr:192.168.0.2  Bcast:192.168.0.255  Mask:255.255.255.0
>   inet6 addr: fe80::250:56ff:fe81:28f4/64 Scope:Link
>   UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>   RX packets:535 errors:0 dropped:10 overruns:0 frame:0
>   TX packets:554 errors:0 dropped:0 overruns:0 carrier:0
>   collisions:0 txqueuelen:1000
>   RX bytes:137612 (137.6 KB)  TX bytes:108783 (108.7 KB)
>
> eth1  Link encap:Ethernet  HWaddr 00:50:56:81:44:e7
>   inet addr:10.10.10.1  Bcast:10.10.10.255  Mask:255.255.255.0
>   inet6 addr: fe80::250:56ff:fe81:44e7/64 Scope:Link
>   UP BROADCAST RUNNING MULTICAST  MTU:1500  Me

Re: [Openstack] [essex vlan]cannot ping vm on other compute node

2013-02-27 Thread Aaron Rosen

Perhaps:

interface gigbbit 0/22
switchport mode trunk
switchport trunk encapsulation dot1q
switchport trunk allowed vlan 1-4094
interface gigbbit 0/23
switchport mode trunk
switchport trunk encapsulation dot1q
switchport trunk allowed vlan 1-4094



On Wed, Feb 27, 2013 at 12:02 AM, Ajiva Fan  wrote:
>
> since i notice that in switcher:
> sw-31>show interface fastEthernet 0/22 trunk
>
> PortMode Encapsulation  StatusNative vlan
> Fa0/22  on   802.1q trunking  1
>
> Port  Vlans allowed on trunk
> Fa0/22  1-4094
>
> PortVlans allowed and active in management domain
> Fa0/22  
> 1,5,7,10-12,16,18-21,27,30,40,50,60,80,88,96,100-101,123,160,192,302-303,600,602,700,800,1000-1001
>
> PortVlans in spanning tree forwarding state and not pruned
> Fa0/22  
> 1,5,7,10-12,16,18-21,27,30,40,50,60,80,88,96,100-101,123,160,192,302-303,600,602,700,800,1000-1001
>
> the vlan 5 is active in management domain but 105 is not, so i try the
> same workflow as before but change vlan id 5 to 110, ping gets no
> reply as vlan105
>
> so may be i should add vlan105 to active list ? sorry i'm a green hand
> to switcher and got confused.
> 1) what the different between the allowd list and active list
> 2) if i should add active list manually, so does the cloud admin, if
> he create a vlan for a tenant, he should add to switcher active list
> too? is there any way automatically recoginize the vlan tag and allow
> it pass?
> maybe add a range to active list, for example, 100-4000? it's ugly..

___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] [essex vlan]cannot ping vm on other compute node

2013-02-26 Thread Aaron Rosen

inline

On Tue, Feb 26, 2013 at 10:51 PM, Ajiva Fan  wrote:

> greeting, stackers
>
> i deploy essex with flatdhcp, it works for a long time, but currently
> i want to use vlan network, so i deploy a new environment everything
> is same as the previous one, just use vlan network.
>
> here is the probelm:
> i cannot ping vm on other compute node
>
> control node (all-in-one)
> public nic(eth0): 172.16.1.12
> vlan nic(eth1):
> vlan105
> br105 10.0.12.6
> compute node(nova-compute, nova-network)
> public nic(eth0): 172.16.1.13
> vlan nic(eth1):
> vlan105
> br105 10.0.12.4
>
> now i create 2 vm, one is 10.0.12.5 on control node, another one is
> 10.0.12.3 on compute node
>
> i cannot ping 10.0.12.4 from control node, so i cannot ping 10.0.12.3
> neither
>
> using tcpdump -nnxx -i eth1 host 10.0.12.3, i capture ARP package from
> control node with vlan tag 8100 0069 0806 0001 0800 0604, so i think
> it works right so far. but on compute node i use tcpdump -i eth1 host
> 10.0.12.3 and get nothing.
>
> the cables connect to eth1 are plugged into a cisco catalyst 2950
> swither port 22 and 23, working under trunk mode, it allows all vlan
> by default
>
> i guess the problem may be caused by wrong setting of switcher since
> packets are dropped, but i'm not very sure.
>
>
You could do:

on host connected to port 22 on the switch
vconfig add eth1 5
ifconfig eth0.5 10.2.2.2/24

on host connected on port 23
vconfig add eth1 5
ifconfig eth0.5 10.2.2.3/24

and then try to ping through the switch (ping 10.2.2.2) in order switch to
rule it out.


> after two days search answer on the internet, i've no idea how to
> solve this question, so please help me
>
> ___
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] [essex vlan]cannot ping vm on other compute node

2013-02-26 Thread Aaron Rosen

On Tue, Feb 26, 2013 at 11:02 PM, Aaron Rosen  wrote:

> inline
>
> On Tue, Feb 26, 2013 at 10:51 PM, Ajiva Fan  wrote:
>
>> greeting, stackers
>>
>> i deploy essex with flatdhcp, it works for a long time, but currently
>> i want to use vlan network, so i deploy a new environment everything
>> is same as the previous one, just use vlan network.
>>
>> here is the probelm:
>> i cannot ping vm on other compute node
>>
>> control node (all-in-one)
>> public nic(eth0): 172.16.1.12
>> vlan nic(eth1):
>> vlan105
>> br105 10.0.12.6
>> compute node(nova-compute, nova-network)
>> public nic(eth0): 172.16.1.13
>> vlan nic(eth1):
>> vlan105
>> br105 10.0.12.4
>>
>> now i create 2 vm, one is 10.0.12.5 on control node, another one is
>> 10.0.12.3 on compute node
>>
>> i cannot ping 10.0.12.4 from control node, so i cannot ping 10.0.12.3
>> neither
>>
>> using tcpdump -nnxx -i eth1 host 10.0.12.3, i capture ARP package from
>> control node with vlan tag 8100 0069 0806 0001 0800 0604, so i think
>> it works right so far. but on compute node i use tcpdump -i eth1 host
>> 10.0.12.3 and get nothing.
>>
>> the cables connect to eth1 are plugged into a cisco catalyst 2950
>> swither port 22 and 23, working under trunk mode, it allows all vlan
>> by default
>>
>> i guess the problem may be caused by wrong setting of switcher since
>> packets are dropped, but i'm not very sure.
>>
>>
> You could do:
>
> on host connected to port 22 on the switch
> vconfig add eth1 5
> ifconfig eth0.5 10.2.2.2/24
>
> on host connected on port 23
> vconfig add eth1 5
> ifconfig eth0.5 10.2.2.3/24
>
> and then try to ping through the switch (ping 10.2.2.2) in order switch to
> rule it out.
>
>
** In order to rule the switch out.


> after two days search answer on the internet, i've no idea how to
>> solve this question, so please help me
>>
>> ___
>> Mailing list: https://launchpad.net/~openstack
>> Post to : openstack@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~openstack
>> More help   : https://help.launchpad.net/ListHelp
>>
>
>
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] VM doesnt get IP

2013-02-23 Thread Aaron Rosen

As long as there is ip connectivity between the networks it doesn't matter
if you are using  tunnels.


On Sat, Feb 23, 2013 at 8:09 AM, Rahul Sharma wrote:

> In one config, you have specified local_ip as 10.10.10.1 and in other as
> 192.168.3.3 . Doesn't they should belong to same network? As per the doc,
> it should be 10.10.10.3? Plus, these both belong to Data-Network, which is
> not controller-network communication but compute-network communication.
>
> -Regards
> Rahul
>
>
> On Sat, Feb 23, 2013 at 12:53 AM, Aaron Rosen  wrote:
>
>> >From the network+controller node can you ping to 192.168.3.3 (just to
>> confirm there is ip connectivity between those).
>>
>> Your configs look fine to me. The issue you are having is that your
>> network+controller node doesn't have a tunnel to your HV node. I'd suggest
>> restarting  the quantum-plugin-openvswitch-agent service on both nodes and
>> see if that does the trick in order to get the agent to add the tunnel for
>> you. Perhaps you edited this file and didn't restart the agent?
>>
>> Aaron
>>
>> On Fri, Feb 22, 2013 at 10:55 AM, Guilherme Russi <
>> luisguilherme...@gmail.com> wrote:
>>
>>> Here is my controller + network node:
>>>
>>> cat /etc/quantum/plugins/openvswitch/ovs_quantum_plugin.ini
>>> [DATABASE]
>>> # This line MUST be changed to actually run the plugin.
>>> # Example:
>>> # sql_connection = mysql://root:nova@127.0.0.1:3306/ovs_quantum
>>> # Replace 127.0.0.1 above with the IP address of the database used by the
>>> # main quantum server. (Leave it as is if the database runs on this
>>> host.)
>>> sql_connection = mysql://quantum:password@localhost:3306/quantum
>>> # Database reconnection retry times - in event connectivity is lost
>>> # set to -1 implies an infinite retry count
>>> # sql_max_retries = 10
>>> # Database reconnection interval in seconds - in event connectivity is
>>> lost
>>> reconnect_interval = 2
>>>
>>> [OVS]
>>> # (StrOpt) Type of network to allocate for tenant networks. The
>>> # default value 'local' is useful only for single-box testing and
>>> # provides no connectivity between hosts. You MUST either change this
>>> # to 'vlan' and configure network_vlan_ranges below or change this to
>>> # 'gre' and configure tunnel_id_ranges below in order for tenant
>>> # networks to provide connectivity between hosts. Set to 'none' to
>>> # disable creation of tenant networks.
>>> #
>>> # Default: tenant_network_type = local
>>> # Example: tenant_network_type = gre
>>> tenant_network_type = gre
>>>
>>> # (ListOpt) Comma-separated list of
>>> # [::] tuples enumerating ranges
>>> # of VLAN IDs on named physical networks that are available for
>>> # allocation. All physical networks listed are available for flat and
>>> # VLAN provider network creation. Specified ranges of VLAN IDs are
>>> # available for tenant network allocation if tenant_network_type is
>>> # 'vlan'. If empty, only gre and local networks may be created.
>>> #
>>> # Default: network_vlan_ranges =
>>> # Example: network_vlan_ranges = physnet1:1000:2999
>>>
>>> # (BoolOpt) Set to True in the server and the agents to enable support
>>> # for GRE networks. Requires kernel support for OVS patch ports and
>>> # GRE tunneling.
>>> #
>>> # Default: enable_tunneling = False
>>> enable_tunneling = True
>>>
>>> # (ListOpt) Comma-separated list of : tuples
>>> # enumerating ranges of GRE tunnel IDs that are available for tenant
>>> # network allocation if tenant_network_type is 'gre'.
>>> #
>>> # Default: tunnel_id_ranges =
>>> # Example: tunnel_id_ranges = 1:1000
>>> tunnel_id_ranges = 1:1000
>>>
>>> # Do not change this parameter unless you have a good reason to.
>>> # This is the name of the OVS integration bridge. There is one per
>>> hypervisor.
>>> # The integration bridge acts as a virtual "patch bay". All VM VIFs are
>>> # attached to this bridge and then "patched" according to their network
>>> # connectivity.
>>> #
>>> # Default: integration_bridge = br-int
>>> integration_bridge = br-int
>>>
>>> # Only used for the agent if tunnel_id_ranges (above) is not empty for
>>> # the server.  In most cases, the default value should be

Re: [Openstack] VM doesnt get IP

2013-02-22 Thread Aaron Rosen

ctivity between hosts. You MUST either change this
> # to 'vlan' and configure network_vlan_ranges below or change this to
> # 'gre' and configure tunnel_id_ranges below in order for tenant
> # networks to provide connectivity between hosts. Set to 'none' to
> # disable creation of tenant networks.
> #
> # Default: tenant_network_type = local
> # Example: tenant_network_type = gre
> tenant_network_type = gre
>
> # (ListOpt) Comma-separated list of
> # [::] tuples enumerating ranges
> # of VLAN IDs on named physical networks that are available for
> # allocation. All physical networks listed are available for flat and
> # VLAN provider network creation. Specified ranges of VLAN IDs are
> # available for tenant network allocation if tenant_network_type is
> # 'vlan'. If empty, only gre and local networks may be created.
> #
> # Default: network_vlan_ranges =
> # Example: network_vlan_ranges = physnet1:1000:2999
>
> # (BoolOpt) Set to True in the server and the agents to enable support
> # for GRE networks. Requires kernel support for OVS patch ports and
> # GRE tunneling.
> #
> # Default: enable_tunneling = False
> enable_tunneling = True
>
> # (ListOpt) Comma-separated list of : tuples
> # enumerating ranges of GRE tunnel IDs that are available for tenant
> # network allocation if tenant_network_type is 'gre'.
> #
> # Default: tunnel_id_ranges =
> # Example: tunnel_id_ranges = 1:1000
> tunnel_id_ranges = 1:1000
>
> # Do not change this parameter unless you have a good reason to.
> # This is the name of the OVS integration bridge. There is one per
> hypervisor.
> # The integration bridge acts as a virtual "patch bay". All VM VIFs are
> # attached to this bridge and then "patched" according to their network
> # connectivity.
> #
> # Default: integration_bridge = br-int
> integration_bridge = br-int
>
> # Only used for the agent if tunnel_id_ranges (above) is not empty for
> # the server.  In most cases, the default value should be fine.
> #
> # Default: tunnel_bridge = br-tun
> tunnel_bridge = br-tun
>
> # Uncomment this line for the agent if tunnel_id_ranges (above) is not
> # empty for the server. Set local-ip to be the local IP address of
> # this hypervisor.
> #
> # Default: local_ip = 10.0.0.3
> local_ip = 192.168.3.3
>
> The 10.10.10.1 is the Data Network from network controller (following the
> tutorial), and it is in the eth0:0 (I'm not pretty sure, but i guess the
> data from the VMs should communicate with this IP).
>
>
>
>
>
> 2013/2/22 Aaron Rosen 
>
>> Running with two nics for this should be fine for tunneling as ip routing
>> would handle which nic the packets should go out. From what you pasted I
>> see that one HV has a gre tunnel setup to 10.10.10.1 <-- Who is that host?
>> Can you attach your /etc/quantum/plugins/openvswitch/ovs_quantum_plugin.ini
>> on your nodes.
>>
>> I suspect the issue is a configuration issue in the [OVS] section. You'll
>> need something along the lines of this in that section:
>> [OVS]
>> local_ip = 
>> enable_tunneling = True
>> tunnel_id_ranges = 1:1000
>> tenant_network_type = gre
>>
>>
>>
>>
>> On Fri, Feb 22, 2013 at 9:54 AM, Guilherme Russi <
>> luisguilherme...@gmail.com> wrote:
>>
>>> Hello Aaron,
>>>
>>>  Sorry about attaching the infos, about the quantum agent, is it the
>>> quantum-plugin-openvswitch-agent? If i was, the job is already ruunning at
>>> the controller and the compute nodes:
>>>
>>> service quantum-plugin-openvswitch-agent start
>>> start: Job is already running: quantum-plugin-openvswitch-agent
>>>
>>>  Is there another thing i should do? I'm running my controller node and
>>> the network node at the same machine with 2 NICs, maybe can be a problem
>>> how i am making my network config?
>>>
>>> Thanks again.
>>>
>>> Guilherme.
>>>
>>>
>>> 2013/2/22 Aaron Rosen 
>>>
>>>> Hi Guilherme,
>>>>
>>>> (next time please paste these in the email rather than attaching, thx).
>>>>
>>>>
>>>> From the text in the attachment (show below). It seems like you are not
>>>> running the quantum-openvswitch-agent on your network node as there is no
>>>> GRE tunnel from that to your compute node. Once you have
>>>>  quantum-openvswitch-agent running on all your machines you should be able
>>>> to run ovs-dpctl looking under br-tun and see a tunnel between each

Re: [Openstack] VM doesnt get IP

2013-02-22 Thread Aaron Rosen

Running with two nics for this should be fine for tunneling as ip routing
would handle which nic the packets should go out. From what you pasted I
see that one HV has a gre tunnel setup to 10.10.10.1 <-- Who is that host?
Can you attach your /etc/quantum/plugins/openvswitch/ovs_quantum_plugin.ini
on your nodes.

I suspect the issue is a configuration issue in the [OVS] section. You'll
need something along the lines of this in that section:
[OVS]
local_ip = 
enable_tunneling = True
tunnel_id_ranges = 1:1000
tenant_network_type = gre




On Fri, Feb 22, 2013 at 9:54 AM, Guilherme Russi  wrote:

> Hello Aaron,
>
>  Sorry about attaching the infos, about the quantum agent, is it the
> quantum-plugin-openvswitch-agent? If i was, the job is already ruunning at
> the controller and the compute nodes:
>
> service quantum-plugin-openvswitch-agent start
> start: Job is already running: quantum-plugin-openvswitch-agent
>
>  Is there another thing i should do? I'm running my controller node and
> the network node at the same machine with 2 NICs, maybe can be a problem
> how i am making my network config?
>
> Thanks again.
>
> Guilherme.
>
>
> 2013/2/22 Aaron Rosen 
>
>> Hi Guilherme,
>>
>> (next time please paste these in the email rather than attaching, thx).
>>
>> From the text in the attachment (show below). It seems like you are not
>> running the quantum-openvswitch-agent on your network node as there is no
>> GRE tunnel from that to your compute node. Once you have
>>  quantum-openvswitch-agent running on all your machines you should be able
>> to run ovs-dpctl looking under br-tun and see a tunnel between each host.
>>
>> Aaron
>>
>> CONTROLLER + NETWORK NODE:
>> system@br-tun:
>> lookups: hit:0 missed:0 lost:0
>> flows: 0
>>  port 0: br-tun (internal)
>> port 1: patch-int (patch: peer=patch-tun)
>> system@br-int:
>>  lookups: hit:0 missed:0 lost:0
>> flows: 0
>> port 0: br-int (internal)
>>  port 1: tap817d2f70-a0 (internal)
>> port 2: qr-ea64e9aa-31 (internal)
>> port 3: patch-tun (patch: peer=patch-int)
>> system@br-ex:
>> lookups: hit:0 missed:0 lost:0
>> flows: 0
>> port 0: br-ex (internal)
>>  port 2: qg-95fe3fa1-d1 (internal)
>>
>>
>> COMPUTE NODES
>>
>> COMPUTE NODE 01:
>> ovs-dpctl show
>> system@br-int:
>> lookups: hit:380 missed:7590 lost:0
>> flows: 0
>> port 0: br-int (internal)
>>  port 2: patch-tun (patch: peer=patch-int)
>> port 3: qvo981ae82e-d4
>> port 6: qvoc9df3a96-5f
>>  port 7: qvoc153ac28-ae
>> port 8: qvo722a5d05-e4
>> system@br-tun:
>> lookups: hit:381 missed:7589 lost:0
>>  flows: 0
>> port 0: br-tun (internal)
>> port 1: patch-int (patch: peer=patch-tun)
>>  port 2: gre-1 (gre: key=flow, remote_ip=10.10.10.1)
>>
>>
>> On Fri, Feb 22, 2013 at 8:47 AM, Guilherme Russi <
>> luisguilherme...@gmail.com> wrote:
>>
>>> So guys, any idea about what am i missing?
>>>
>>> Thanks.
>>>
>>>
>>>
>>>
>>> 2013/2/22 Guilherme Russi 
>>>
>>>> Hello Aaron,
>>>>
>>>>  Here are the outputs.
>>>>
>>>>
>>>> Thanks.
>>>>
>>>> Guilherme.
>>>>
>>>>
>>>> 2013/2/21 Aaron Rosen 
>>>>
>>>>> The output to the following would be a good start:
>>>>>
>>>>> quantum net-list
>>>>> quantum port-list
>>>>> ovs-dpctl show (on all nodes)
>>>>>
>>>>> Also make sure the quantum-dhcp-agent is running on your network node.
>>>>>
>>>>> Aaron
>>>>>
>>>>> On Thu, Feb 21, 2013 at 11:23 AM, Guilherme Russi <
>>>>> luisguilherme...@gmail.com> wrote:
>>>>>
>>>>>> Sorry about that, I'm using Folsom release with quantum, I'm
>>>>>> installing the controller node and the network node in the same physical
>>>>>> machine, I'm following this tutorial:
>>>>>>
>>>>>>
>>>>>> http://docs.openstack.org/folsom/basic-install/content/basic-install_controller.html
>>>>>>
>>>>>> Which config files do you need?
>>>>>>
>>>>>> Thanks.
>>>>>>
>>>>>> Guilherme.
>>>>>>
>>>>>>
>>>>>> 2013/2/21 Aaron Rosen 
>>>>>>
>>>>

Re: [Openstack] VM doesnt get IP

2013-02-22 Thread Aaron Rosen

Hi Guilherme,

(next time please paste these in the email rather than attaching, thx).

>From the text in the attachment (show below). It seems like you are not
running the quantum-openvswitch-agent on your network node as there is no
GRE tunnel from that to your compute node. Once you have
 quantum-openvswitch-agent running on all your machines you should be able
to run ovs-dpctl looking under br-tun and see a tunnel between each host.

Aaron

CONTROLLER + NETWORK NODE:
system@br-tun:
lookups: hit:0 missed:0 lost:0
flows: 0
port 0: br-tun (internal)
port 1: patch-int (patch: peer=patch-tun)
system@br-int:
lookups: hit:0 missed:0 lost:0
flows: 0
port 0: br-int (internal)
port 1: tap817d2f70-a0 (internal)
port 2: qr-ea64e9aa-31 (internal)
port 3: patch-tun (patch: peer=patch-int)
system@br-ex:
lookups: hit:0 missed:0 lost:0
flows: 0
port 0: br-ex (internal)
port 2: qg-95fe3fa1-d1 (internal)


COMPUTE NODES

COMPUTE NODE 01:
ovs-dpctl show
system@br-int:
lookups: hit:380 missed:7590 lost:0
flows: 0
port 0: br-int (internal)
port 2: patch-tun (patch: peer=patch-int)
port 3: qvo981ae82e-d4
port 6: qvoc9df3a96-5f
port 7: qvoc153ac28-ae
port 8: qvo722a5d05-e4
system@br-tun:
lookups: hit:381 missed:7589 lost:0
flows: 0
port 0: br-tun (internal)
port 1: patch-int (patch: peer=patch-tun)
port 2: gre-1 (gre: key=flow, remote_ip=10.10.10.1)


On Fri, Feb 22, 2013 at 8:47 AM, Guilherme Russi  wrote:

> So guys, any idea about what am i missing?
>
> Thanks.
>
>
>
>
> 2013/2/22 Guilherme Russi 
>
>> Hello Aaron,
>>
>>  Here are the outputs.
>>
>>
>> Thanks.
>>
>> Guilherme.
>>
>>
>> 2013/2/21 Aaron Rosen 
>>
>>> The output to the following would be a good start:
>>>
>>> quantum net-list
>>> quantum port-list
>>> ovs-dpctl show (on all nodes)
>>>
>>> Also make sure the quantum-dhcp-agent is running on your network node.
>>>
>>> Aaron
>>>
>>> On Thu, Feb 21, 2013 at 11:23 AM, Guilherme Russi <
>>> luisguilherme...@gmail.com> wrote:
>>>
>>>> Sorry about that, I'm using Folsom release with quantum, I'm installing
>>>> the controller node and the network node in the same physical machine, I'm
>>>> following this tutorial:
>>>>
>>>>
>>>> http://docs.openstack.org/folsom/basic-install/content/basic-install_controller.html
>>>>
>>>> Which config files do you need?
>>>>
>>>> Thanks.
>>>>
>>>> Guilherme.
>>>>
>>>>
>>>> 2013/2/21 Aaron Rosen 
>>>>
>>>>> Hi,
>>>>>
>>>>> You'll have to provide more information than this for anyone to help
>>>>> you: i.e are you using quantum or nova-network, if your using quantum 
>>>>> which
>>>>> plugin, config files etc.
>>>>>
>>>>> Aaron
>>>>>
>>>>> On Thu, Feb 21, 2013 at 11:13 AM, Guilherme Russi <
>>>>> luisguilherme...@gmail.com> wrote:
>>>>>
>>>>>> Hello guys,
>>>>>>
>>>>>>  I'm getting problem in my VMs' creation, they don't get IP, the log
>>>>>> piece shows:
>>>>>>
>>>>>>
>>>>>> Starting network...
>>>>>> udhcpc (v1.18.5) started
>>>>>> Sending discover...
>>>>>> Sending discover...
>>>>>> Sending discover...
>>>>>> No lease, failing
>>>>>> WARN: /etc/rc3.d/S40-network failed
>>>>>>
>>>>>>
>>>>>>  Do you have any idea how I can solve it?
>>>>>>
>>>>>> Thank you so much.
>>>>>>
>>>>>> Guilherme.
>>>>>>
>>>>>>
>>>>>> ___
>>>>>> Mailing list: https://launchpad.net/~openstack
>>>>>> Post to : openstack@lists.launchpad.net
>>>>>> Unsubscribe : https://launchpad.net/~openstack
>>>>>> More help   : https://help.launchpad.net/ListHelp
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] VM doesnt get IP

2013-02-21 Thread Aaron Rosen

The output to the following would be a good start:

quantum net-list
quantum port-list
ovs-dpctl show (on all nodes)

Also make sure the quantum-dhcp-agent is running on your network node.

Aaron

On Thu, Feb 21, 2013 at 11:23 AM, Guilherme Russi <
luisguilherme...@gmail.com> wrote:

> Sorry about that, I'm using Folsom release with quantum, I'm installing
> the controller node and the network node in the same physical machine, I'm
> following this tutorial:
>
>
> http://docs.openstack.org/folsom/basic-install/content/basic-install_controller.html
>
> Which config files do you need?
>
> Thanks.
>
> Guilherme.
>
>
> 2013/2/21 Aaron Rosen 
>
>> Hi,
>>
>> You'll have to provide more information than this for anyone to help you:
>> i.e are you using quantum or nova-network, if your using quantum which
>> plugin, config files etc.
>>
>> Aaron
>>
>> On Thu, Feb 21, 2013 at 11:13 AM, Guilherme Russi <
>> luisguilherme...@gmail.com> wrote:
>>
>>> Hello guys,
>>>
>>>  I'm getting problem in my VMs' creation, they don't get IP, the log
>>> piece shows:
>>>
>>>
>>> Starting network...
>>> udhcpc (v1.18.5) started
>>> Sending discover...
>>> Sending discover...
>>> Sending discover...
>>> No lease, failing
>>> WARN: /etc/rc3.d/S40-network failed
>>>
>>>
>>>  Do you have any idea how I can solve it?
>>>
>>> Thank you so much.
>>>
>>> Guilherme.
>>>
>>>
>>> ___
>>> Mailing list: https://launchpad.net/~openstack
>>> Post to : openstack@lists.launchpad.net
>>> Unsubscribe : https://launchpad.net/~openstack
>>> More help   : https://help.launchpad.net/ListHelp
>>>
>>>
>>
>
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] VM doesnt get IP

2013-02-21 Thread Aaron Rosen

Hi,

You'll have to provide more information than this for anyone to help you:
i.e are you using quantum or nova-network, if your using quantum which
plugin, config files etc.

Aaron

On Thu, Feb 21, 2013 at 11:13 AM, Guilherme Russi <
luisguilherme...@gmail.com> wrote:

> Hello guys,
>
>  I'm getting problem in my VMs' creation, they don't get IP, the log piece
> shows:
>
>
> Starting network...
> udhcpc (v1.18.5) started
> Sending discover...
> Sending discover...
> Sending discover...
> No lease, failing
> WARN: /etc/rc3.d/S40-network failed
>
>
>  Do you have any idea how I can solve it?
>
> Thank you so much.
>
> Guilherme.
>
>
> ___
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>
>
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] Doubt with apt-get

2013-02-18 Thread Aaron Rosen

Anything is possible with upgrading but hopefully not :P

On Mon, Feb 18, 2013 at 4:18 AM, Guilherme Russi  wrote:

> Hello guys,
>
>  I got a message from my Ubuntu Server 12.04 about upgrade somethings, the
> upgrades include Linux Headers and some upgrades for openstack's
> components. My question is, if I apply the upgrades, my openstack system
> can break off?
>
> Thank you.
>
> Guilherme.
>
> ___
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>
>
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] How to ping/ssh instance outside openstack server?

2013-02-17 Thread Aaron Rosen

The issue is your laptop doesn't have a route to that network.  Try running
this on your laptop to see if this makes it work:

sudo ip route add 192.168.4.0/24  dev wlan0 # replace wlan0 with the
correct interface

If that doesn't work perhaps give this one a shot:

route add -net 192.168.4.0 netmask 255.255.255.0 gw 192.168.1.10 dev wlan0
# replace wlan0 with correct interface

The correct solution though is to add a static route for 192.168.4.0/24 to
192.168.4.1 on your router.

Aaron

On Sun, Feb 17, 2013 at 9:25 PM, jeffty  wrote:

> Hello,
>
> I installed openstack in my PC. The IP of my router is 192.168.1.1 and
> the PC's nic IP is static - 192.168.1.2.
>
> Then I created images and instances, assigned private IP as manual
> states in website. e.g. 192.168.4.40.
>
> I can ping/ssh instance in PC 192.168.1.10. But fail to do that in my
> laptop(IP: 192.168.1.3).
>
> How to access instance then? Do I need to configure sth for that?
>
> And I found that if I run
>
> sudo kvm -m xxx file=linux.img ... -vnc :0
>
> The instance can access Internet. But if it's running automatically by
> Nova, I cannot connect to Internet when SSH/VNC onto it.
>
> Thanks a lot.
>
> ___
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] brctl meltdown on RHEL 6.3

2013-02-11 Thread Aaron Rosen

Which plugin are you trying to use? You mentioned both linuxbridge and
openvswitch in your email.

Aaron

On Mon, Feb 11, 2013 at 8:33 AM, Greg Chavez  wrote:

>
> Running latest EPEL Folsom packages on RHEL 6.3.  Three nodes right now,
> one controller, one network node, one compute node.  The network node has
> three NICs, one for external net, one for management net, one for VM
> network traffic.  It has been a miserable journey so far.
>
> The lastest calamity began with a failed spawn of the Cirros test image.
>  I booted it like this:
>
> # nova --os-username demo --os-password demo --os-tenant-name demoProject
> boot --image aefa581f-47b0-4d46-8dbc-1a1f7f02dfa0 --flavor 2  --nic
> net-id=3de1e780-07d1-42af-89cc-0feaf1ece6e9 server-01
>
> This succeeded but went directly into an ERROR state.  The compute node's
> /var/log/nova/compute.log showed this:
>
> ProcessExecutionError: Unexpected error while running command.
> Command: sudo nova-rootwrap /etc/nova/rootwrap.conf brctl addbr
> qbr2218b8c4-7d
> Exit code: 1
> Stdout: ''
> Stderr: 'add bridge failed: Package not installed\n'
>
> Hrm.  So then I ran this:
>
> # brctl show
> bridge name bridge id STP enabled interfaces
> br-eth1 /sys/class/net/br-eth1/bridge: No such file or directory
> /sys/class/net/br-eth1/bridge: No such file or directory
> /sys/class/net/br-eth1/bridge: No such file or directory
> /sys/class/net/br-eth1/bridge: No such file or directory
> /sys/class/net/br-eth1/bridge: No such file or directory
> /sys/class/net/br-eth1/bridge: No such file or directory
> /sys/class/net/br-eth1/bridge: No such file or directory
> /sys/class/net/br-eth1/bridge: No such file or directory
> /sys/class/net/br-eth1/bridge: No such file or directory
> /sys/class/net/br-eth1/bridge: No such file or directory
> /sys/class/net/br-eth1/bridge: No such file or directory
> /sys/class/net/br-eth1/bridge: No such file or directory
> .bc305befedd1 no
> br-int /sys/class/net/br-int/bridge: No such file or directory
> /sys/class/net/br-int/bridge: No such file or directory
> /sys/class/net/br-int/bridge: No such file or directory
> /sys/class/net/br-int/bridge: No such file or directory
> /sys/class/net/br-int/bridge: No such file or directory
> /sys/class/net/br-int/bridge: No such file or directory
> /sys/class/net/br-int/bridge: No such file or directory
> /sys/class/net/br-int/bridge: No such file or directory
> /sys/class/net/br-int/bridge: No such file or directory
> /sys/class/net/br-int/bridge: No such file or directory
> /sys/class/net/br-int/bridge: No such file or directory
> /sys/class/net/br-int/bridge: No such file or directory
> .7e1636f42c4b no
>
> GAH!   What!!! First of all, bridge capability is set by default in the
> RHEL 6.3 kernel.  Secondly, nova knows that it's supposed to be using
> openvswitch.  The ProcessExecutionError's trace showed that the offending
> code came from /usr/lib/python2.6/site-packages/nova/virt/libvirt/vif.py
> line 216 which has this comment:
>
> def plug(self, instance, vif):
> """Plug using hybrid strategy
>
> Create a per-VIF linux bridge, then link that bridge to the OVS
> integration bridge via a veth device, setting up the other end
> of the veth device just like a normal OVS port.  Then boot the
> VIF on the linux bridge using standard libvirt mechanisms
> """
>
> Thirdly, ovs-vsctrl is happy:
>
> # ovs-vsctl show
> 44435595-8cc8-469c-ace4-ded76a7b864d
> Bridge "br-eth1"
> Port "br-eth1"
> Interface "br-eth1"
> type: internal
> Port "phy-br-eth1"
> Interface "phy-br-eth1"
> Port "eth1"
> Interface "eth1"
> Bridge br-int
> Port "int-br-eth1"
> Interface "int-br-eth1"
> Port br-int
> Interface br-int
> type: internal
> ovs_version: "1.7.3"
>
> Final note, my network node fails the same way, but the controller does
> not.
>
> I hope so much that somebody knows what is going on here.  This is very
> terrible for me as I am struggling to achieve minimal functionality.
>  Thanks.
>
> --
> \*..+.-
> --Greg Chavez
> +//..;};
>
> ___
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>
>
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] Network cannot be found

2013-02-10 Thread Aaron Rosen

Hi Greg,

I checked out why this can happen and I think the reason you are getting
this is because you are trying to create a vm as an admin user on a network
that you are not the owner.

https://github.com/openstack/nova/blob/master/nova/network/quantumv2/api.py#L95

Thanks,

Aaron


On Sun, Feb 10, 2013 at 4:28 PM, Greg Chavez  wrote:

> This has me utterly befuddled.  All I'm trying to do is bring up a Cirros
> VM on my 3-node controller+network+compute Folsom setup.  So nova is
> configured on the controller to use quantum:
>
> network_api_class = nova.network.quantumv2.api.API
> quantum_admin_username = quantum
> quantum_admin_password = quantum
> quantum_admin_auth_url = http://192.168.241.100:35357/v2.0
> quantum_auth_strategy = keystone
> quantum_admin_tenant_name = service
> quantum_url = http://192.168.241.100:9696
>
> 192.168.241.100 is the controller management port IP.
>
> I have the following network available:
>
> # quantum net-list | grep demo-net
> | 3de1e780-07d1-42af-89cc-0feaf1ece6e9 | demo-net |
> 7f54d28f-b87a-43f7-a15f-1c0d20569e2a |
>
> # quantum subnet-list | grep 7f54d28f
> | 7f54d28f-b87a-43f7-a15f-1c0d20569e2a |  | 192.168.1.0/24 |
> {"start": "192.168.1.2", "end": "192.168.1.254"} |
>
> # quantum net-show 3de1e780-07d1-42af-89cc-0feaf1ece6e9
> +---+--+
> | Field | Value|
> +---+--+
> | admin_state_up| True |
> | id| 3de1e780-07d1-42af-89cc-0feaf1ece6e9 |
> | name  | demo-net |
> | provider:network_type | vlan |
> | provider:physical_network | physnet1 |
> | provider:segmentation_id  | 2001 |
> | router:external   | False|
> | shared| False|
> | status| ACTIVE   |
> | subnets   | 7f54d28f-b87a-43f7-a15f-1c0d20569e2a |
> | tenant_id | 6ea263cf12ce44e29d4d7baefacb9689 |
> +---+--+
>
> # quantum router-port-list 37d3b2dd-ad19-435b-b4b9-3edbcd812f58
> <..snip snip..>
> {"subnet_id": "7f54d28f-b87a-43f7-a15f-1c0d20569e2a", "ip_address":
> "192.168.1.1"} |
> {"subnet_id": "e45987aa-2f3a-45e7-b9c8-7499d8eb93e6", "ip_address":
> "10.21.166.2"}
>
> So far so good.  From my perspective everything looks good.  But when I
> try to boot a vm it fails:
>
> # nova boot --image aefa581f-47b0-4d46-8dbc-1a1f7f02dfa0 --flavor 2 --nic
> net-id=3de1e780-07d1-42af-89cc-0feaf1ece6e9 --key-name demo-key server-01
> ERROR: The resource could not be found. (HTTP 404) (Request-ID:
> req-b0badcb3-244a-4e76-92b2-8bbabc645f3b)
>
> Looking in api.log I find this error:
>
> Caught error: Network 3de1e780-07d1-42af-89cc-0feaf1ece6e9 could not be
> found.
>
> WHAT! How is it not found?  It clearly exists, unless net-id is expecting
> something else as its value.  Argh.
>
> Thanks in advance.
>
> --
> \*..+.-
> --Greg Chavez
> +//..;};
>
> ___
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>
>
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] quantum net-list command get error

2013-02-08 Thread Aaron Rosen

Looks like you are missing this part:
http://docs.openstack.org/trunk/openstack-network/admin/content/keystone.html

Aaron

On Fri, Feb 8, 2013 at 12:55 PM, Rain Li  wrote:

> Hi all,
>
> When setting the virtual network on network-node with the basic-install
> guide, I failed to authenticate with the environment variables as suggested
> in novarc. Then I directly execute command quantum net-list with credential
> parameters contained. I get this error:
>
> DEBUG: quantumclient.quantum.v2_0.network.ListNetwork
> get_data(Namespace(columns=[], fields=[], filter_specs=[],
> formatter='table', quote_mode='nonnumeric', request_format='json',
> show_details=False))
> DEBUG: quantumclient.client REQ: curl -i http://10.0.0.1:35357/v2.0/tokens-X 
> POST -H "Content-Type: application/json" -H "Accept: application/json"
> -H "User-Agent: python-quantumclient"
>
> DEBUG: quantumclient.client REQ BODY: {"auth": {"tenantName": "admin",
> "passwordCredentials": {"username": "admin", "password": "password"}}}
>
> DEBUG: quantumclient.client RESP:{'date': 'Fri, 08 Feb 2013 20:44:56 GMT',
> 'transfer-encoding': 'chunked', 'status': '200', 'content-type':
> 'application/json', 'vary': 'X-Auth-Token'}
>
>
> ERROR: cliff.app An unknown exception occurred.
> Traceback (most recent call last):
>   File "/usr/lib/python2.7/dist-packages/cliff/app.py", line 218, in
> run_subcommand
> result = cmd.run(parsed_args)
>   File "/usr/lib/python2.7/dist-packages/quantumclient/common/command.py",
> line 35, in run
> return super(OpenStackCommand, self).run(parsed_args)
>   File "/usr/lib/python2.7/dist-packages/cliff/display.py", line 84, in run
> column_names, data = self.take_action(parsed_args)
>   File "/usr/lib/python2.7/dist-packages/quantumclient/common/command.py",
> line 41, in take_action
> return self.get_data(parsed_args)
>   File
> "/usr/lib/python2.7/dist-packages/quantumclient/quantum/v2_0/__init__.py",
> line 360, in get_data
> quantum_client = self.get_client()
>   File
> "/usr/lib/python2.7/dist-packages/quantumclient/quantum/v2_0/__init__.py",
> line 187, in get_client
> return self.app.client_manager.quantum
>   File
> "/usr/lib/python2.7/dist-packages/quantumclient/common/clientmanager.py",
> line 41, in __get__
> self._handle = self.factory(instance)
>   File "/usr/lib/python2.7/dist-packages/quantumclient/quantum/client.py",
> line 36, in make_client
> instance.initialize()
>   File
> "/usr/lib/python2.7/dist-packages/quantumclient/common/clientmanager.py",
> line 78, in initialize
> httpclient.authenticate()
>   File "/usr/lib/python2.7/dist-packages/quantumclient/client.py", line
> 207, in authenticate
> self._extract_service_catalog(body)
>   File "/usr/lib/python2.7/dist-packages/quantumclient/client.py", line
> 176, in _extract_service_catalog
> endpoint_type='adminURL')
>   File "/usr/lib/python2.7/dist-packages/quantumclient/client.py", line
> 80, in url_for
> raise exceptions.EndpointNotFound()
> EndpointNotFound: An unknown exception occurred.
> DEBUG: quantumclient.shell clean_up ListNetwork
> DEBUG: quantumclient.shell got an error: An unknown exception occurred.
>
> Does anyone know what's going on?
>
> Regards,
> Rain
>
> ___
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>
>
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] Can I use a window XP to submit the code?

2013-02-03 Thread Aaron Rosen

Yup, it can be done via this:

 git push ssh://review.openstack.org:29418/openstack/.git
HEAD:refs/for/

Aaron


On Sun, Feb 3, 2013 at 6:40 PM, Huang Zhiteng  wrote:

> Git-review is python script, therefore it's possible to install it onto
> windows system, however it is more convenient to use Linux, even with a
> virtual machine.
> On Feb 4, 2013 9:32 AM, "Xiazhihui (Hashui, IT)" 
> wrote:
>
>>  Hi All,
>>
>> ** **
>>
>>Can I use a window XP to submit the codes? Git-review cannot be
>> installed in Windows well, is it necessary ? Can anybody give me help.***
>> *
>>
>> ** **
>>
>>   Thank you. 
>>
>> ___
>> Mailing list: https://launchpad.net/~openstack
>> Post to : openstack@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~openstack
>> More help   : https://help.launchpad.net/ListHelp
>>
>>
> ___
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>
>
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] Quantum duplicate subnet creation

2013-01-17 Thread Aaron Rosen

Nova (network) does not support overlapping ip addresses so if you use nova
security groups directly this won't work. This should be fixed in G3 using
nova security groups with a nova to quantum security group proxy.
Until recently nova meta data did not work with overlapping ips but that
works now if you use the quantum-meta data agent. If you want to use
security groups with overlapping ips you can use quantum security groups
directly, though this only works with the linux bridge plugin currently
(soon the ovs and nvp plugin will support this once some patches merge
upstream).

Aaron

On Fri, Jan 18, 2013 at 12:09 AM, Balamurugan V G
wrote:

> Can some one thought more light on this?
>
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] Quantim duplicate subnet creation

2013-01-17 Thread Aaron Rosen

Hi,

Yup this is definitely possible. The reason why this isn't set by default
is that some distros don't ship kernels that build with CONFIG_NET_NS=y or
their iproute2 package is to outdated to support linux namespaces.  Also,
until recently nova's metadata service didn't support overlapping ips. If
you are running ubuntu 12.04 you should be able to set:

Q_ALLOW_OVERLAPPING_IP=True

in your localrc to enable this.

or edit your quantum.conf here and restart quantum to enable overlapping
ips.

# Enable or disable overlapping IPs for subnets
# Attention: the following parameter MUST be set to False if Quantum is
# being used in conjunction with nova security groups and/or metadata
service.
# allow_overlapping_ips = False


Aaron

p.s: I don't think this will work in a flat network setup though since
there is no way to isolate that. What plugin are you using?
> I have the following networks in a flat network setup.


On Thu, Jan 17, 2013 at 2:52 AM, Balamurugan V G wrote:

> Hi,
>
> Is there a way to create a duplicate network/subnet for tenant in quantum.
> Basically for a tenant, I want to have some instances(GroupA) share a
> subnet and another set of instances(GroupB) share the same(duplicate)
> subnet but GroupA and GroupB should be isolated. I have labnet which is the
> flat network to which one instance from each group is assigned for external
> connectivity. Then I want to have two private networks private1 and
> private2 both sharing the same subnet but I was to assign some instances to
> private1 and some in private2.
>
> I have the following networks in a flat network setup.
>
> root@openstack:~# quantum subnet-list
>
> +--+--+--+--+
> | id   | name | cidr |
> allocation_pools |
>
> +--+--+--+--+
> | abb62a74-ad15-452c-857f-ee0a1b388ede |  | 192.168.168.0/24 |
> {"start": "192.168.168.2", "end": "192.168.168.254"} |
> | eedc0c12-c3ed-42ce-a860-692e766087a2 |  | 10.5.12.0/24 |
> {"start": "10.5.12.21", "end": "10.5.12.25"} |
>
> +--+--+--+--+
> root@openstack:~#
>
>
> Now, the following gets denied.
>
> root@openstack:~# quantum subnet-create --tenant-id
> 7cda178971e84c5194c8531bf4f229d7  private2 192.168.168.0/24
> Invalid input for operation: Requested subnet with cidr: 192.168.168.0/24for 
> network: 64ec75d6-0c6f-44e1-a268-b573324c4160 overlaps with another
> subnet.
> root@openstack:~#
>
> I understand that a duplicate network with a tenant is not a common
> scenario and perhaps by design its not allowed.
>
> But there could be cases like I mentioned.
>
> Strangely, I am not allowed to create the duplicate network even across
> tenants. Atleast this should be allowed.
>
> BTW, I am running a single node Devstack.
>
> Regards,
> Balu
>
> ___
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>
>
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] What's the function of devstack？

2013-01-15 Thread Aaron Rosen

It allows one to setup an openstack deployment from source quickly (helpful
for developers) see http://devstack.org/faq.html.

There is no graphical interface except for horizon which you have to access
via a browser after stack.sh completes (if you install horizon).

Aaron

On Tue, Jan 15, 2013 at 12:32 AM, Jia Lee  wrote:

> Hi,
>
> Could someone tell me the function of devstack and will there be a
> graphical user interface when the 'stack.sh'  is executed?
>
>
> --
> 世界因你而精彩~
>
> ___
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>
>
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] quantum: two ips one vif

2012-10-23 Thread Aaron Rosen

Are the eth* interfaces up that are attached to the bridge?

On Tue, Oct 23, 2012 at 3:09 PM, Jason  wrote:

> Only one listed. What is more odd is that I am not seeing arps being
> returned so this issue seems to be at layer 2. Any other ideas?
>
> Jason
>
> On Oct 23, 2012, at 5:46 PM, Aaron Rosen  wrote:
>
> Do you have two default gateways in your instance when you type route -n ?
>
> Aaron
>
> On Tue, Oct 23, 2012 at 2:12 PM, Jason Ford  wrote:
>
>> This seems broke unless I have something weird going on in my ovs setup.
>> I can get quantum to assign the second IP address to the instance but when
>> trying to do anything to that second IP, traffic is blocked by something. I
>> have verified that iptables is updated on the hypervisor and I can see
>> flows in OVS inbound but no replies. I can even see the traffic making it
>> to the instance as well via tcpdump and also see the replies going out for
>> the initial ARP as well from inside the instance. The ARP never seems to
>> make it into OVS as a flow. Is Quantum missing a configuration for a flow
>> somewhere or is there something more I should look for? Does it work for
>> anyone else or did I hit a bug?
>>
>> jason
>>
>> - Original Message -
>> From: "Dan Wendlandt" 
>> To: "Jason Ford" 
>> Cc: openstack@lists.launchpad.net
>> Sent: Tuesday, October 23, 2012 12:55:42 AM
>> Subject: Re: [Openstack] quantum: two ips one vif
>>
>> by default, quantum will give a port one IP address from any v4 subnet
>> associated with the network, and one from any v6 subnet associated
>> with the subnet.  However, you can create your own port with multiple
>> subnets, and then boot a VM with that port.  You can create a port
>> with IPs from different subnets by using the --fixed-ip option twice,
>> each time specifying a different subnet.  See example below.
>>
>> Dan
>>
>>
>> nicira@com-dev:~/devstack$ quantum subnet-list -c id -c network_id -c
>> cidr
>>
>> +-+--+--+
>> | cidr| id   | network_id
>>  |
>>
>> +-+--+--+
>> | 10.0.0.0/16 | a26f5605-8400-45ef-82cc-ec62fae37a33 |
>> 9f930f56-ca54-41b9-bb68-688f009e2f75 |
>> | 20.0.0.0/24 | f1278823-d6e3-4237-ad55-7f2fe286994c |
>> 9f930f56-ca54-41b9-bb68-688f009e2f75 |
>>
>> +-+--+--+
>> nicira@com-dev:~/devstack$ quantum port-create --fixed-ip
>> subnet_id=a26f5605-8400-45ef-82cc-ec62fae37a33 --fixed-ip
>> subnet_id=f1278823-d6e3-4237-ad55-7f2fe286994c
>> 9f930f56-ca54-41b9-bb68-688f009e2f75
>> Created a new port:
>>
>> ++-+
>> | Field  | Value
>> |
>>
>> ++-+
>> | admin_state_up | True
>> |
>> | device_id  |
>> |
>> | device_owner   |
>> |
>> | fixed_ips  | {"subnet_id":
>> "a26f5605-8400-45ef-82cc-ec62fae37a33", "ip_address": "10.0.0.3"} |
>> || {"subnet_id":
>> "f1278823-d6e3-4237-ad55-7f2fe286994c", "ip_address": "20.0.0.3"} |
>> | id | 79f20e6f-7b95-44b0-90e6-bd0296c7aa54
>> |
>> | mac_address| fa:16:3e:05:69:ba
>> |
>> | name   |
>> |
>> | network_id | 9f930f56-ca54-41b9-bb68-688f009e2f75
>> |
>> | status | ACTIVE
>> |
>> | tenant_id  | b02686b6c8c44c75bd7459710ed81edb
>> |
>>
>> ++-+
>> nicira@com-dev:~/devstack$ nova image-list
>>
>> +--+-+++
>> | ID   | Name
>>   | Status | Server |
>>
>> +--+-++--

Re: [Openstack] quantum: two ips one vif

2012-10-23 Thread Aaron Rosen

Do you have two default gateways in your instance when you type route -n ?

Aaron

On Tue, Oct 23, 2012 at 2:12 PM, Jason Ford  wrote:

> This seems broke unless I have something weird going on in my ovs setup. I
> can get quantum to assign the second IP address to the instance but when
> trying to do anything to that second IP, traffic is blocked by something. I
> have verified that iptables is updated on the hypervisor and I can see
> flows in OVS inbound but no replies. I can even see the traffic making it
> to the instance as well via tcpdump and also see the replies going out for
> the initial ARP as well from inside the instance. The ARP never seems to
> make it into OVS as a flow. Is Quantum missing a configuration for a flow
> somewhere or is there something more I should look for? Does it work for
> anyone else or did I hit a bug?
>
> jason
>
> - Original Message -
> From: "Dan Wendlandt" 
> To: "Jason Ford" 
> Cc: openstack@lists.launchpad.net
> Sent: Tuesday, October 23, 2012 12:55:42 AM
> Subject: Re: [Openstack] quantum: two ips one vif
>
> by default, quantum will give a port one IP address from any v4 subnet
> associated with the network, and one from any v6 subnet associated
> with the subnet.  However, you can create your own port with multiple
> subnets, and then boot a VM with that port.  You can create a port
> with IPs from different subnets by using the --fixed-ip option twice,
> each time specifying a different subnet.  See example below.
>
> Dan
>
>
> nicira@com-dev:~/devstack$ quantum subnet-list -c id -c network_id -c cidr
>
> +-+--+--+
> | cidr| id   | network_id
>  |
>
> +-+--+--+
> | 10.0.0.0/16 | a26f5605-8400-45ef-82cc-ec62fae37a33 |
> 9f930f56-ca54-41b9-bb68-688f009e2f75 |
> | 20.0.0.0/24 | f1278823-d6e3-4237-ad55-7f2fe286994c |
> 9f930f56-ca54-41b9-bb68-688f009e2f75 |
>
> +-+--+--+
> nicira@com-dev:~/devstack$ quantum port-create --fixed-ip
> subnet_id=a26f5605-8400-45ef-82cc-ec62fae37a33 --fixed-ip
> subnet_id=f1278823-d6e3-4237-ad55-7f2fe286994c
> 9f930f56-ca54-41b9-bb68-688f009e2f75
> Created a new port:
>
> ++-+
> | Field  | Value
> |
>
> ++-+
> | admin_state_up | True
> |
> | device_id  |
> |
> | device_owner   |
> |
> | fixed_ips  | {"subnet_id":
> "a26f5605-8400-45ef-82cc-ec62fae37a33", "ip_address": "10.0.0.3"} |
> || {"subnet_id":
> "f1278823-d6e3-4237-ad55-7f2fe286994c", "ip_address": "20.0.0.3"} |
> | id | 79f20e6f-7b95-44b0-90e6-bd0296c7aa54
> |
> | mac_address| fa:16:3e:05:69:ba
> |
> | name   |
> |
> | network_id | 9f930f56-ca54-41b9-bb68-688f009e2f75
> |
> | status | ACTIVE
> |
> | tenant_id  | b02686b6c8c44c75bd7459710ed81edb
> |
>
> ++-+
> nicira@com-dev:~/devstack$ nova image-list
>
> +--+-+++
> | ID   | Name
>   | Status | Server |
>
> +--+-+++
> | 5809a3fe-2c27-4d87-80c0-963ec1f92d0f | cirros-0.3.0-x86_64-uec
>   | ACTIVE ||
> | e9a03bac-1e46-4d98-973d-2efc0f10d4d2 |
> cirros-0.3.0-x86_64-uec-kernel  | ACTIVE ||
> | 28ad71a6-b120-4d75-a8cc-1aabe248edfa |
> cirros-0.3.0-x86_64-uec-ramdisk | ACTIVE ||
>
> +--+-+++
> nicira@com-dev:~/devstack$ nova boot --image
> 5809a3fe-2c27-4d87-80c0-963ec1f92d0f --flavor 1 --nic
> port-id=79f20e6f-7b95-44b0-90e6-bd0296c7aa54 vm1
> ++--+
> | Property   | Value|
> ++--+
> | OS-DCF:diskConfig  | MANUAL   |
> | OS-EXT-STS:power_state | 0|
> | OS-EXT-STS:task_state  | scheduling   |
> | OS-EXT-STS:vm_state| building |
> | accessIPv4 |  |
> | accessIPv6

Re: [Openstack] QEMU Error

2012-10-23 Thread Aaron Rosen

Can you show the qemu-kvm command you are running?


On Tue, Oct 23, 2012 at 8:48 AM, AK Sathiya  wrote:
> Thanks Aaron, i have only qemu-kvm not kvm. The issue was the image type is
> qcow2. When I changed it to the following I got pass that issue.
>
> qemu-image create -f qcow2 $IMAGE 5 G
>
> Howerve, I am not getting ISOLINUX 4.02 2010-07-21 ETCD Copyright (C)
> 1994-2010 H. Peter Anvin et alÿ.
>
> I have tried to boot with the same ISO on a different VM and it worked
> fined.
>
> Not sure why. any ideas.
>
> AK
>
>
>> Date: Mon, 22 Oct 2012 11:09:19 -0700
>> Subject: Re: [Openstack] QEMU Error
>> From: aro...@nicira.com
>> To: ak_m...@hotmail.com
>> CC: openstack@lists.launchpad.net
>
>>
>> The following should do the trick for you in order to create a new
>> disk and boot an iso using it :
>>
>> IMAGE=centos-6.2.img
>> qemu-img create -f raw $IMAGE 5G
>> sudo kvm -hda $IMAGE -m 512 -smp 2 -cdrom centos_installer.iso -boot c
>>
>> Aaron
>>
>> On Mon, Oct 22, 2012 at 8:36 AM, AK Sathiya  wrote:
>> > All, i am a newbi to the openstack. I am trying to create a QCOW2 image
>> > from
>> > a Centos Linux installation iso and ran into the a road block. This is
>> > what
>> > I did so far (just followed the admin manual for Openstack).
>> >
>> > IMAGE=centos-6.2.img
>> > $ qemu-img create -f raw $IMAGE 5G
>> >
>> > VNCDISPLAY=:2
>> > $ MONITOR=/tmp/file.mon
>> > $ sudo /usr/libexec/qemu-kvm -m 1024 -drive
>> > file=${IMAGE},if=virtio,index=0
>> > \
>> > -boot c -net nic -net user -nographic -vnc ${VNCDISPLAY} \
>> > -monitor unix:${MONITOR},server,nowait
>> >
>> > I have the distribution iso on the local directory of the user.
>> >
>> > I got the following error. what am i missing here?
>> >
>> > qemu-kvm: -drive file=centos-6.2.img,if=virtio,index=0: could not open
>> > disk
>> > image centos-6.2.img:Operation not supported
>> >
>> > Any help is appreciated.
>> >
>> > AK
>> >
>> >
>> >
>> > ___
>> > Mailing list: https://launchpad.net/~openstack
>> > Post to : openstack@lists.launchpad.net
>> > Unsubscribe : https://launchpad.net/~openstack
>> > More help : https://help.launchpad.net/ListHelp
>> >

___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] [Quantum] Security Group question

2012-10-22 Thread Aaron Rosen

Hi Liem,

Nachi, is working on the security groups implementation for the
OVSPlugin which I believe will be using iptables. (@Nachi, correct me
if I'm wrong here.)

Thanks,

Aaron

On Mon, Oct 22, 2012 at 11:16 AM, Nguyen, Liem Manh
 wrote:
> Hi fellow stackers,
>
>
>
> I see a blueprint for security groups that is making great progress
> (thanks!)…  Would this blueprint encompass security group for the OVSPlugin?
> Also, would it be using iptables or flow for this?
>
>
>
> Thanks,
>
> Liem
>
>
> ___
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>

___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] QEMU Error

2012-10-22 Thread Aaron Rosen

The following should do the trick for you in order to create a new
disk and boot an iso using it :

IMAGE=centos-6.2.img
qemu-img create -f raw $IMAGE 5G
sudo kvm -hda $IMAGE -m 512 -smp 2  -cdrom centos_installer.iso -boot c

Aaron

On Mon, Oct 22, 2012 at 8:36 AM, AK Sathiya  wrote:
> All, i am a newbi to the openstack. I am trying to create a QCOW2 image from
> a Centos Linux installation iso and ran into the a road block. This is what
> I did so far (just followed the admin manual for Openstack).
>
> IMAGE=centos-6.2.img
> $ qemu-img create -f raw $IMAGE 5G
>
>  VNCDISPLAY=:2
> $ MONITOR=/tmp/file.mon
> $ sudo  /usr/libexec/qemu-kvm -m 1024 -drive file=${IMAGE},if=virtio,index=0
> \
> -boot c -net nic -net user -nographic -vnc ${VNCDISPLAY} \
> -monitor unix:${MONITOR},server,nowait
>
> I have the distribution iso on the local directory of the user.
>
> I got the following error. what am i missing here?
>
> qemu-kvm: -drive file=centos-6.2.img,if=virtio,index=0: could not open disk
> image centos-6.2.img:Operation not supported
>
> Any help is appreciated.
>
> AK
>
>
>
> ___
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>

___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] ERROR in ‘/var/log/quantum/agent-dhcp.log’ for FOLSOM-3

2012-09-18 Thread Aaron Rosen

Hi  Balaji,

This issue seems to have been solved for Srikanth here:
https://answers.launchpad.net/quantum/+question/208446

Thanks,

Aaron


On Tue, Sep 18, 2012 at 1:53 AM, Srikanth Kumar Lingala <
srikanthkumar.ling...@gmail.com> wrote:

> Hi Dan,
> Yes, we have mentioned valid rabbit_host, rabbit_userid and
> rabbit_password fields in quantum.conf.
> And also, we gave the same fields in ovs_quantum_plugin.ini also.
> But, we are getting the same errors in agent-dhcp.log
>
> Srikanth.
>
>
> On Mon, Sep 17, 2012 at 9:56 PM, Dan Wendlandt  wrote:
>
>> Does the quantum.conf on the host that the dhcp agent is running on
>> point to a valid rabbit_host and have a valid user/password for that
>> rabbit host?
>>
>> Dan
>>
>>
>> On Mon, Sep 17, 2012 at 4:29 AM, balaji patnala 
>> wrote:
>> > Hi,
>> >
>> > I'm using Folsom Testing Packages on Ubuntu 12.04.,  Quantum V2 with OVS
>> > Plugin & Agent running.
>> >
>> >
>> >
>> > I am getting the following error for every 30 secs in
>> > ‘/var/log/quantum/agent-dhcp.log’ in the Openstack Controller:
>> >
>> >
>> >
>> > 2012-09-17 12:25:12ERROR [quantum.agent.dhcp_agent] Unable to sync
>> > network state.
>> >
>> > Traceback (most recent call last):
>> >
>> >   File "/usr/lib/python2.7/dist-packages/quantum/agent/dhcp_agent.py",
>> line
>> > 112, in sync_state
>> >
>> > active_networks = set(self.plugin_rpc.get_active_networks())
>> >
>> >   File "/usr/lib/python2.7/dist-packages/quantum/agent/dhcp_agent.py",
>> line
>> > 260, in get_active_networks
>> >
>> > topic=self.topic)
>> >
>> >   File
>> >
>> "/usr/lib/python2.7/dist-packages/quantum/openstack/common/rpc/proxy.py",
>> > line 80, in call
>> >
>> > return rpc.call(context, self._get_topic(topic), msg, timeout)
>> >
>> >   File
>> >
>> "/usr/lib/python2.7/dist-packages/quantum/openstack/common/rpc/__init__.py",
>> > line 102, in call
>> >
>> > return _get_impl().call(cfg.CONF, context, topic, msg, timeout)
>> >
>> >   File
>> >
>> "/usr/lib/python2.7/dist-packages/quantum/openstack/common/rpc/impl_kombu.py",
>> > line 712, in call
>> >
>> > rpc_amqp.get_connection_pool(conf, Connection))
>> >
>> >   File
>> > "/usr/lib/python2.7/dist-packages/quantum/openstack/common/rpc/amqp.py",
>> > line 368, in call
>> >
>> > rv = list(rv)
>> >
>> >   File
>> > "/usr/lib/python2.7/dist-packages/quantum/openstack/common/rpc/amqp.py",
>> > line 329, in __iter__
>> >
>> > self.done()
>> >
>> >   File "/usr/lib/python2.7/contextlib.py", line 24, in __exit__
>> >
>> > self.gen.next()
>> >
>> >   File
>> > "/usr/lib/python2.7/dist-packages/quantum/openstack/common/rpc/amqp.py",
>> > line 326, in __iter__
>> >
>> > self._iterator.next()
>> >
>> >   File
>> >
>> "/usr/lib/python2.7/dist-packages/quantum/openstack/common/rpc/impl_kombu.py",
>> > line 595, in iterconsume
>> >
>> > yield self.ensure(_error_callback, _consume)
>> >
>> >   File
>> >
>> "/usr/lib/python2.7/dist-packages/quantum/openstack/common/rpc/impl_kombu.py",
>> > line 526, in ensure
>> >
>> > error_callback(e)
>> >
>> >   File
>> >
>> "/usr/lib/python2.7/dist-packages/quantum/openstack/common/rpc/impl_kombu.py",
>> > line 576, in _error_callback
>> >
>> > raise rpc_common.Timeout()
>> >
>> > Timeout: Timeout while waiting on RPC response.
>> >
>> >
>> >
>> > Can anybody help me on this
>>
>>
>>
>> --
>> ~~~
>> Dan Wendlandt
>> Nicira, Inc: www.nicira.com
>> twitter: danwendlandt
>> ~~~
>>
>> ___
>> Mailing list: https://launchpad.net/~openstack
>> Post to : openstack@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~openstack
>> More help   : https://help.launchpad.net/ListHelp
>>
>
>
> ___
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>
>
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] quantum-openvswitch-agent needs a restart to bind the vlan-ID

2012-08-30 Thread Aaron Rosen

Hi Joy,

I did noticed a bug in ovs_lib.py but it would cause q-agt to crash. Did
the agent crash?

Aaron

On Thu, Aug 30, 2012 at 2:48 PM, Naveen Joy (najoy)  wrote:

>  Hi All,
>
> ** **
>
> I am running the latest quantum code base. I am seeing an issue in which
> the openvswitch agent is not automatically assigning the vlans to the tap
> interfaces of my new instances. If I restart the agent, it fixes the
> problem. Has anyone seen this issue?.
>
> ** **
>
> #quantum port-list
>
> | True   |
> b74ebe64-4a25-462b-b022-e1c6c42b7e9e
> | compute:N| {"subnet_id": "a44f49dd-cc71-4da6-998c-f0842687d4b0",
> "ip_address": "192.168.119.86"} | 7e6e1373-5ddd-410c-807f-cdf50893be55 |
> fa:16:3e:82:ba:43 || acab3c27-2a5d-4a62-8dbe-e7f856f83978 |
> ACTIVE | 244be8af89624b1e94c0136d5d557a9d |
>
> ** **
>
> #sudo ovs-vsctl list port
>
> _uuid   : 2eec7692-4e1b-40a8-a428-ee8956516406
>
> bond_downdelay  : 0
>
> bond_fake_iface : false
>
> bond_mode   : []
>
> bond_updelay: 0
>
> external_ids: {}
>
> fake_bridge : false
>
> interfaces  : [8dfee46d-e752-4c84-a738-5a63cf4c9c09]
>
> lacp: []
>
> mac : []
>
> name: "tap7e6e1373-5d"
>
> other_config: {}
>
> qos : []
>
> statistics  : {}
>
> status  : {}
>
> tag : []
>
> trunks  : []
>
> vlan_mode   : []
>
> ** **
>
> #sudo restart quantum-openvswitch-agent
>
> #sudo ovs-vsctl list port
>
> _uuid   : 2eec7692-4e1b-40a8-a428-ee8956516406
>
> bond_downdelay  : 0
>
> bond_fake_iface : false
>
> bond_mode   : []
>
> bond_updelay: 0
>
> external_ids: {}
>
> fake_bridge : false
>
> interfaces  : [8dfee46d-e752-4c84-a738-5a63cf4c9c09]
>
> lacp: []
>
> mac : []
>
> name: "tap7e6e1373-5d"
>
> other_config: {}
>
> qos : []
>
> statistics  : {}
>
> status  : {}
>
> tag : 622
>
> trunks  : []
>
> vlan_mode   : []
>
> ** **
>
> Thanks,
>
> Naveen
>
> ** **
>
> ___
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>
>
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] Upgrading from devstack pre-F3/quantum v1/OVS to latest not going well :-(

2012-08-28 Thread Aaron Rosen

Hi Syd,

Unfortunately, I don't believe there are any tools to upgrade the
ovs_quantum db to it's current format. That said, I don't believe it would
be that hard to write one to migrate your setup.

If you read though this page http://wiki.openstack.org/RunningQuantumV2Api it
gives an example of creating a network and boot vms on it. I'm
not familiar with horizon (maybe someone else who is can help you out).

One last thing. Are you running the latest devstack code? The v1 api code
has been removed from quantum so you can remove the following line from
rclocal NOVA_USE_QUANTUM_API=v2

I'd also suggest also removing this line since devstack can now configure
quantum to use keystone by default.

Q_AUTH_STRATEGY=noauth

Best,

Aaron

On Wed, Aug 29, 2012 at 12:53 AM, Syd (Sydney) Logan wrote:

>  I played around with horizon a bit more and discovered that the “demo”
> project page does have a Create Instance button, but when I try and do so I
> get an error message saying that horizon is unable to get quota
> information. I tracked down a bug that was filed 5 days ago on someone
> seeing the same message, and it was punted over to nova after the horizon
> guys concluded that it was a nova bug.
>
> ** **
>
> I’m going to see if I can work around this problem in horizon (or
> rootcause it) tomorrow only because I have no other obvious course of
> action at the moment.
>
> ** **
>
> Here is my localrc, the same as what was working well before I grabbed
> latest devstack (and it grabbed the latest git versions of the openstack
> apps):
>
> ** **
>
> HOST_IP=192.168.4.1
>
> FLAT_INTERFACE=eth1
>
> FIXED_RANGE=10.4.128.0/20
>
> FIXED_NETWORK_SIZE=4096
>
> FLOATING_RANGE=192.168.4.128/25
>
> MULTI_HOST=True
>
> Q_INTERFACE=eth1
>
> LOGFILE=/opt/stack/logs/stack.sh.log
>
> ADMIN_PASSWORD=password
>
> MYSQL_PASSWORD=password
>
> RABBIT_PASSWORD=password
>
> SERVICE_PASSWORD=password
>
> SERVICE_TOKEN=xyzpdqlazydog
>
> LIBVIRT_FIREWALL_DRIVER=nova.virt.firewall.NoopFirewallDriver
>
>
> ENABLED_SERVICES=g-api,g-reg,key,n-api,n-crt,n-obj,n-cpu,cinder,c-sch,c-api,c-vol,n-sch,n-novnc,n-xvnc,n-cauth,horizon,mysql,rabbit,openstackx,q-svc,quantum,q-agt
> 
>
> Q_PLUGIN=openvswitch
>
> Q_AUTH_STRATEGY=noauth
>
> NOVA_USE_QUANTUM_API=v2
>
> ** **
>
> syd
>
> ** **
>
> *From:* Syd (Sydney) Logan
> *Sent:* Tuesday, August 28, 2012 2:19 PM
> *To:* 'openstack@lists.launchpad.net'
> *Subject:* Upgrading from devstack pre-F3/quantum v1/OVS to latest not
> going well :-(
>
> ** **
>
> Hi,
>
> ** **
>
> Is there a recommended procedure for upgrading nodes that were configured
> pre-Folsom 3 to use quantum V1/OVS that were deployed with devstack? I
> probably should have asked this question before trying, but I went ahead
> and tried. I had a multi-node setup that I was driving with Horizon that
> was working very well. Now I’m just trying to get a single node setup
> working, and not getting far. 
>
> ** **
>
> To get sync’d up with the latest, I did the following:
>
> ** **
>
> $ rm –rf /opt/stack (this is where devstack pulled things to)
>
> $ rm –rf /etc/quantum; rm –rf /etc/nova
>
> ** **
>
> In the devstack localrc:
>
> ** **
>
> Removed n-net from ENABLED_SERVICES
>
> Added q-dhcp to ENABLED_SERVICES (I had this disabled in pre-F3 after
> e-mails with Aaron Rosen when he helped me get going earlier, I’ve tried
> both ways and seems not to make a difference)
>
> Added NOVA_USE_QUANTUM=v2 (but this doesn’t seem to make a difference
> either)
>
> ** **
>
> And I ran devstack.
>
> ** **
>
> I got no errors when I ran devstack.
>
> ** **
>
> When I launched Horizon, some problems are evident. There is no launch
> instance button on the Instances page. Because I don’t yet know the command
> UI enough to spin up and configure VMs, I figured I’d try running the
> devstack exercise.sh script to see what happens. It creates a few VMs, but
> none get an IP address (before I used to get IPs in 10.4.128.0).  It
> reports all tests passed, as well. If I click through in the UI on the VM,
> I see that for networking address it assigns all VMs is the value “Net1”.
> 
>
> ** **
>
> I’ve looked at console logs for the VMs created and see failures trying to
> dhcp (that’s why I naively added q-dhcp back to ENABLED_SERVICES), but as I
> mentioned above, adding q-dhcp didn’t help, and I’m wondering if it was a
> good idea anyway since Aaron steered me away from it before.
>

[Openstack] [Glance] Unable to retrieve request id from context

2012-08-28 Thread Aaron Rosen

Hi,

I'm running devstack and when I boot vms I seem to be running into this
error in glance which I believe is causing  the cirros image to just hang
on "Booting from ROM..."  I was wondering if anyone has run into this
before?  (Logs below)

Thanks,

Aaron


arosen@controller:/opt/stack$ nova image-list
+--+-+++
| ID   | Name|
Status | Server |
+--+-+++
| a1a0f8ea-bdba-4892-8fff-2760442b59be | cirros-0.3.0-x86_64-uec |
ACTIVE ||
| c40709b0-c554-4d1b-9a18-9fc393fc6d35 | cirros-0.3.0-x86_64-uec-kernel  |
ACTIVE ||
| 15d78597-4384-4b1f-894f-d1e9eee4b732 | cirros-0.3.0-x86_64-uec-ramdisk |
ACTIVE ||
+--+-+++



nova boot --image  a1a0f8ea-bdba-4892-8fff-2760442b59be-flavor 1 --nic
net-id=e2908a4c-98cd-4ab5-b61c-131f7ed488e9 teststest


 After booting VM from g-api.


2012-08-28 14:56:27 DEBUG glance.api.middleware.version_negotiation [-]
Determining version of request: HEAD
/v1/images/a1a0f8ea-bdba-4892-8fff-2760442b59be Accept:  from (pid=17874)
process_request
/opt/stack/glance/glance/api/middleware/version_negotiation.py:42
Determining version of request: HEAD
/v1/images/a1a0f8ea-bdba-4892-8fff-2760442b59be Accept:
2012-08-28 14:56:27 DEBUG glance.api.middleware.version_negotiation [-]
Using url versioning from (pid=17874) process_request
/opt/stack/glance/glance/api/middleware/version_negotiation.py:55
Using url versioning
2012-08-28 14:56:27 DEBUG glance.api.middleware.version_negotiation [-]
Matched version: v1 from (pid=17874) process_request
/opt/stack/glance/glance/api/middleware/version_negotiation.py:67
Matched version: v1
2012-08-28 14:56:27 DEBUG glance.api.middleware.version_negotiation [-] new
uri /v1/images/a1a0f8ea-bdba-4892-8fff-2760442b59be from (pid=17874)
process_request
/opt/stack/glance/glance/api/middleware/version_negotiation.py:68
new uri /v1/images/a1a0f8ea-bdba-4892-8fff-2760442b59be
2012-08-28 14:56:27 DEBUG glance.common.client
[29d06659-c2e2-45f4-b9e9-c5e2f787562a edfe191c96d2460fa2c83a204d03893a
0d4d4b373b344f2ba292e9a56d78c2e8] Constructed URL:
http://0.0.0.0:9191/images/a1a0f8ea-bdba-4892-8fff-2760442b59be from
(pid=17874) _construct_url /opt/stack/glance/glance/common/client.py:464
Constructed URL:
http://0.0.0.0:9191/images/a1a0f8ea-bdba-4892-8fff-2760442b59be
2012-08-28 14:56:27 DEBUG glance.registry.client
[29d06659-c2e2-45f4-b9e9-c5e2f787562a edfe191c96d2460fa2c83a204d03893a
0d4d4b373b344f2ba292e9a56d78c2e8] Registry request GET
/images/a1a0f8ea-bdba-4892-8fff-2760442b59be HTTP 200 request id None from
(pid=17874) do_request /opt/stack/glance/glance/registry/client.py:94
Registry request GET /images/a1a0f8ea-bdba-4892-8fff-2760442b59be HTTP 200
request id None
2012-08-28 14:56:27 ERROR glance.api.middleware.context
[29d06659-c2e2-45f4-b9e9-c5e2f787562a edfe191c96d2460fa2c83a204d03893a
0d4d4b373b344f2ba292e9a56d78c2e8] Unable to retrieve request id from context
Unable to retrieve request id from context
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] [Netstack] Openstack Folsom - 3 Installation

2012-08-22 Thread Aaron Rosen

inline

On Thu, Aug 23, 2012 at 1:34 AM, Trinath Somanchi <
trinath.soman...@gmail.com> wrote:

> Hi-
>
> Any inputs for understanding and resolving the issue...
>
>
> Kindly help me in this regard.
>
> --
> Trinath
>
>
> On Wed, Aug 22, 2012 at 4:43 PM, Trinath Somanchi <
> trinath.soman...@gmail.com> wrote:
>
>> Hi All-
>>
>> I'm installing Openstack Components of Folsom-3 milestone from the Tar
>> files available from launchpad.
>>
>> Can any one guide me on the installation of the these components like the
>> Essex component installation and configuration.
>>
>> I'm upto this level of Installation.
>>
>> For instance, Keystone component,
>>
>> I have untar the file and executed the following commands.
>>
>> *Keystone $>* python setup.py build
>> *Keystone $>* python setup.py install.
>>
>> Will these two steps install the respective component and all its
>> necessary components.
>>
> Probably only need sudo python setup.py install

>
>>
> With this type of Install can I use the Openstack components as I use them
>> in the 'apt-get' based Essex installation.
>>
>> Yes, this is just a different method of installation.

> Kindly guide me on this...
>>
>> Thanking you all.
>>
>>
>>
>>
>> --
>> Regards,
>> --
>> Trinath Somanchi,
>> +91 9866 235 130
>>
>>
>
>
> --
> Regards,
> --
> Trinath Somanchi,
> +91 9866 235 130
>
>
> --
> Mailing list: https://launchpad.net/~netstack
> Post to : netst...@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~netstack
> More help   : https://help.launchpad.net/ListHelp
>
>
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] Question about Flat DHCP networking

2012-08-18 Thread Aaron Rosen

Hi Eugene,

This means that if a VM stops it's DHCP client that nova-network will be
aware of this since the VM will not attempt to renew it's DHCP lease.

Aaron

On Fri, Aug 17, 2012 at 5:58 PM, Eugene Kirpichov wrote:

> Hi,
>
> The documentation
>
> http://docs.openstack.org/diablo/openstack-compute/admin/content/configuring-flat-dhcp-networking.html
> has the passage: "The nova-network service will track leases and
> releases in the database so it knows if a VM instance has stopped
> properly configuring via DHCP"
>
> Can someone briefly explain me what this means, if possible with rough
> pointers to code?
> I don't recall nova noticing when my VM actually stopped properly
> configuring via DHCP.
>
> --
> Eugene Kirpichov
> http://www.linkedin.com/in/eugenekirpichov
>
> ___
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] Question about Flat DHCP networking

2012-08-18 Thread Aaron Rosen

Hi Eugene,

I'm not sure I have not looked at the code (I'm guessing that it probably
keeps the lease around since it knows the VM is still active instead of
recycling the ip address). Though this is just a guess. You should look at
the implementation details if you are curious.

Aaron

On Sat, Aug 18, 2012 at 3:48 AM, Eugene Kirpichov wrote:

> Thanks. And how will n-net react?
>
>
>
> 18.08.2012, в 0:43, Aaron Rosen  написал(а):
>
> Hi Eugene,
>
> This means that if a VM stops it's DHCP client that nova-network will be
> aware of this since the VM will not attempt to renew it's DHCP lease.
>
> Aaron
>
> On Fri, Aug 17, 2012 at 5:58 PM, Eugene Kirpichov wrote:
>
>> Hi,
>>
>> The documentation
>>
>> http://docs.openstack.org/diablo/openstack-compute/admin/content/configuring-flat-dhcp-networking.html
>> has the passage: "The nova-network service will track leases and
>> releases in the database so it knows if a VM instance has stopped
>> properly configuring via DHCP"
>>
>> Can someone briefly explain me what this means, if possible with rough
>> pointers to code?
>> I don't recall nova noticing when my VM actually stopped properly
>> configuring via DHCP.
>>
>> --
>> Eugene Kirpichov
>> http://www.linkedin.com/in/eugenekirpichov
>>
>> ___
>> Mailing list: https://launchpad.net/~openstack
>> Post to : openstack@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~openstack
>> More help   : https://help.launchpad.net/ListHelp
>>
>
>
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] 回复：回复： Openstack Folsom 2 or 3

2012-08-17 Thread Aaron Rosen

By far in my opinion the easiest route to take in order to quickly try out
and play with the latest code is www.devstack.org.

Aaron

On Fri, Aug 17, 2012 at 3:17 AM, Salvatore Orlando wrote:

> Hi,
>
> Folsom-3 is going to be released this evening GMT. Expect it to be
> available after 1700 GMT.
> You'll find both a folsom-3 tag on github, as well as tarballs
> downloadable from launchpad.
>
> Regards,
> Salvatore
>
>
> On 17 August 2012 08:50, 延生 付  wrote:
>
>> Seems not release yet. Hold on :)
>>
>>
>> Regards,
>>
>>
>> willfu
>>   *发件人：* Trinath Somanchi 
>> *收件人：* 延生 付 
>> *抄送：* "openstack@lists.launchpad.net" 
>> *发送日期：* 2012年8月17日, 星期五, 下午 2:25
>> *主题:* Re: 回复： [Openstack] Openstack Folsom 2 or 3
>>
>> Hi-
>>
>> Thanks for the reply.
>>
>> How to download the Folsom-3 code base of Openstack... Can you guide me
>> on this...
>>
>> Thanking you...
>>
>> --\
>> Trinath
>>
>>
>> On Fri, Aug 17, 2012 at 11:47 AM, 延生 付  wrote:
>>
>>  Try this one for folsom 2.
>>
>> https://github.com/openstack/nova/tree/folsom-2
>>
>> All the source is under https://github.com/openstack
>>
>> You can choose the required version.
>>
>> Regards,
>>  willfu
>>*发件人：* Trinath Somanchi 
>> *收件人：* openstack@lists.launchpad.net
>> *发送日期：* 2012年8月17日, 星期五, 下午 12:59
>> *主题:* [Openstack] Openstack Folsom 2 or 3
>>
>> Hi-
>>
>> I want to download the Openstack Folsom 2 or 3. Is Version 3 downloadable.
>>
>> My web search is not fruitful with the the link to the download of the
>> release.
>>
>> Please guide me on downloading Openstack Folsom - 3 or 2 source code.
>>
>> thanking you,
>>
>> --
>> Regards,
>> --
>> Trinath Somanchi,
>> +91 9866 235 130
>>
>>
>> ___
>> Mailing list: https://launchpad.net/~openstack
>> Post to: openstack@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~openstack
>> More help  : https://help.launchpad.net/ListHelp
>>
>>
>>
>>
>>
>> --
>> Regards,
>> --
>> Trinath Somanchi,
>> +91 9866 235 130
>>
>>
>>
>>
>> ___
>> Mailing list: https://launchpad.net/~openstack
>> Post to : openstack@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~openstack
>> More help   : https://help.launchpad.net/ListHelp
>>
>>
>
> ___
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>
>
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] Question for Quantum V2 subnet

2012-08-13 Thread Aaron Rosen

The reason for this is because you can have multiple subnets on the same L2
bcast domain. You can use ip aliasing in order to use multiple subnets on
one virtual nic. For example ifconfig eth0:1 a.b.c.d/24; ifconfig eth0:2
d.e.f.g/24

Aaron

On Mon, Aug 13, 2012 at 7:52 PM, Takaaki Suzuki  wrote:

> Hi all.
>
> I have one question. I prepared devstack with Qauntum V2.
> Now I can create Subnet for Network.
> And I can add multiple Subnet for one Network. VM can use multiple
> subnet for one virtual NIC?
> Why quantum v2 can create multiple subnet for one Network?
>
> quantum --os_token 1b73ace152c440ea939c2329fd115e56 --os_url
> http://localhost:9696/ net-list
>
> ++--+---++--+--+
> | admin_state_up | id   | name  |
> status | subnets  | tenant_id
>   |
>
> ++--+---++--+--+
> | True   | d7a8106c-7ca6-4302-a065-6a87c859ed9c | test
> | ACTIVE | 474ea30c-9337-4f48-854c-9f572538a44c |
> 4fb66e3355304be5a6f3340d7067b369 |
> |  |
>||  |
> 52ffda8c-61aa-465b-ae62-1ef57e9bed85 |
> |
> |  |
>||  |
> 9a659285-c6b1-4e6f-b3f0-c3e37341e0be |
>|
>
> quantum --os_token 1b73ace152c440ea939c2329fd115e56 --os_url
> http://localhost:9696/ subnet-list
>
> +--+--+---+--+++--+--+
> | allocation_pools | cidr
>| gateway_ip| id   | ip_version
> | name   | network_id   | tenant_id
> |
>
> +--+--+---+--+++--+--+
> | {"start": "192.168.100.2", "end": "192.168.100.254"} |
> 192.168.100.0/24 | 192.168.100.1 |
> 474ea30c-9337-4f48-854c-9f572538a44c |  4 | test01 |
> d7a8106c-7ca6-4302-a065-6a87c859ed9c |
> 4fb66e3355304be5a6f3340d7067b369 |
> | {"start": "192.168.210.2", "end": "192.168.210.254"} |
> 192.168.210.0/24 | 192.168.210.1 |
> 52ffda8c-61aa-465b-ae62-1ef57e9bed85 |  4 | test03 |
> d7a8106c-7ca6-4302-a065-6a87c859ed9c |
> 4fb66e3355304be5a6f3340d7067b369 |
> | {"start": "192.168.200.2", "end": "192.168.200.254"} |
> 192.168.200.0/24 | 192.168.200.1 |
> 9a659285-c6b1-4e6f-b3f0-c3e37341e0be |  4 | test02 |
> d7a8106c-7ca6-4302-a065-6a87c859ed9c |
> 4fb66e3355304be5a6f3340d7067b369 |
>
> +--+--+---+--+++--+--+
>
> Thanks!
> Suzuki
>
> ___
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] Nova DHCP

2012-08-13 Thread Aaron Rosen

You can definitely disable the dhcp and provide your own means of providing
dhcp. Do you have a specific use case in mind that isn't addressed by
either these two already provided?

Aaron

P.S; the quantum dhcp agent now support for overlapping ip :)

On Mon, Aug 13, 2012 at 2:30 AM, Trinath Somanchi <
trinath.soman...@gmail.com> wrote:

> Hi-
>
> Rather than using Nova DHCP from Essex or Quantum based DHCP in the
> upcoming folsom release, Can we have a configurable option to use custom
> DHCP...
>
> Can any one tried this way or any one can help me how to get in this using
> Openstack Essex and also with Folsom releases.
>
> Thanking you all..
>
>
> --
> Regards,
> --
> Trinath Somanchi,
> +91 9866 235 130
>
>
> ___
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>
>
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] [openstack-dev] [Netstack] [Quantum] Multi-host implementation

2012-08-13 Thread Aaron Rosen

The dhcp agent now is able to use network namespaces so there is no longer
ip conflicts. Perhaps in the future the dhcp agent could implement some
kind of DHCP reply (ip helper) service . Though currently it allocates an
ip address in each subnet that you want dhcp enabled on.

Aaron

On Mon, Aug 13, 2012 at 12:02 AM, Hua ZZ Zhang  wrote:

> hi,
>
> I have a question about the ip address consumed by the dhcp services. is
> it necessary to assign an individual ip for each dhcp daemon? can we
> reserve only one ip address for all dhcp deamons subject to one subnet
> since they won't run on the same host?  since the dhcp service only need to
> communicate with local VM instances and local dhcp agent (don't know if it
> is true for this assumption), can we find a kind of isolation mechanism to
> avoid ip conflicts and extra consume of ip addresses to implement this
> feature?
>
> *Best Regards, *
>
> --
>
>*Edward Zhang(张华)*
>Staff Software Engineer
>Travel&Transportation Standards
>Emerging Technology Institute(ETI)
>IBM China Software Development Lab
>e-mail: zhu...@cn.ibm.com
>Notes ID: Hua ZZ Zhang/China/IBM
>Tel: 86-10-82450483
>
>
>地址:北京市海淀区东北旺西路8号 中关村软件园28号楼 环宇大厦3层 邮编：100193
>Address: 3F Ring, Building 28 Zhongguancun Software Park, 8
>Dongbeiwang West Road, Haidian District, Beijing, P.R.C.100193
>
>
>
>
>
>
>
> [image: Inactive hide details for MURAOKA Yusuke ---2012-08-09
> 00:21:52---Hi,]MURAOKA Yusuke ---2012-08-09 00:21:52---Hi,
>
>
>*MURAOKA Yusuke *
>Sent by: openstack-bounces+zhuadl=cn.ibm@lists.launchpad.net
>
>2012-08-09 00:19
>
>
> To
>
>
>Dan Wendlandt 
>
>
> cc
>
>
>OpenStack Development Mailing List ,
>netst...@lists.launchpad.net, openstack@lists.launchpad.net
>
>
> Subject
>
>
>Re: [Openstack] [Netstack] [openstack-dev] [Quantum] Multi-host
>implementation
>
>
> Hi,
>
> I've updated the bp to correspond with current design spec.
> > https://blueprints.launchpad.net/quantum/+spec/quantum-multihost-dhcp
>
>
> I'd know the case of failure, improper, insane, by that.
> Anyway, comments, discussions are welcome.
>
> Thanks.
>
> --
> MURAOKA Yusuke
>
> Mail: yus...@jbking.org
>
>
> 日付：2012年8月7日火曜日、�r刻：2:47、差出人：Nachi Ueno：
>
> > Hi Dan
> >
> > Thank you for pointing this.
> >
> > Yusuke updated design spec.
> > https://blueprints.launchpad.net/quantum/+spec/quantum-multihost-dhcp
> >
> > 2012/8/6 Dan Wendlandt  > (mailto:d...@nicira.com
> )>:
> > > Hi Nachi,
> > >
> > > I've reviewed the code and added comments. I'd like to see at least a
> basic
> > > spec describing the proposed approach (need only be a couple
> paragraphs,
> > > perhaps with a diagram) linked to the blueprint so we can have a design
> > > discussion around it. Thanks,
> > >
> > > Dan
> > >
> > >
> > > On Fri, Aug 3, 2012 at 1:03 PM, Nachi Ueno  mailto:na...@nttmcl.com )> wrote:
> > > >
> > > > Hi folks
> > > >
> > > > Sorry.
> > > > I added openstack-...@lists.openstack.org (
> mailto:openstack-...@lists.openstack.org)
> in this discussion.
> > > >
> > > > 2012/8/3 Nati Ueno  > > > (mailto:nati.u...@gmail.com
> )>:
> > > > > Hi folks
> > > > >
> > > > > > Gary
> > > > > Thank you for your comment. I wanna discuss your point on the
> mailing
> > > > > list.
> > > > >
> > > > > Yusuke pushed Multi-host implementation for review.
> > > > > https://review.openstack.org/#/c/10766/2
> > > > > This patch changes only quantum-dhcp-agent side.
> > > > >
> > > > > Gary's point is we should have host attribute on the port for
> > > > > scheduling.
> > > > > I agree with Gary.
> > > > >
> > > > > In the nova, vm has available_zone for scheduling.
> > > > > So Instead of using host properties.
> > > > > How about use available_zone for port?
> > > > >
> > > > > Format of availability_zone is something like this
> > > > > available_zone="zone_name:host".
> > > > >
> > > > > We can also add availability_zone attribute for the network as a
> > > > > default value of port.
> > > > > We can write this until next Monday.
> > > > > However I'm not sure quantum community will accept this or not, so
> I'm
> > > > > asking here.
> > > > >
> > > > > If there are no objections, we will push zone version for review.
> > > > > Thanks
> > > > > Nachi
> > > > >
> > > > > ___
> > > > > Mailing list: https://launchpad.net/~openstack
> > > > > Post to : openstack@lists.launchpad.net (
> mailto:openstack@lists.launchpad.net )
> > > > > Unsubscribe : https://launchpad.net/~openstack
> > > > > More help : https://help.launchpad.net/ListHelp
> > > >
> > > >
> > > >
> > > > ___
> > > > OpenStack-dev mailing list
> > > > openstack-...@lists.openstack.org (
> mailto:openstack-...@lists.openstack.org
> )
> > > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> > >
> > >
> > >
> > >
> > >
> > >
> > > --
> > > ~~~
> > > Dan Wendla

Re: [Openstack] Quantum devstack authentication error

2012-08-07 Thread Aaron Rosen

Hi Salvatore,

Gabriel ran into this issue because devstack currently defaults to use
quantum v1. I added Q_AUTH_STRATEGY=noauth to the current v1 devstack page.
I'll go ahead and add a link to the v2 page on the v1 page and then fully
update the page once v2 is the default in devstack.

Aaron


On Tue, Aug 7, 2012 at 2:32 PM, Salvatore Orlando wrote:

> Aaron,
>
> it would be great if you can update the wiki page for running Quantum with
> devstack with the info in http://wiki.openstack.org/RunningQuantumV2Api that
> you created.
> I also had other people asking me about how to run devstack with Quantum
> v2, and I pointed them to your page.
>
> On the issue Gabriel was referring to, I have to say that now devstack
> fully supports Quantum v2 with Keystone, so there's no need for running it
> in noauth mode.
> From the published traceback, it seem n-net is still enabled in devstack.
> It should be instead removed from ENABLED_SERVICES if running quantum v2.
>
> Regards,
> Salvatore
>
>
> On 7 August 2012 23:15, Aaron Rosen  wrote:
>
>> Inline
>>
>> On Tue, Aug 7, 2012 at 2:05 PM, Gabriel Hurley > > wrote:
>>
>>>  Thanks, that got it. Two things, though:
>>>
>>> ** **
>>>
>>> **1.   **Shouldn’t that be in the wiki?
>>>
>>  I'll add it. This change was recently introduce to devstack.
>>
>>> 
>>>
>>> **2.   **What do you mean “only works in folsom”? I’m running the
>>> latest devstack with master everything… how much more “folsom” does it get?
>>> 
>>>
>>> **
>>>
>> If you do add  NOVA_USE_QUANTUM_API=v2 to localrc it uses the quantum v2
>> api. http://wiki.openstack.org/RunningQuantumV2Api
>>
>>
>>> **
>>>
>>> **-  **Gabriel
>>>
>>
>> Aaron
>>
>>> 
>>>
>>> ** **
>>>
>>> *From:* Aaron Rosen [mailto:aro...@nicira.com]
>>> *Sent:* Tuesday, August 07, 2012 1:33 PM
>>> *To:* Gabriel Hurley
>>> *Cc:* openstack@lists.launchpad.net
>>> *Subject:* Re: [Openstack] Quantum devstack authentication error
>>>
>>> ** **
>>>
>>> Hi Gabriel, 
>>>
>>> ** **
>>>
>>> Adding Q_AUTH_STRATEGY=noauth to localrc should fix the issue. 
>>>
>>> ** **
>>>
>>> The authentication it's trying to use only works in folsom. 
>>>
>>> ** **
>>>
>>> Thanks, 
>>>
>>> ** **
>>>
>>> Aaron
>>>
>>> On Tue, Aug 7, 2012 at 1:04 PM, Gabriel Hurley <
>>> gabriel.hur...@nebula.com> wrote:
>>>
>>> I'm trying to run devstack with quantum enabled so I can test the recent
>>> work on re-integrating Quantum into Horizon.
>>>
>>> I've followed the instructions for what should be in my localrc file
>>> here: http://wiki.openstack.org/QuantumDevstack
>>>
>>> However, devstack fails when trying to create a network during its
>>> health checks. The error logged is here: https://gist.github.com/3288861
>>>
>>> Any advice? What's missing from that wiki page? Or is this a bug?
>>>
>>> Thanks,
>>>
>>> - Gabriel
>>>
>>>
>>> ___
>>> Mailing list: https://launchpad.net/~openstack
>>> Post to : openstack@lists.launchpad.net
>>> Unsubscribe : https://launchpad.net/~openstack
>>> More help   : https://help.launchpad.net/ListHelp
>>>
>>> ** **
>>>
>>
>>
>> ___
>> Mailing list: https://launchpad.net/~openstack
>> Post to : openstack@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~openstack
>> More help   : https://help.launchpad.net/ListHelp
>>
>>
>
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] Quantum devstack authentication error

2012-08-07 Thread Aaron Rosen

Inline

On Tue, Aug 7, 2012 at 2:05 PM, Gabriel Hurley wrote:

>  Thanks, that got it. Two things, though:
>
> ** **
>
> **1.   **Shouldn’t that be in the wiki?
>
 I'll add it. This change was recently introduce to devstack.

> 
>
> **2.   **What do you mean “only works in folsom”? I’m running the
> latest devstack with master everything… how much more “folsom” does it get?
> 
>
> **
>
If you do add  NOVA_USE_QUANTUM_API=v2 to localrc it uses the quantum v2
api. http://wiki.openstack.org/RunningQuantumV2Api


> **
>
> **-      **Gabriel
>

Aaron

> 
>
> ** **
>
> *From:* Aaron Rosen [mailto:aro...@nicira.com]
> *Sent:* Tuesday, August 07, 2012 1:33 PM
> *To:* Gabriel Hurley
> *Cc:* openstack@lists.launchpad.net
> *Subject:* Re: [Openstack] Quantum devstack authentication error
>
> ** **
>
> Hi Gabriel, 
>
> ** **
>
> Adding Q_AUTH_STRATEGY=noauth to localrc should fix the issue. 
>
> ** **
>
> The authentication it's trying to use only works in folsom. 
>
> ** **
>
> Thanks, 
>
> ** **
>
> Aaron
>
> On Tue, Aug 7, 2012 at 1:04 PM, Gabriel Hurley 
> wrote:
>
> I'm trying to run devstack with quantum enabled so I can test the recent
> work on re-integrating Quantum into Horizon.
>
> I've followed the instructions for what should be in my localrc file here:
> http://wiki.openstack.org/QuantumDevstack
>
> However, devstack fails when trying to create a network during its health
> checks. The error logged is here: https://gist.github.com/3288861
>
> Any advice? What's missing from that wiki page? Or is this a bug?
>
> Thanks,
>
> - Gabriel
>
>
> ___
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>
> ** **
>
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] Quantum devstack authentication error

2012-08-07 Thread Aaron Rosen

Hi Gabriel,

Adding Q_AUTH_STRATEGY=noauth to localrc should fix the issue.

The authentication it's trying to use only works in folsom.

Thanks,

Aaron

On Tue, Aug 7, 2012 at 1:04 PM, Gabriel Hurley wrote:

> I'm trying to run devstack with quantum enabled so I can test the recent
> work on re-integrating Quantum into Horizon.
>
> I've followed the instructions for what should be in my localrc file here:
> http://wiki.openstack.org/QuantumDevstack
>
> However, devstack fails when trying to create a network during its health
> checks. The error logged is here: https://gist.github.com/3288861
>
> Any advice? What's missing from that wiki page? Or is this a bug?
>
> Thanks,
>
> - Gabriel
>
>
> ___
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] Configuring with devstack for multiple hardware nodes

2012-08-06 Thread Aaron Rosen

Hi Syd,

There should not be an additional gateway interface on the compute nodes,
only the node that has n-net in ENABLED_SERVICES. I'm assuming you want to
use the OVSQuantumPlugin? Can you also
attach /etc/quantum/plugins/openvswitch/ovs_quantum_plugin.ini from your
two nodes?  Also if you are interested in trying out the folsom quantum
code the following link should help you get running:
http://wiki.openstack.org/RunningQuantumV2Api

Aaron


On Mon, Aug 6, 2012 at 4:30 PM, Syd (Sydney) Logan wrote:

>  Hi,
>
> ** **
>
> I just posted the following at
> http://forums.openstack.org/viewtopic.php?f=15&t=1435, then realized this
> mailing list might be a better place to ask the question.
>
> ** **
>
> In summary, I’ve cobbled together devstack-based nodes to exercise
> quantum/openvswitch (when I say cobbled, I mean my result is the
> combination of information from wiki and from devstack, and elsewhere to
> create my localrc files, since there is no one definitive template that I
> could use, and it seems that devstack examples are not current with what is
> happening on Folsom). One node is a controller, one is a compute node. I
> can launch using horizon on the controller, VMs launched on the controller
> are pingable, but ones launched on the compute node are not. The big
> difference I can see is a missing gateway interface on the controller (on
> gw-* displayed when I run ifconfig). By inspection of the logs, I can see
> that the VMs are unable to establish a network, and I think the missing
> gateway interface may be the root cause for that. 
>
> ** **
>
> Below are details:
>
> ** **
>
> Two hosts, one configured as a controller, the other configured as a
> compute node.
>
> Each host is dual homed, network for eth0 is connected to the local
> intranet, network for eth1 is configured as a local net 192.168.3.0
>
> On the controller host, I used devstack with the following localrc (which
> is an aggregation of stuff I found on the devstack site, and stuff I found
> recently on the quantum wiki -- it would be nice if complete templates for
> a controller and compute node supporting devstack and openvswitch were
> published on the devstack site or the wiki, perhaps since we are not yet at
> Folsom it makes sense they don't exist, if I get something working, I will
> share my configuration in the entirety at whatever is the most appropriate
> place). Anyway, controller host localrc is:
>
> ** **
>
> HOST_IP=192.168.3.1
>
> FLAT_INTERFACE=eth1
>
> FIXED_RANGE=10.4.128.0/20
>
> FIXED_NETWORK_SIZE=4096
>
> FLOATING_RANGE=192.168.3.128/25
>
> MULTI_HOST=True
>
> LOGFILE=/opt/stack/logs/stack.sh.log
>
> ADMIN_PASSWORD=password
>
> MYSQL_PASSWORD=password
>
> RABBIT_PASSWORD=password
>
> SERVICE_PASSWORD=password
>
> SERVICE_TOKEN=xyzpdqlazydog
>
>
> ENABLED_SERVICES=g-api,g-reg,key,n-api,n-cpu,n-net,n-sch,n-vnc,horizon,mysql,rabbit,openstackx,q-svc,quantum,q-agt,q-dhcp
> 
>
> Q_PLUGIN=openvswitch
>
> Q_AUTH_STRATEGY=noauth
>
> ** **
>
> If I run stack on this host, I get the following nova.conf:
>
> ** **
>
> [DEFAULT]
>
> verbose=True
>
> auth_strategy=keystone
>
> allow_resize_to_same_host=True
>
> root_helper=sudo /usr/local/bin/nova-rootwrap /etc/nova/rootwrap.conf
>
> compute_scheduler_driver=nova.scheduler.filter_scheduler.FilterScheduler**
> **
>
> dhcpbridge_flagfile=/etc/nova/nova.conf
>
> fixed_range=10.4.128.0/20
>
> s3_host=192.168.3.1
>
> s3_port=
>
> network_manager=nova.network.quantum.manager.QuantumManager
>
> quantum_connection_host=localhost
>
> quantum_connection_port=9696
>
> quantum_use_dhcp=True
>
> libvirt_vif_type=ethernet
>
> libvirt_vif_driver=nova.virt.libvirt.vif.LibvirtOpenVswitchDriver
>
> linuxnet_interface_driver=nova.network.linux_net.LinuxOVSInterfaceDriver**
> **
>
>
> osapi_compute_extension=nova.api.openstack.compute.contrib.standard_extensions
> 
>
> my_ip=192.168.3.1
>
> public_interface=br100
>
> vlan_interface=eth0
>
> flat_network_bridge=br100
>
> flat_interface=eth1
>
> sql_connection=mysql://root:password@localhost/nova?charset=utf8
>
> libvirt_type=kvm
>
> libvirt_cpu_mode=none
>
> instance_name_template=instance-%08x
>
> novncproxy_base_url=http://192.168.3.1:6080/vnc_auto.html
>
> xvpvncproxy_base_url=http://192.168.3.1:6081/console
>
> vncserver_listen=127.0.0.1
>
> vncserver_proxyclient_address=127.0.0.1
>
> api_paste_config=/etc/nova/api-paste.ini
>
> image_service=nova.image.glance.GlanceImageService
>
> ec2_dmz_host=192.168.3.1
>
> rabbit_host=localhost
>
> rabbit_password=password
>
> glance_api_servers=192.168.3.1:9292
>
> force_dhcp_release=True
>
> multi_host=True
>
> send_arp_for_ha=True
>
> logging_context_format_string=%(asctime)s %(color)s%(levelname)s %(name)s
> [^[[01;36m%(request_id)s ^[[00;36m%(user_

1 2 >

1 - 100 of 103 matches

Mail list logo