Have you migrated to Neutron at the same time as upgrading? There are installer docs for metadata with Neutron; the troubleshooting process will depend on the production config you chose - e.g. namespaced network, or not etc.
Cheers, Rob On 29 October 2013 14:14, Bill Owen <[email protected]> wrote: > 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 > [email protected] > Strategic Test Methods and Tools > 520-799-4829, T/L 321-4829 > > > [image: Inactive hide details for Pádraig Brady ---10/26/2013 02:41:27 > PM---On 10/26/2013 01:43 AM, Bill Owen wrote: > I've just update]Pádraig > Brady ---10/26/2013 02:41:27 PM---On 10/26/2013 01:43 AM, Bill Owen wrote: > > I've just updated my test environment to stable-havana. > > From: Pádraig Brady <[email protected]> > To: Bill Owen/Tucson/IBM@IBMUS > Cc: [email protected] > 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. > > > -- Robert Collins <[email protected]> Distinguished Technologist HP Converged Cloud
<<graycol.gif>>
_______________________________________________ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : [email protected] Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
