Today the metadata / userdata server is retrieved by the guest from http://<address of DHCP server>/latest/meta-data and http://<address<http://<address> of DHCP server>/latest/user-data
This of course has been inspired by the EC2 standard[1] http://169.254.169.254/latest/ While this works and has been incorporated into cloud-init [2], there are other platforms that do not use cloud-init and consume the userdata/metadata directly. For example, CloudFoundry [3] does not use cloud-init, rather it tries to have adapters for different cloud types. Adding support for CloudStack in this case can take a long time. Another problem is that cloud-init tries the ec2 way first, times out and then tries the CloudStack way. I found a easy way to get the EC2-style metadata addressing working in Advanced Zone / Isolated / VPC By adding the following iptables rule in the VR, the guest VM can safely address the 169.254.169.254 URL iptables -t nat -A PREROUTING -i eth0 -p tcp -m tcp --dport 80 -d 169.254.169.254/32 -j DNAT --to-destination <eth0 ip:80> The current addressing scheme continues to work while supporting the EC2 scheme. Since the VR is not on the default router in Basic Zone and other cases, this is not universally applicable. For KVM & XenServer in Basic Zone we could program the iptables rules in dom0 (host) to NAT 169.254.169.254 queries to the DHCP server. For XenServer in Advanced Zone where OVS is the default, there is no stateful NAT possible. For other hypervisors (Hyper-V, VMWare) and Baremetal, there is no comparable solution for Basic Zone and advanced networks where the VR is not the default router. However, note that this is not a breaking change, rather, an enhancement. Thoughts? — Chiradeep [1] http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-metadata.html [2] https://cloudinit.readthedocs.org/en/latest/ [3] https://github.com/cloudfoundry/bosh-agent/blob/master/settings/settings.go
