Hi Wilson, Can you clarify a couple of things here?
- Does each tenant have their own router in front of their respective instance? - have you confirmed connectivity to the admin instance from the router namespace? - can you verify the dnat/snat entries for the admin instance exist in iptables in the router namespace? - have you verified the instance got its fixed up from dhcp? - have you tried consoling to the instance and verifying outbound connectivity? If you can, start with some simple connectivity verifications with the namespaces and work your way out from there. Also, your screenshots didn't come through, so if you can post the Cli output somewhere that would be helpful. James Sent from my iPhone On Jun 4, 2015, at 10:18 PM, Wilson Kwok <leiw...@gmail.com<mailto:leiw...@gmail.com>> wrote: Any one can help? 於 2015/5/29 上午10:39，"Wilson Kwok" <leiw...@gmail.com<mailto:leiw...@gmail.com>> 寫道： Ok 於 2015/5/28 下午6:24，"Remo Mattei" <r...@italy1.com<mailto:r...@italy1.com>> 寫道： Nope. Inviato da iPhone Il giorno 28/mag/2015, alle ore 02:04, Wilson Kwok <leiw...@gmail.com<mailto:leiw...@gmail.com>> ha scritto: Hello all, Have some see my attached screenshots? Thanks 於 2015/5/27 上午11:14，"Wilson Kwok" <leiw...@gmail.com<mailto:leiw...@gmail.com>> 寫道： Hello all, Please see attached Zip screenshots, you will know what is my problem. Thanks for your help! 2015-05-27 1:15 GMT+08:00 Remo Mattei <r...@italy1.com<mailto:r...@italy1.com>>: Just a quick note, each tenant has it’s own default security group rules. So I would double check and make sure your admin does have those rules set. If it works with Demo it has to work with admin. Remo On May 26, 2015, at 09:03, Wilson Kwok <leiw...@gmail.com<mailto:leiw...@gmail.com>> wrote: Hi Yair, I just tried something: 1. I created Peter account and added into Demo project, I can access Peter's VM from external network PC via floating IP. 2. Admin account router account floating IP is 172.28.0.163, I can ping it, but I can't access Admin's VM floating IP 172.128.0.164 from external network PC (Securty Group allow ICMP and SSH) 3. Demo account with no problem. I created public network with keystone admin, please see below result with neutron net-show public: [root@localhost ~(keystone_admin)]# neutron net-show public +---------------------------+--------------------------------------+ | Field | Value | +---------------------------+--------------------------------------+ | admin_state_up | True | | id | 6145669e-4688-40a6-b878-aaa2f9cb26c6 | | mtu | 0 | | name | public | | provider:network_type | vxlan | | provider:physical_network | | | provider:segmentation_id | 10 | | router:external | True | | shared | True | | status | ACTIVE | | subnets | 65c1896c-0bc6-4b00-b89b-57f2677b3219 | | tenant_id | e67ef147ee074f83bdab0da903f0cdd3 | +---------------------------+--------------------------------------+ and keystone tenant-list command: [root@localhost ~(keystone_admin)]# keystone tenant-list /usr/lib/python2.7/site-packages/keystoneclient/shell.py:65: DeprecationWarning: The keystone CLI is deprecated in favor of python-openstackclient. For a Python library, continue using python-keystoneclient. 'python-keystoneclient.', DeprecationWarning) +----------------------------------+----------+---------+ | id | name | enabled | +----------------------------------+----------+---------+ | e67ef147ee074f83bdab0da903f0cdd3 | admin | True | | 24f9a6c52a1d471a8e7dc0f8fde32ced | demo | True | | 64c18def585e45e39b5e4ec161e18633 | services | True | | 80f0de3f19bf4c699938b54288d1ede8 | test | True | +----------------------------------+----------+---------+ Thanks for your help! 2015-05-26 18:32 GMT+08:00 Yair Fried <yfr...@redhat.com<mailto:yfr...@redhat.com>>: Hi, >From https://bugzilla.redhat.com/show_bug.cgi?id=1163726#c3 <snip> By marking a network as "external" you are actually sharing it among all other tenants to be used as default GW and a source for floating IPs. Marking a network as "shared" is allowing other tenants to connect VMs (and not router GWs) directly to the network. Marking an external network as "shared" would allow VMs of all tenants to connect to a network as well as pull floating ips from it (via router GW). While this is possible in Neutron, it is also redundant, as with the case above - There isn't much sense in pulling a floating IP from a network that you can connect to directly. </snip> please provide the relevant output from: $ neutron net-show <external net> $ keystone tenant-list Without this output it seems like the network was created by non-admin tenant/user which shouldn't allow its floating IPs to be consumed by other tenants. I've never tried to do that, so I'm not sure if this is a legitimate operation and if so, how such network should behave. The ideal flow is: 1. Admin creates an external network (usually called "public") in its own tenant. 2. Users (in their own tenants) create private networks and VMs attached to them. 3. Users create routers connecting their private networks ( router-interface-add") to the external ("public") network ("router-gateway-set"). *** At this point, VMs should be able to access the outside world via NAT. 4. Now users can allocate floating IPs to their VMs (only those VMs that are connected to the external network via routers). Please let me know if this is unclear Regards Yair !DSPAM:1,5566da3a317321526615646! _______________________________________________ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org<mailto:openstack@lists.openstack.org> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
_______________________________________________ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
