Excellent tip! Didn’t notice this in the docs before: http://docs.cloudstack.apache.org/projects/cloudstack-administration/en/4.5/virtual_machines/user-data.html
From: Carlos Reategui <car...@reategui.com<mailto:car...@reategui.com>> Reply-To: "dev@cloudstack.apache.org<mailto:dev@cloudstack.apache.org>" <dev@cloudstack.apache.org<mailto:dev@cloudstack.apache.org>> Date: Thursday, August 6, 2015 at 9:17 AM To: "dev@cloudstack.apache.org<mailto:dev@cloudstack.apache.org>" <dev@cloudstack.apache.org<mailto:dev@cloudstack.apache.org>> Subject: Re: [DISCUSS][PROPOSAL] Support for standard metadata/userdata URL BTW you can speed up cloud-init to look for CloudStack first/only by overriding the datasource_list. The way I do it is by adding a file in my templates to the /etc/cloud/cloud.cfg.d directory with only CloudStack in it: echo "datasource_list: [ CloudStack ]" > etc/cloud/cloud.cfg.d/90_datasource.cfg Start to finish on a first time boot of an instance cloud-init takes ~12 seconds on my system. A reboot of that same system, cloud-init only takes 5 seconds. This is with a default/stock cloud-init config on an ubuntu 14.04 system with just that one file added. On Wed, Aug 5, 2015 at 10:46 PM, Chiradeep Vittal < chiradeep.vit...@citrix.com<mailto:chiradeep.vit...@citrix.com>> wrote: 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
