<div>The original purpose behind sharing the HostID with a customer was to allow a customer to identify situations where they had two VMs placed on the same host. This knowledge is extremely critical if a customer is trying to setup two VMs in an HA configuration. Because this use case does not require the HostID to be globally unique the HostID was hashed with the customer ID to create a customer specific identifier for each host. (This is how Rackspace Cloud Servers works today.)</div>
<div><br></div><div>The two arguments that I have heard for not making HostIDs globally unique are; one, it would allow customers (or partners) to figure out exactly how many hosts a given cloud is running and two, it would potentially allow customers to figure out if their VM is on the same host as another customer's VM. The first concern is specific to the cloud operator; some operators may feel that the size of their cloud is material information that needs to be protected, while other operators may go as far as to publish those types of stats. The second concern is around the potential for a customer to either a) impact the performance of another customer's VM by excessively taxing the host machine or b) if there was a hypervisor exploit it would enable a customer to more easily target another customer's VM. For example, if you found out the HostID of your target VM you could then keep spinning up instances until you got one on the same host, then attack.</div>
<div><br></div><div>I strongly feel that HostID should be unique per project (or tenant) and if it isn't that way right now I think we should look at changing it.</div><div><br></div><div>Of course this doesn't address Glen's original question which is around the need for an cloud admin to have a globally unique host identifier for targeting operations on a specific host. That type of concept is probably worth building in, but in my opinion should be separate from HostID (which should be reserved for determining VM placement collisions).</div>
<div><br></div><div>-Blake</div><div><br></div>On Sat, Jul 16, 2011 at 10:47 AM, Jorge Williams <span dir="ltr"><<a href="mailto:jorge.williams@rackspace.com">jorge.williams@rackspace.com</a>></span> wrote:<br><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">Right so we should really be hashing this with the tenant ID as well.<br>
<br>
-jOrGe W.<br>
<div><div></div><div class="h5"><br>
On Jul 15, 2011, at 6:16 PM, Chris Behrens wrote:<br>
<br>
> I think it's sensitive because one could figure out how many hosts a SP has globally... which a SP might not necessarily want to reveal.<br>
><br>
> - Chris<br>
><br>
><br>
> On Jul 15, 2011, at 3:34 PM, <a href="mailto:karim.allah.ahmed@gmail.com">karim.allah.ahmed@gmail.com</a> wrote:<br>
><br>
>> On Fri, Jul 15, 2011 at 11:31 PM, Chris Behrens <<a href="mailto:chris.behrens@rackspace.com">chris.behrens@rackspace.com</a>> wrote:<br>
>> Nevermind. Just found a comment in the API spec that says "hostID" is unique per account, not globally. Hmmm...<br>
>><br>
>> This is weird ! I can't find anything in the code that says so !! hostID is just a hashed version of the 'host' which is set as the 'hostname' of the physical machine and this isn't user sensitive. So, It's supposed to be a global thing !<br>
>><br>
>> Can somebody explain how this is a user sensitive ?<br>
>><br>
>><br>
>><br>
>> On Jul 15, 2011, at 2:27 PM, Chris Behrens wrote:<br>
>><br>
>>> I see the v1.1 API spec talks about a 'hostId' item returned when you list your instances (section 4.1.1 in the spec). These should be the same thing, IMO.<br>
>>><br>
>>> I think you're right, though. I don't believe we have any sort of 'hostId' today, since hosts just become available by attaching to AMQP.<br>
>>><br>
>>> - Chris<br>
>>><br>
>>> On Jul 15, 2011, at 1:16 PM, Glen Campbell wrote:<br>
>>><br>
>>>> I understand that we're all familiar with virtualization and its benefits. However, in the Real World, those of us who run clouds often need to work with physical devices. I've proposed a blueprint and spec for a /hosts admin API resource that would return information on physical hosts. However, I don't believe that there's any way for us to actually identify a specific server (I'm actually hoping I'm mistaken about this, because that would make my life easier).<br>
>>>><br>
>>>> So, to get information about a specific host, you'd use /host/{id} — but what should go in the {id} slot?<br>
>>>><br>
>>>> We'd also like to include this data elsewhere; for example, in error messages, it might help to know the physical device on which a server is created.<br>
>>>><br>
>>>><br>
>>>> <signature[4].png><br>
>>>> This email may include confidential information. If you received it in error, please delete it.<br>
>>>> _______________________________________________<br>
>>>> Mailing list: <a href="https://launchpad.net/~openstack" target="_blank">https://launchpad.net/~openstack</a><br>
>>>> Post to : <a href="mailto:openstack@lists.launchpad.net">openstack@lists.launchpad.net</a><br>
>>>> Unsubscribe : <a href="https://launchpad.net/~openstack" target="_blank">https://launchpad.net/~openstack</a><br>
>>>> More help : <a href="https://help.launchpad.net/ListHelp" target="_blank">https://help.launchpad.net/ListHelp</a><br>
>>><br>
>><br>
>> This email may include confidential information. If you received it in error, please delete it.<br>
>><br>
>><br>
>> _______________________________________________<br>
>> Mailing list: <a href="https://launchpad.net/~openstack" target="_blank">https://launchpad.net/~openstack</a><br>
>> Post to : <a href="mailto:openstack@lists.launchpad.net">openstack@lists.launchpad.net</a><br>
>> Unsubscribe : <a href="https://launchpad.net/~openstack" target="_blank">https://launchpad.net/~openstack</a><br>
>> More help : <a href="https://help.launchpad.net/ListHelp" target="_blank">https://help.launchpad.net/ListHelp</a><br>
>><br>
>><br>
>><br>
>> --<br>
>> Karim Allah Ahmed.<br>
>> LinkedIn<br>
>><br>
>> _______________________________________________<br>
>> Mailing list: <a href="https://launchpad.net/~openstack" target="_blank">https://launchpad.net/~openstack</a><br>
>> Post to : <a href="mailto:openstack@lists.launchpad.net">openstack@lists.launchpad.net</a><br>
>> Unsubscribe : <a href="https://launchpad.net/~openstack" target="_blank">https://launchpad.net/~openstack</a><br>
>> More help : <a href="https://help.launchpad.net/ListHelp" target="_blank">https://help.launchpad.net/ListHelp</a><br>
><br>
> This email may include confidential information. If you received it in error, please delete it.<br>
><br>
><br>
> _______________________________________________<br>
> Mailing list: <a href="https://launchpad.net/~openstack" target="_blank">https://launchpad.net/~openstack</a><br>
> Post to : <a href="mailto:openstack@lists.launchpad.net">openstack@lists.launchpad.net</a><br>
> Unsubscribe : <a href="https://launchpad.net/~openstack" target="_blank">https://launchpad.net/~openstack</a><br>
> More help : <a href="https://help.launchpad.net/ListHelp" target="_blank">https://help.launchpad.net/ListHelp</a><br>
<br>
This email may include confidential information. If you received it in error, please delete it.<br>
<br>
<br>
_______________________________________________<br>
Mailing list: <a href="https://launchpad.net/~openstack" target="_blank">https://launchpad.net/~openstack</a><br>
Post to : <a href="mailto:openstack@lists.launchpad.net">openstack@lists.launchpad.net</a><br>
Unsubscribe : <a href="https://launchpad.net/~openstack" target="_blank">https://launchpad.net/~openstack</a><br>
More help : <a href="https://help.launchpad.net/ListHelp" target="_blank">https://help.launchpad.net/ListHelp</a><br>
</div></div></blockquote></div><br>