Open Stack

Padraig, Robert, Chenrui,
It seems to be a problem with nova metadata service.

> Are you using libguestfs to do the injection?
Yes - I wasn't originally, but have installed this on my controller and
compute nodes.

> What's the value of the following in nova.conf?
> libvirt_inject_key
> libvirt_inject_partition

I have the following set - I added inject_password as well to see if any
additional information could be seen.
/etc/nova/nova.conf:libvirt_inject_partition = -1
/etc/nova/nova.conf:libvirt_inject_key = True
/etc/nova/nova.conf:libvirt_inject_password = True

When I boot a Ubuntu precise image I see the following in the console log:
   [    1.573692] EXT4-fs (vda1): re-mounted. Opts: (null)
   cloud-init start-local running: Tue, 29 Oct 2013 00:15:41 +0000. up 5.11
   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.10.100.2     255.255.255.0   fa:16:3e:a6:5a:98
   ci-info: route-0: 0.0.0.0         10.10.100.3     0.0.0.0         eth0
   UG
   ci-info: route-1: 10.10.100.0     0.0.0.0         255.255.255.0   eth0
   U
   cloud-init start running: Tue, 29 Oct 2013 00:15:41 +0000. up 5.89
   seconds
   2013-10-29 00:16:32,646 - util.py[WARNING]:
   'http://169.254.169.254/2009-04-04/meta-data/instance-id' failed
   [50/120s]: url error [timed out]
   2013-10-29 00:17:23,698 - util.py[WARNING]:
   'http://169.254.169.254/2009-04-04/meta-data/instance-id' failed
   [101/120s]: url error [timed out]
   2013-10-29 00:17:41,717 - util.py[WARNING]:
   'http://169.254.169.254/2009-04-04/meta-data/instance-id' failed
   [119/120s]: url error [timed out]
   2013-10-29 00:17:42,718 - DataSourceEc2.py[CRITICAL]: giving up on md
   after 120 seconds

   no instance data found in start
   Skipping profile in /etc/apparmor.d/disable: usr.sbin.rsyslogd

Here are the metadata values defined in nova.conf:
# grep metadata_ /etc/nova/nova.conf
metadata_host=192.167.11.5
metadata_port=8775
metadata_listen=0.0.0.0
metadata_listen_port=8775
metadata_manager=nova.api.manager.MetadataManager

I am able to query the metadata server from compute / controller nodes:
# curl http://192.167.11.5:8775
1.0
...
2008-09-01
2009-04-04

If I boot cirros image and try to query the metadata server using
169.264.169.254, it fails:
$ curl http://169.254.169.254/
curl: (7) couldn't connect to host

I suspect that IP tables rules that are created to redirect from
169.264.169.254 on the guest to $metadata_host:$metadata_port are not being
created correctly - suggestions on how to debug this or why this might be
the case?

Is there documentation that helps with the setup and verification of nova
api metadata service?

Thanks,
Bill Owen
billowen at us.ibm.com
Strategic Test Methods and Tools
520-799-4829, T/L 321-4829




From:	Pádraig Brady <P at draigbrady.com>
To:	Bill Owen/Tucson/IBM at IBMUS
Cc:	openstack at lists.openstack.org
Date:	10/26/2013 02:41 PM
Subject:	Re: [Openstack] Key Injection not working after upgrading from
            Grizzly to Havana



On 10/26/2013 01:43 AM, Bill Owen wrote:
> I've just updated my test environment to stable-havana.
>
> I have booted vm instances with Fedora and Ubuntu images with a key_name
specified:
> $ nova boot --key_name  key  <vm-name> --image <image-id> --flavor 2
test_vm
>
> After the image becomes active, I try to ssh to the image, but get an
error message:
> $ ssh -i key.pem fedora@<vm-ip-addr>
> Permission denied (publickey,gssapi-keyex,gssapi-with-mic).
>
> I tried using keys/images that worked in grizzly, as well as newly
created keys and new images following the instructions in the install docs:
>
http://docs.openstack.org/trunk/install-guide/install/apt/content/nova-boot.html

>
> I don't see anything about changes in this area in release notes.  Any
suggestions on what I might be missing or how to debug would be
appreciated!
> In particular, is there a way to increase debug logging so I can see when
it tries to do the key injection on the new vm?
>
> FWIW, cirros image boots and I can ssh/login using cirros user and
password.

Injection is not under active development in Havana,
and so theoretically nothing should have changed here.

Are you using libguestfs to do the injection?
What's the value of the following in nova.conf?

 libvirt_inject_key
 libvirt_inject_partition

Note failure to inject a key does not cause a guest to error,
only failure to inject a user specified file does at present.
However at debug level, messages are printed as to why there
were errors with injecting the other components.  So please
set debug=True in nova.conf, restart the nova-compute service,
and try again, keeping an eye on /var/log/nova/compute.log

thanks,
Pádraig.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20131028/a527a7e3/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graycol.gif
Type: image/gif
Size: 105 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20131028/a527a7e3/attachment.gif>