<html> <head> <meta http-equiv="Content-Type" content="text/html; charset=Windows-1252"> <style style="display: none;" id="owaParaStyle" type="text/css">P {margin-top:0;margin-bottom:0;}</style><style>  </style> </head> <body tabindex="0" aria-label="Nachrichtentext" fpstyle="1" dir="ltr"> <div name="divtagdefaultwrapper" id="divtagdefaultwrapper" style="font-family: Tahoma, Geneva, sans-serif; font-size: 10pt; color: #000000; margin: 0"> Hello! I worked with the 169.254.169.254 aka metadata server quite a bit. The first thing I discovered is that there is only an IPtables redirect for access to port 80, which means that access *must* go through an OpenStack router, otherwise the ARP requests seek 169.254.169.254, not the router address. This happened for me when I used an external router, which of course does not redirect to the metadata server. So I set up a secondary router and passed a route to 169.254.0.0/16 to the VMs as an explicit route (may not work with some DHCP clients). I can't log into the computer center right now, so I can't check for the process you are missing, but maybe the above will give you an alternate path to pursue. Maybe I misunderstood you, and this does not apply. Then I apologize for wasting your time. <div> <title></title> <basefont size="2" face="Arial"> Best regards / Mit freundlichen Grüßen Lutz Christoph -- Lutz Christoph arago Institut für komplexes Datenmanagement AG Eschersheimer Landstraße 526 - 532 60433 Frankfurt am Main eMail: lchristoph@arago.de - www: http://www.arago.de Tel: 0172/6301004 Mobil: 0172/6301004 <a href="http://www.cloudops.de/"><img border="0" height="88" width="350" src="http://www.arago.net/wp-content/uploads/2013/06/EmailSignatur1.png"> </a> -- Bankverbindung: Frankfurter Sparkasse, BLZ: 500 502 01, Kto.-Nr.: 79343 Vorstand: Hans-Christian Boos, Martin Friedrich Vorsitzender des Aufsichtsrats: Dr. Bernhard Walther Sitz: Kronberg im Taunus - HRB 5731 - Registergericht: Königstein i.Ts Ust.Idnr. DE 178572359 - Steuernummer 2603 003 228 43435 </div> <div style="color: rgb(40, 40, 40);"> <hr tabindex="-1" style="display:inline-block; width:98%"> <div id="divRplyFwdMsg" dir="ltr">Von: rhos-list-bounces@redhat.com <rhos-list-bounces@redhat.com> im Auftrag von Randy Krenz <randy.krenz@overturenetworks.com> Gesendet: Donnerstag, 29. August 2013 19:57 An: rhos-list@redhat.com Betreff: [rhos-list] issue with metadata server <div> </div> </div> <div> <div class="WordSection1"> I’m experiencing an issue with the quantum metadata server. I seem to be having the same issue on either the RDO or Redhat-supported versions of OpenStack. I’m trying to provide the metadata service on an isolated virtual network via the DHCP namespace. As such, I have set “enable_isolated_metadata = True” in dhcp_agent.ini. When I start a virtual machine on this network, the virtual machine fails to reach the metadata service. If I login to the virtual machine, I see that the DHCP server has added a route which says the DHCP server IP address is the route to 169.254.169.254, as expected. I also see that the quantum-metadata-agent is running on the bare-metal Linux and is responding to curl requests on port 8775. What I don’t see is quantum-ns-metadata-proxy running, which I thought was supposed to be spawned with the DHCP server. Probably some kind of configuration error but just can’t put my finger on it. Don’t see any obvious issues in /var/log/quantum. Any help appreciated. Randy Here is my dhcp_agent.ini: [DEFAULT] # Show more verbose log output (sets INFO log level output). # verbose = True # Show debugging output in log (sets DEBUG log level output). # debug = False debug = False # Where to store dnsmasq state files. This directory must be writable by the # user executing the agent. The value below is compatible with a default # devstack installation. # state_path = /var/lib/quantum state_path = /var/lib/quantum # The DHCP agent will resync its state with Quantum to recover from any # transient notification or rpc errors. The interval is number of # seconds between attempts. # resync_interval = 5 resync_interval = 30 # The DHCP agent requires that an interface driver be set. Choose the # one that best matches you plugin. There is no default. # interface_driver = # # OVS # interface_driver = quantum.agent.linux.interface.OVSInterfaceDriver interface_driver = quantum.agent.linux.interface.OVSInterfaceDriver # LinuxBridge # interface_driver = quantum.agent.linux.interface.BridgeInterfaceDriver # Ryu # interface_driver = quantum.agent.linux.interface.RyuInterfaceDriver # The agent can use other DHCP drivers. Dnsmasq is the simplest and requires # no additional setup of the DHCP server. # dhcp_driver = quantum.agent.linux.dhcp.Dnsmasq dhcp_driver = quantum.agent.linux.dhcp.Dnsmasq use_namespaces = False enable_isolated_metadata = True </div> This email and attachments may contain privileged or confidential information intended only for the addressee(s) indicated. The sender does not waive any of its rights, privileges or protections respecting this information. If you are not the named addressee, an employee, or agent responsible for sending this message to the named addressee (or this message was received by mistake), you are not authorized to read, print, retain, copy or disseminate this message or any part of it. If received in error, please notify us immediately by e-mail, discard any paper copies and delete all electronic files of the email. Computer viruses can be transmitted via email. The recipient should check this email and any attachments for viruses. Email transmission cannot be guaranteed to be secured or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender accepts no liability for any damage caused by any transmitted viruses or errors or omissions in the contents of this message. Overture Networks, Inc. 637 Davis Drive, Morrisville, NC USA 27560 www.overturenetworks.com </div> </div> </div> </body> </html>