thanks will try that asap Regards, Pranav
On Tue, Mar 19, 2013 at 8:53 PM, bruno sendas <bsen...@gmail.com> wrote: > Hi, > > I had tried every sollution posted on the openstack archives and it simply > wouldn't work. > Until I had the wrong idea and installed the nova-api-metadata on the > controller node and it removed the nova-api, which corrupted the openstack > deployment. So when I re-installed all the nova components (the > nova-api-metadata was removed), one reboot later and the metadata server > was running. :))) > > Also, I added a route to the Private Network ( for the VM) using the > router external gateway. > > The problem must have been from a bad installation of nova-api int the > controller node. > > best regards, > Bruno > > > 2013/3/18 Pranav <pps.pra...@gmail.com> > >> I think this should solve the metadata issue, but there is one more >> issue, the instances do not seem to get IP address and also it is not so >> clear weather to use L2 with L3. >> Regards, >> Pranav >> >> >> On Tue, Mar 19, 2013 at 1:18 AM, Anne Gentle <a...@openstack.org> wrote: >> >>> Hi all, >>> >>> I've got a doc bug against the Basic Install guide that I've been trying >>> to understand. [1] >>> >>> The first issue is that the Basic Install guide doesn't tell the user to >>> install the nova-api-metadata service. But there's more to it than just >>> that, I believe. Two doc comments have noted that there's a routing issue >>> as well: >>> >>> "there seems to be a step left out of this guide on the controller setup >>> ...once you create the tenant subnets you need to add the route from the >>> internal ips in this case route add -n 10.5.5.0/24 gw (the external >>> router project IP ) once i did this on the controller node it pulls the >>> metadata perfectly" >>> >>> Does this routing sound like the solution in your cases? >>> >>> Anne >>> >>> 1. https://bugs.launchpad.net/openstack-manuals/+bug/1108040 >>> >>> >>> On Mon, Mar 18, 2013 at 2:11 PM, Pranav <pps.pra...@gmail.com> wrote: >>> >>>> Having similar issues... someone please do help us if poss. >>>> Regards, >>>> Pranav >>>> >>>> >>>> On Tue, Mar 19, 2013 at 12:35 AM, Gui Maluf <guimal...@gmail.com>wrote: >>>> >>>>> >>>>> >>From what I understood, without the retrieval of the metadata from the >>>>> >server, the keys are not downloaded to the VM, is this correct? >>>>> >>>>> Yes. This is correct. >>>>> >>>>> AFAIK in Essex, the metadata service was pointed out through iptables. So >>>>> there was a rule that DNAT the metadata service to the CC machine. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> I had this metadata problem too, but I couldn't find out a proper >>>>> solution. >>>>> My guess is that this problem is related to the Gateway/Router in >>>>> Folsom+Quantum installation. Or maybe in the metadata_host in the >>>>> nova.conf file. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> I hope someone could clarify this things for us. >>>>> >>>>> >>>>> regards. >>>>> >>>>> >>>>> >>>>> On Mon, Mar 18, 2013 at 7:32 AM, Bruno Parreira <bsen...@gmail.com>wrote: >>>>> >>>>>> >>>>>> Hi, >>>>>> >>>>>> >>>>>> >>>>>> We have deployed OpenStack using the guide provided at the OpenStack >>>>>> webpage: >>>>>> >>>>>> Host A : controller node >>>>>> >>>>>> Host B : network node >>>>>> >>>>>> Host C : compute node >>>>>> >>>>>> >>>>>> >>>>>> Everything went fine during the installation process, but when we try to >>>>>> instantiate a VM, the logs show that the VMs are unable to connect to the >>>>>> metadata service (169.254.169.254). >>>>>> >>>>>> We've tried this with the Ubuntu image and the Cirros image, but the >>>>>> result >>>>>> is the same. >>>>>> >>>>>> >>>>>> >>>>>> >From what I understood, without the retrieval of the metadata from the >>>>>> server, the keys are not downloaded to the VM, is this correct? >>>>>> >>>>>> Because we can ping the IP address assigned to the VM from the network >>>>>> node, >>>>>> and if we assign a floating IP to the VM, the public IP also responds to >>>>>> ping replys. >>>>>> >>>>>> But we are unable to ssh into the VMs, with the error: "Read from socket >>>>>> failed: Connection reset by peer" >>>>>> >>>>>> If we try to telnet into the public IP this is the result: >>>>>> >>>>>> >>>>>> >>>>>> controller@controller:~$ telnet x.x.x.x 22 >>>>>> >>>>>> Trying x.x.x.x... >>>>>> >>>>>> Connected to x.x.x.x. >>>>>> >>>>>> Escape character is '^]'. >>>>>> >>>>>> SSH-2.0-OpenSSH_5.9p1 Debian-5ubuntu1 >>>>>> >>>>>> >>>>>> >>>>>> Protocol mismatch. >>>>>> >>>>>> Connection closed by foreign host. >>>>>> >>>>>> >>>>>> >>>>>> Questions: >>>>>> >>>>>> In which node is the metadata service supposed to be running (compute, >>>>>> network or controller)? >>>>>> >>>>>> Should the IP address 169.254.169.254 be reachable outside the VM? >>>>>> >>>>>> Is there an alternative to the metadata service? >>>>>> >>>>>> >>>>>> >>>>>> Kind regards, >>>>>> >>>>>> Bruno Parreira >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Mailing list: https://launchpad.net/~openstack >>>>>> Post to : openstack@lists.launchpad.net >>>>>> Unsubscribe : https://launchpad.net/~openstack >>>>>> More help : https://help.launchpad.net/ListHelp >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> *guilherme* \n >>>>> \t *maluf* >>>>> >>>>> _______________________________________________ >>>>> Mailing list: https://launchpad.net/~openstack >>>>> Post to : openstack@lists.launchpad.net >>>>> Unsubscribe : https://launchpad.net/~openstack >>>>> More help : https://help.launchpad.net/ListHelp >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> Mailing list: https://launchpad.net/~openstack >>>> Post to : openstack@lists.launchpad.net >>>> Unsubscribe : https://launchpad.net/~openstack >>>> More help : https://help.launchpad.net/ListHelp >>>> >>>> >>> >> >
_______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
