<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 13 December 2013 16:13, Alessandro Pilotti <span dir="ltr"><<a href="mailto:apilotti@cloudbasesolutions.com" target="_blank">apilotti@cloudbasesolutions.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">2) The HTTP metadata service accessible from the guest with its magic number is IMO quite far from an optimal solution. Since every hypervisor commonly<br>


used in OpenStack (e.g. KVM, XenServer, Hyper-V, ESXi) provides guest / host communication services, we could define a common abstraction layer which will<br>
include a guest side (to be included in cloud-init, cloudbase-init, etc) and a hypervisor side, to be implemented for each hypervisor and included in the related Nova drivers.<br>
This has already been proposed / implemented in various third party scenarios, but never under the OpenStack umbrella for multiple hypervisors.<br></blockquote><div><br></div><div>Firstly, what's wrong with the single anycast IP address mechanism that makes it 'not an optimal solution'?<br>

<br></div><div>While I agree we could, theoretically, make KVM, Xen, Docker, Hyper-V, VMWare and so on all implement the same backdoor mechanism - unlikely as that seems - and then implement a userspace mechanism to match in every cloud-init service in Windows, Linux, *BSD (and we then have a problem with niche OSes, too, so this mechanism had better be easy to implement, and it's likely to involve the kernel) it's hard.  And we still come unstuck when we get to bare metal, because these interfaces just can't be added there.<br>

-- <br></div><div>Ian.<br></div></div></div></div>