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@redhat.com>:
On 9 Jul 2014, at 13:14, Madko <madko77@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@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@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@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@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@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@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@redhat.com >:
> > > Hi,
> > >
> > > Did you try with using the “cloud-user” login username?
> > >
> > > Thanks
> > > Rhys
> > >
> > > On 4 Jul 2014, at 09:22, Madko < madko77@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@redhat.com
> > > > https://www.redhat.com/mailman/listinfo/rdo-list
> > >
> > >
> > >
> > >
> > > --
> > > Edouard Bourguignon
> >
> >
> >
> >
> > --
> > Edouard Bourguignon
> >
> > _______________________________________________
> > Rdo-list mailing list
> > Rdo-list@redhat.com
> > https://www.redhat.com/mailman/listinfo/rdo-list
> >
> >
> >
> >
> >
> > --
> > Edouard Bourguignon
> >
> >
> >
> > --
> > Edouard Bourguignon
> >
> > _______________________________________________
> > Rdo-list mailing list
> > Rdo-list@redhat.com
> > https://www.redhat.com/mailman/listinfo/rdo-list
> >
>
>
>
> --
> Edouard Bourguignon
> _______________________________________________
> Rdo-list mailing list
> Rdo-list@redhat.com
> https://www.redhat.com/mailman/listinfo/rdo-list




--
Edouard Bourguignon