Ok I have no NAT rules, so the problem seems to be on the l3-agent. I will
check that part. Thanks again for the help.
2014-07-09 14:21 GMT+02:00 Rhys Oxenham <roxenham(a)redhat.com>:
On 9 Jul 2014, at 13:14, Madko <madko77(a)gmail.com> wrote:
> thanks Assaf for the point. But When I try to connect to 169.254.169.254
on the Cirros VM I only get a no route to host. On the Fedora VM, the
CloudInit seems to know the IP address of the metadata agent and try to
contact this IP (instead of 169.254.169.254). I can't recall where exactly
but I remember I read something about neutron doing some NAT with iptables
to forward the http request to the right address. How can I check this NAT
rules? I don't see anything like this with iptables.
>
You can check the NAT rules on the L3 agent (if using the default
configuration)...
'ip netns list’ to find the router namespace appropriate for the tenant
network that your instance is operating in.
You may have to use ‘neutron router-list’ to find the correct UUID.
Then, execute the following to check the NAT rules:
‘ip netns exec qrouter-XXXX iptables -L -t nat’ (replace XXXX with the
router ID you found in the previous command)
You should expect something in the output like this:
Chain neutron-l3-agent-PREROUTING (1 references)
target prot opt source destination
REDIRECT tcp -- anywhere 169.254.169.254 tcp dpt:http
redir ports 9697
>
> 2014-07-06 11:08 GMT+02:00 Assaf Muller <amuller(a)redhat.com>:
>
>
> ----- Original Message -----
> > Great!!! I can connect to the cirros instance. But no
.ssh/authorized_keys.
> > Seems the metadata api is not available. Where is it supposed to be
hosted?
> > what service? is it the neutron-metadata-agent?
> >
>
> Metadata is hosted by the nova-api server. When using Neutron, the
neutron-metadata-
> agent on the network node proxies metadata requests to nova-api. It does
a couple
> of queries to Neutron,adds the instance-id to the request and forwards
the message
> to nova-api. This is because when using nova-network you cannot have
overlapping IPs
> so the nova metadata server can figure out the instance ID from its IP.
Neutron
> does support overlapping IPs so that's why the neutron-metadata-agent
exists.
>
> If curl 169.254.169.254 doesn't work, check for errors in the neutron
metadata
> agent logs and in nova-api as well.
>
> >
> > 2014-07-04 13:13 GMT+02:00 Madko < madko77(a)gmail.com > :
> >
> >
> >
> > Thank you Rhys and Vimal, I'll try cyrros image right now.
> >
> >
> > 2014-07-04 11:55 GMT+02:00 Vimal Kumar < vimal7370(a)gmail.com > :
> >
> >
> >
> >
> > Use cirros (13M) image to test if ssh key-pair injection is working or
not:
> >
> >
http://download.cirros-cloud.net/0.3.2/cirros-0.3.2-x86_64-disk.img
> >
> > ssh as: cirros@<ip>
> >
> > In case if your ssh key isn't working, the password is cubswin:)
> >
> >
> >
> > On Fri, Jul 4, 2014 at 3:20 PM, Madko < madko77(a)gmail.com > wrote:
> >
> >
> >
> > I've just deployed OpenStack so I don't have any other image. I can
try to
> > make one. Is cloudInit easy to install on Fedora ? I have some CentOS
images
> > too, but no cloudInit.
> >
> >
> > 2014-07-04 11:45 GMT+02:00 Rhys Oxenham < roxenham(a)redhat.com > :
> >
> >
> >
> > Can you try another image to make sure that key pair injection is
working
> > inside of your environment? i.e. an image you already know the
password for
> > so you can check via VNC or passworded ssh login?
> >
> > Cheers
> > Rhys
> >
> > On 4 Jul 2014, at 10:40, Madko < madko77(a)gmail.com > wrote:
> >
> > > Nope didn't try this one, but no luck, same problem :( (I tried root,
> > > fedora, and now cloud-user)
> > >
> > > [root@openstack-neutron ~]# ip netns exec
> > > qdhcp-1d742b5e-c3f3-430f-b8a9-275bcbf967a3 ping 192.168.2.4
> > > PING 192.168.2.4 (192.168.2.4) 56(84) bytes of data.
> > > 64 bytes from 192.168.2.4 : icmp_seq=1 ttl=64 time=2.02 ms
> > > 64 bytes from 192.168.2.4 : icmp_seq=2 ttl=64 time=1.90 ms
> > > ^C
> > > --- 192.168.2.4 ping statistics ---
> > > 2 packets transmitted, 2 received, 0% packet loss, time 1161ms
> > > rtt min/avg/max/mdev = 1.900/1.964/2.029/0.078 ms
> > > [root@openstack-neutron ~]# ip netns exec
> > > qdhcp-1d742b5e-c3f3-430f-b8a9-275bcbf967a3 ssh -i neutron_test.pem -l
> > > cloud-user 192.168.2.4
> > > Permission denied (publickey,gssapi-keyex,gssapi-with-mic).
> > >
> > >
> > >
> > > 2014-07-04 11:09 GMT+02:00 Rhys Oxenham < roxenham(a)redhat.com >:
> > > Hi,
> > >
> > > Did you try with using the “cloud-user” login username?
> > >
> > > Thanks
> > > Rhys
> > >
> > > On 4 Jul 2014, at 09:22, Madko < madko77(a)gmail.com > wrote:
> > >
> > > > Hi,
> > > >
> > > > I have an almost working openstack platform deployed via foreman.
When I
> > > > launch an instance from the Fedora 19 cloud image, everything seems
> > > > fine, the VM is running on one of my hypervisor, but I can't
access it
> > > > (ping is ok)...
> > > >
> > > > I'm following this documentation
> > > >
http://openstack.redhat.com/Running_an_instance
> > > >
> > > > I only get a permission denied when I do the last part:
> > > > ssh -l root -i my_key_pair.pem floating_ip_address
> > > > I also try by importing an ssh key. Same error.
> > > >
> > > > In the VM console, I see that CloudInit service is starting inside
the
> > > > VM, no error are shown here. So my question is: Where are the logs
for
> > > > that parts (cloud init server) in openstack ? Is the above
documentation
> > > > fine ?
> > > >
> > > > best regards,
> > > >
> > > > --
> > > > Edouard Bourguignon
> > > > _______________________________________________
> > > > Rdo-list mailing list
> > > > Rdo-list(a)redhat.com
> > > >
https://www.redhat.com/mailman/listinfo/rdo-list
> > >
> > >
> > >
> > >
> > > --
> > > Edouard Bourguignon
> >
> >
> >
> >
> > --
> > Edouard Bourguignon
> >
> > _______________________________________________
> > Rdo-list mailing list
> > Rdo-list(a)redhat.com
> >
https://www.redhat.com/mailman/listinfo/rdo-list
> >
> >
> >
> >
> >
> > --
> > Edouard Bourguignon
> >
> >
> >
> > --
> > Edouard Bourguignon
> >
> > _______________________________________________
> > Rdo-list mailing list
> > Rdo-list(a)redhat.com
> >
https://www.redhat.com/mailman/listinfo/rdo-list
> >
>
>
>
> --
> Edouard Bourguignon
> _______________________________________________
> Rdo-list mailing list
> Rdo-list(a)redhat.com
>
https://www.redhat.com/mailman/listinfo/rdo-list