Thierry, you're right. I'd like the platform to identify itself to the guest. And openstack already does this in libvirt/kvm and i386/x86_64 (which I suggest is by far the most common deployment path).
In order to create cross cloud-platform images there has to be some way to determine where an image is running, so it can behave appropriately for the platform.
Essentially, we have a communication mechanism in smbios/dmi where by the host says "You're running on OpenStack". Once that bit of information is established, cloud-init can then decide to reach the metadata service that openstack provides (http://169.254.169.254/openstack/).
Without the identification from the host, poking/polling at this network service can be problematic for many reasons.
Thierry, you're right. I'd like the platform to identify itself to the guest. And openstack already does this in libvirt/kvm and i386/x86_64 (which I suggest is by far the most common deployment path).
In order to create cross cloud-platform images there has to be some way to determine where an image is running, so it can behave appropriately for the platform.
Essentially, we have a communication mechanism in smbios/dmi where by the host says "You're running on OpenStack". Once that bit of information is established, cloud-init can then decide to reach the metadata service that openstack provides (http:// 169.254. 169.254/ openstack/).
Without the identification from the host, poking/polling at this network service can be problematic for many reasons.