openstack team mailing list archive

[Blake Yeager <blake.yeager@xxxxxxxxx>]

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.)

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.

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.

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).

-Blake

On Sat, Jul 16, 2011 at 10:47 AM, Jorge Williams <
jorge.williams@xxxxxxxxxxxxx> wrote:

> Right so we should really be hashing this with the tenant ID as well.
>
> -jOrGe W.
>
> On Jul 15, 2011, at 6:16 PM, Chris Behrens wrote:
>
> > 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.
> >
> > - Chris
> >
> >
> > On Jul 15, 2011, at 3:34 PM, karim.allah.ahmed@xxxxxxxxx wrote:
> >
> >> On Fri, Jul 15, 2011 at 11:31 PM, Chris Behrens <
> chris.behrens@xxxxxxxxxxxxx> wrote:
> >> Nevermind.  Just found a comment in the API spec that says "hostID" is
> unique per account, not globally.  Hmmm...
> >>
> >> 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 !
> >>
> >> Can somebody explain how this is a user sensitive ?
> >>
> >>
> >>
> >> On Jul 15, 2011, at 2:27 PM, Chris Behrens wrote:
> >>
> >>> 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.
> >>>
> >>> 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.
> >>>
> >>> - Chris
> >>>
> >>> On Jul 15, 2011, at 1:16 PM, Glen Campbell wrote:
> >>>
> >>>> 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).
> >>>>
> >>>> So, to get information about a specific host, you'd use /host/{id} —
> but what should go in the {id} slot?
> >>>>
> >>>> 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.
> >>>>
> >>>>
> >>>> <signature[4].png>
> >>>> This email may include confidential information. If you received it in
> error, please delete it.
> >>>> _______________________________________________
> >>>> Mailing list: https://launchpad.net/~openstack
> >>>> Post to     : openstack@xxxxxxxxxxxxxxxxxxx
> >>>> Unsubscribe : https://launchpad.net/~openstack
> >>>> More help   : https://help.launchpad.net/ListHelp
> >>>
> >>
> >> This email may include confidential information. If you received it in
> error, please delete it.
> >>
> >>
> >> _______________________________________________
> >> Mailing list: https://launchpad.net/~openstack
> >> Post to     : openstack@xxxxxxxxxxxxxxxxxxx
> >> Unsubscribe : https://launchpad.net/~openstack
> >> More help   : https://help.launchpad.net/ListHelp
> >>
> >>
> >>
> >> --
> >> Karim Allah Ahmed.
> >> LinkedIn
> >>
> >> _______________________________________________
> >> Mailing list: https://launchpad.net/~openstack
> >> Post to     : openstack@xxxxxxxxxxxxxxxxxxx
> >> Unsubscribe : https://launchpad.net/~openstack
> >> More help   : https://help.launchpad.net/ListHelp
> >
> > This email may include confidential information. If you received it in
> error, please delete it.
> >
> >
> > _______________________________________________
> > Mailing list: https://launchpad.net/~openstack
> > Post to     : openstack@xxxxxxxxxxxxxxxxxxx
> > Unsubscribe : https://launchpad.net/~openstack
> > More help   : https://help.launchpad.net/ListHelp
>
> This email may include confidential information. If you received it in
> error, please delete it.
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>