Hi, Sergey,
I remember I had similar problem when I switched to quantum(neutron's
previous name) from nova-network.
But, I can't recall how I solved it exactly, it would be something like
previous nova-network NAT caused the problem, so, if you switched to
neutron from nova-network at the same system, you might want to look at
your NAT to see if you still have some NAT setup remaining that came
from nova-network, and (e.g. redirect :80 to 0.0.0.0:8775)
> I guess, metadata service is supposed to listen on 192.168.0.2,
but it's not.
Yes, it's not, if I understand it correctly, it will be redirected to
metadata port in name space, so, you won't see it actually listens on 80
port.
Best regards,
Felix Lee ~
On 2014年06月14日 19:44, Sergey Motovilovets wrote:
This can probably be useful too:
From network node
# ip netns ls
qdhcp-1b982b98-62db-4c87-867b-0490bac8fb52
qrouter-c7e7ea00-a362-4f4f-9a1c-a54ac86eb3be
# ps -x | grep metadata
�1469 ? � � � �S � � �0:00 /usr/bin/python
/usr/bin/neutron-ns-metadata-proxy
--pid_file=/var/lib/neutron/external/pids/6c91714c-c1aa-41d7-88ba-249df3a8368c.pid
--metadata_proxy_socket=/var/lib/neutron/metadata_proxy
--network_id=6c91714c-c1aa-41d7-88ba-249df3a8368c
--state_path=/var/lib/neutron --metadata_port=80
--log-file=neutron-ns-metadata-proxy-6c91714c-c1aa-41d7-88ba-249df3a8368c.log
--log-dir=/var/log/neutron
�5937 ? � � � �S � � �0:00 /usr/bin/python
/usr/bin/neutron-ns-metadata-proxy
--pid_file=/var/lib/neutron/external/pids/fa72c69b-2ca2-4d4d-ab8c-d6fa6e8e72d6.pid
--metadata_proxy_socket=/var/lib/neutron/metadata_proxy
--network_id=fa72c69b-2ca2-4d4d-ab8c-d6fa6e8e72d6
--state_path=/var/lib/neutron --metadata_port=80
--log-file=neutron-ns-metadata-proxy-fa72c69b-2ca2-4d4d-ab8c-d6fa6e8e72d6.log
--log-dir=/var/log/neutron
�8108 ? � � � �S � � �0:00 /usr/bin/python
/usr/bin/neutron-ns-metadata-proxy
--pid_file=/var/lib/neutron/external/pids/c7e7ea00-a362-4f4f-9a1c-a54ac86eb3be.pid
--metadata_proxy_socket=/var/lib/neutron/metadata_proxy
--router_id=c7e7ea00-a362-4f4f-9a1c-a54ac86eb3be
--state_path=/var/lib/neutron --metadata_port=9697
--log-file=neutron-ns-metadata-proxy-c7e7ea00-a362-4f4f-9a1c-a54ac86eb3be.log
--log-dir=/var/log/neutron
2014-06-14 20:38 GMT+03:00 Sergey Motovilovets
<motovilovets.ser...@gmail.com <mailto:motovilovets.ser...@gmail.com>>:
Hi, Mike.
There are no routes in my VM's except for the default one. Private
subnet I'm using is 192.168.0.0/24 <http://192.168.0.0/24> with
neutron router on 192.168.0.1.
# route -n
Kernel IP routing table
Destination � � Gateway � � � � Genmask � � � � Flags Metric Ref �
�Use Iface
0.0.0.0 � � � � 192.168.0.1 � � 0.0.0.0 � � � � UG � �0 � � �0 � � �
�0 eth0
192.168.0.0 � � 0.0.0.0 � � � � 255.255.255.0 � U � � 0 � � �0 � � �
�0 eth0
Following is a part of Fedora cloud-init script output. Instance
tries to get info from 169.254.169.254 and then switches to
192.168.0.2, which is an interface with dnsmasq injected by neutron.
I guess, metadata service is supposed to listen on 192.168.0.2, but
it's not.
[ 61.409140] cloud-init[512]: 2014-06-14 17:23:53,183 -
url_helper.py[WARNING]: Calling
'http://169.254.169.254/2009-04-04/meta-data/instance-id' failed
[50/120s]: request error [HTTPConnectionPool(host='169.254.169.254',
port=80): Request timed out. (timeout=50.0)]
[ 112.463197] cloud-init[512]: 2014-06-14 17:24:44,237 -
url_helper.py[WARNING]: Calling
'http://169.254.169.254/2009-04-04/meta-data/instance-id' failed [101/120s]:
request error [HTTPConnectionPool(host='169.254.169.254', port=80): Request
timed out. (timeout=50.0)]
[ 130.489916] cloud-init[512]: 2014-06-14 17:25:02,264 -
url_helper.py[WARNING]: Calling
'http://169.254.169.254/2009-04-04/meta-data/instance-id' failed [119/120s]:
request error [HTTPConnectionPool(host='169.254.169.254', port=80): Request
timed out. (timeout=17.0)]
[ 131.494462] cloud-init[512]: 2014-06-14 17:25:03,266 -
DataSourceEc2.py[CRITICAL]: Giving up on md from
['http://169.254.169.254/2009-04-04/meta-data/instance-id'] after 120 seconds
[ 131.502647] cloud-init[512]: 2014-06-14 17:25:03,273 - url_helper.py[WARNING]:
Calling 'http://192.168.0.2//latest/meta-data/instance-id' failed [0/120s]: request
error [HTTPConnectionPool(host='192.168.0.2', port=80): Max retries exceeded with
url: //latest/meta-data/instance-id (Caused by <class 'socket.error'>: [Errno
111] Connection refused)]
2014-06-14 20:04 GMT+03:00 Mike Spreitzer <mspre...@us.ibm.com
<mailto:mspre...@us.ibm.com>>:
Sergey Motovilovets <motovilovets.ser...@gmail.com
<mailto:motovilovets.ser...@gmail.com>> wrote on 06/14/2014
11:00:09 AM:
...
> Another problem is metadata service. I've tried like
everything I
> found regarding neutron<->metadata configuration, without any
> success. I just can't connect to 169.254.169.254 from virtual
> machines, though they get configured by dhcp, can ping each
other in
> their subnet and I can allocate floating IPs to them.
> ...
Did yo look to see if there is a wrong route in your VM?
�Sometimes I find the metadata service is messed up by a bogus
entry in the VM's routing table.
Regards,
Mike
_______________________________________________
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
--
Felix H.T Lee Academia Sinica Grid & Cloud.
Tel: +886-2-27898308
Office: Room P111, Institute of Physics, 128 Academia Road, Section 2,
Nankang, Taipei 115, Taiwan
_______________________________________________
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
