Re: [Openstack] problem ssh-ing into vms
On Wed, 28 Mar 2012, Pierre Amadio wrote: Hi there ! I'm puzzled with a ssh issue. Things used to work before, and now, i cannot access my vms anymore. Thank you for attaching euca-get-console-output. That provides the real hint here. | cloud-init start-local running: Wed, 28 Mar 2012 13:09:35 +. up 43.07 seconds | no instance data found in start-local | ci-info: lo: 1 127.0.0.1 255.0.0.0 | ci-info: eth0 : 1 10.0.0.3255.255.255.0 fa:16:3e:59:63:1b | ci-info: route-0: 0.0.0.0 10.0.0.10.0.0.0 eth0 UG | ci-info: route-1: 10.0.0.00.0.0.0 255.255.255.0 eth0 U | cloud-init start running: Wed, 28 Mar 2012 13:09:48 +. up 56.41 seconds | 2012-03-28 13:09:49,331 - DataSourceEc2.py[WARNING]: 'http://169.254.169.254' failed: url error [[Errno 111] Connection refused] | 2012-03-28 13:09:50,349 - DataSourceEc2.py[WARNING]: 'http://169.254.169.254' failed: url error [[Errno 111] Connection refused] | ... | 2012-03-28 13:11:29,162 - DataSourceEc2.py[WARNING]: 'http://169.254.169.254' failed: url error [[Errno 111] Connection refused] | 2012-03-28 13:11:35,174 - DataSourceEc2.py[CRITICAL]: giving up on md after 105 seconds The instance was unable to connect to the metadata service to get your public keys and put them into the instance. The Ubuntu images have an annoyance, in that if it can't get to the MD it doesn't even generate ssh server keys, so the ssh server just drops you immediately. But your real problem is that the guests can't see the host. You could potentially debug some more by using a cirros image, which will let you do password auth in after it fails to reach the data source. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] problem ssh-ing into vms
It seems iptables or some other similar software are no running on your host. openstack relies on it to translate 169.254.169.254 to host address.-openstack-bounces+gongysh=cn.ibm@lists.launchpad.net wrote: -To: Pierre Amadio pierre.ama...@canonical.comFrom: Scott Moser smo...@ubuntu.comSent by: openstack-bounces+gongysh=cn.ibm@lists.launchpad.netDate: 03/28/2012 10:16PMCc: openstack openstack@lists.launchpad.netSubject: Re: [Openstack] problem ssh-ing into vmsOn Wed, 28 Mar 2012, Pierre Amadio wrote: Hi there ! I'm puzzled with a ssh issue. Things used to work "before", and now, i cannot access my vms anymore.Thank you for attaching euca-get-console-output. That provides the realhint here.| cloud-init start-local running: Wed, 28 Mar 2012 13:09:35 +. up 43.07 seconds| no instance data found in start-local| ci-info: lo : 1 127.0.0.1255.0.0.0| ci-info: eth0 : 1 10.0.0.3255.255.255.0 fa:16:3e:59:63:1b| ci-info: route-0: 0.0.0.0 10.0.0.10.0.0.0 eth0 UG| ci-info: route-1: 10.0.0.00.0.0.0 255.255.255.0 eth0 U| cloud-init start running: Wed, 28 Mar 2012 13:09:48 +. up 56.41 seconds| 2012-03-28 13:09:49,331 - DataSourceEc2.py[WARNING]: 'http://169.254.169.254' failed: url error [[Errno 111] Connection refused]| 2012-03-28 13:09:50,349 - DataSourceEc2.py[WARNING]: 'http://169.254.169.254' failed: url error [[Errno 111] Connection refused]| ...| 2012-03-28 13:11:29,162 - DataSourceEc2.py[WARNING]: 'http://169.254.169.254' failed: url error [[Errno 111] Connection refused]| 2012-03-28 13:11:35,174 - DataSourceEc2.py[CRITICAL]: giving up on md after 105 secondsThe instance was unable to connect to the metadata service to get yourpublic keys and put them into the instance. The Ubuntu images have anannoyance, in that if it can't get to the MD it doesn't even generate sshserver keys, so the ssh server just drops you immediately.But your real problem is that the guests can't see the host.You could potentially debug some more by using a cirros image, which willlet you do password auth in after it fails to reach the data source.___Mailing list: https://launchpad.net/~openstackPost to : openstack@lists.launchpad.netUnsubscribe : https://launchpad.net/~openstackMore 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
Re: [Openstack] problem ssh-ing into vms
Hi there ! | 2012-03-28 13:11:29,162 - DataSourceEc2.py[WARNING]: 'http://169.254.169.254' failed: url error [[Errno 111] Connection refused] | 2012-03-28 13:11:35,174 - DataSourceEc2.py[CRITICAL]: giving up on md after 105 seconds The instance was unable to connect to the metadata service to get your public keys and put them into the instance. The Ubuntu images have an annoyance, in that if it can't get to the MD it doesn't even generate ssh server keys, so the ssh server just drops you immediately. But your real problem is that the guests can't see the host. Thanks, this helped a lot. The vm was on a node running nova-compute and nova-network only. Turned out the metadata service was available after i have started nova-api on top of that. I though nova-api was not needed on boxes running nova-compute ? (i have it running on a manager node that do not launch vms). Was my assumption wrong or is there something special to do to have the metadata service available without running nova-api ? ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] problem ssh-ing into vms
http://docs.openstack.org/trunk/openstack-compute/admin/content/configuring-openstack-compute-basics.html#configuring-multiple-compute-nodes:If you want to use the 10.04 Ubuntu Enterprise Cloud images that are readily available at http://uec-images.ubuntu.com/releases/10.04/release/, you may run into delays with booting. Any server that does not have nova-api running on it needs this iptables entry so that UEC images can get metadata info. On compute nodes, configure the iptables with this next step:# iptables -t nat -A PREROUTING -d 169.254.169.254/32 -p tcp -m tcp --dport 80 -j DNAT --to-destination $NOVA_API_IP:8773-openstack-bounces+gongysh=cn.ibm@lists.launchpad.net wrote: -To: openstack openstack@lists.launchpad.netFrom: Pierre Amadio pierre.ama...@canonical.comSent by: openstack-bounces+gongysh=cn.ibm@lists.launchpad.netDate: 03/28/2012 11:01PMSubject: Re: [Openstack] problem ssh-ing into vmsHi there ! | 2012-03-28 13:11:29,162 - DataSourceEc2.py[WARNING]: 'http://169.254.169.254' failed: url error [[Errno 111] Connection refused] | 2012-03-28 13:11:35,174 - DataSourceEc2.py[CRITICAL]: giving up on md after 105 seconds The instance was unable to connect to the metadata service to get your public keys and put them into the instance. The Ubuntu images have an annoyance, in that if it can't get to the MD it doesn't even generate ssh server keys, so the ssh server just drops you immediately. But your real problem is that the guests can't see the host. Thanks, this helped a lot.The vm was on a node running nova-compute and nova-network only.Turned out the metadata service was available after i have startednova-api on top of that.I though nova-api was not needed on boxes running nova-compute ? (i haveit running on a "manager" node that do not launch vms).Was my assumption wrong or is there something special to do to have themetadata service available without running nova-api ?___Mailing list: https://launchpad.net/~openstackPost to : openstack@lists.launchpad.netUnsubscribe : https://launchpad.net/~openstackMore 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
Re: [Openstack] problem ssh-ing into vms
On Mar 28, 2012, at 8:01 AM, Pierre Amadio wrote: Was my assumption wrong or is there something special to do to have the metadata service available without running nova-api ? You can run the metadata service by itself using bin/nova-api-metadata. For performance reasons, I prefer this option. Alternatively you can leave it running on the api node but you have to make sure config is set on your compute and network hosts to tell the system where to forward to. You do this via a config option in nova.conf ## (StrOpt) the ip for the metadata api server # metadata_host=$my_ip Also you have to make sure that packets are not snatted when they leave the network host if they are going to the metadata server. You can do this via a config option as well: ## (StrOpt) dmz range that should be accepted # dmz_cidr=10.128.0.0/24 So setting the following: metadata_host=api_ip dmz_cidr=api_ip/32 should work with nova-api running separately ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
