On Thu, Nov 20, 2008 at 02:28, Douglas A. Tutty <[EMAIL PROTECTED]> wrote:
> What about virtual hosts that may migrate from one piece of hardware to > another? Wouldn't VMs mean that you need a unique host ID separate from > hardware? Yes, that is the point. But a cloned VM would create a duplicate ID. If not for this, I would have used .etc.hostid, already. > Why not just assign sequential IDs as new hosts are created, never > duplicating them? In this sense, all hosts would be virtual, whether > actually virtual (VMs) or single host on/in a single box. Because looking up the IDs that are taken is not always feasible. With uuids, you do not have that problem. > It could be used as a database key, which links virtual hosts to what > they are running on. The database could also contain an entry for each > component that makes up a host (if you wish), e.g. brand-model-serial > for a case (e.g. what I see in front of me: HP-D6131-60200-US84700448 > [HP NetServer LPr PII/450). Newer versions of some SQL daemons offer native uuid support. Putting a description into an ID is an absolute no-go, though. You are thinking of a name, and I have a scheme for that, namely DNS. > What you are describing is just part of the larger issue of namespace > managment. Work out exactly what you want, the criteria not the method. I know what I want. A db table with proper relations that, amongst others, tracks all assets. The unique ID for running OSes is the only remaining thing I miss. Richard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]