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>: > 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 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>: > > Sergey Motovilovets <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