When using the multi-host network mode, the simplest solution is to install either the whole nova-api service, or better yet, just the nova-api-metadata service alongside every nova-network.
If you're on Ubuntu, just install the nova-api-metadata package.. Thanks, Kiall Sent from my phone. On Jun 20, 2012 8:55 p.m., "Lars Kellogg-Stedman" <l...@seas.harvard.edu> wrote: > We seem to have OpenStack working correctly with a FlatDHCP network > environment, running in multi_host mode. Outbound connectivity works just > fine: > > instance# curl http://google.com > <HTML><HEAD><meta http-equiv="content-type" > content="text/html;charset=utf-8"> > <TITLE>301 Moved</TITLE></HEAD><BODY> > <H1>301 Moved</H1> > The document has moved > <A HREF="http://www.google.com/";>here</A>. > </BODY></HTML> > > We are having problems with connectivity from the instance to our > OpenStack controller (particularly the metadata service). Our compute > host is configured like this: > > public_interface = em1 > flat_interface = bond0.662 > bridge = br662 > fixed_range = 10.243.28.0/24 > routing_source_ip = 10.243.16.151 > flat_network_dhcp_start = 10.243.28.10 > > Here's the bridge, with one instance attached: > > br662 8000.00212883a78c no bond0.662 > vnet0 > > Our metadata server is at 10.243.21.36, and the example instance is at > 10.243.28.28: > > instance# ifconfig > eth0 Link encap:Ethernet HWaddr fa:16:3e:40:f3:ad > inet addr:10.243.28.28 Bcast:10.243.28.255 Mask:255.255.255.0 > > >From the instance, it's not possible to access the metadata server, > either directly or via the DNAT rule for 169.254.169.254. An attempt > to access http://10.243.21.26:8775/ fails because this causes a packet > to be emitted on public_interface with a source address from > fixed_range on our private network: > > host# tshark -i em1 -n host 10.243.21.36 > 0.000000 10.243.28.28 -> 10.243.21.36 TCP 37070 > 8775 [SYN] Seq=0 > Win=14600 Len=0 MSS=1460 TSV=1699692 TSER=0 WS=3 > > This is promptly discarded by the routing infrastructure, since the > source address of the packet does not match the address range of the > network. > > The connection avoids the SNAT rule applied to other connections > because of this rule: > > -A nova-network-POSTROUTING -s 10.243.28.0/24 -d 10.243.21.36/32 -j > ACCEPT > > What is the reason to skip SNAT for access to controller? The only > configuration I can see in which this would work is to give the metadata > server an interface on the private instance network...but this doesn't > seem to match any of the architecture diagrams I've seen at > openstack.org, and it poses another set of problems w/r/t the DNAT > rule (with the metadata server on the *same* network as the instance, > access via http://169.254.169.254/ will fail because returning packets > will have the wrong source address). > > I'm assuming that some part of our configuration does not match the > expectations of nova-network. I would be grateful for suggestions as > to which part needs fixing. > > -- > Lars Kellogg-Stedman <l...@seas.harvard.edu> | > Senior Technologist | > http://ac.seas.harvard.edu/ > Academic Computing | > http://code.seas.harvard.edu/ > Harvard School of Engineering and Applied Sciences | > > > _______________________________________________ > 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
