Hi Dan,
Thanks for your clear answer. I do confirm, the 169.254.0.0/16 route was
working with my nova-network setup (FlatDHCP).
When mentioning Grizzly pushing a route to VMs, I guess it would be
possible to backport it to Folsom.
Do you have any idea on which changes to do for that feature
Hi Sylvain,
The answer here is that "it depends".
If you are using Folsom + Quantum, the only supported mechanism is reaching
the metadata server is via your default gateway, so VMs should not have
specific routes to reach the metadata subnet (I believe this is also the
case for nova-network, so
Yet no reply ?
I did the hack, I removed the 169.254.0.0/16 route from my images, but
this is quite a ugly hack.
Could someone with OpenVswitch/GRE setup please confirm that there is no
route to create for metadata ?
Thanks,
-Sylvain
Le 21/02/2013 11:33, Sylvain Bauza a écrit :
Anyone ?
I f
Anyone ?
I found the reason why a 'quantum-dhcp-agent restart' is fixing the
route, this is because the lease is DHCPNACK'd at next client refresh
and the VM is getting a fresh new configuration excluding 169.254.0.0/16
route.
Community, I beg you to confirm the 169.254.0.0/16 route should *n
4 matches
Mail list logo