[occi-wg] [OFF TOPIC] Re: Instance runtime API

[Chris Webb]

Randy Bias <randyb at gogrid.com> writes:

> Alternative is to say that Œmachine-id¹ is always deposited in / or C:\ and
> has UUID.

This is straying away from API territory into mechanism, but it's quite
interesting so...

If you're doing hardware virtualisation, you can always pass the machine
UUID in through the SMBIOS UUID without breaking the abstraction layers.
This is what we do with Qemu/KVM, and Google suggests an identical option is
available with VMware ESX. I don't know what the analogue is for Xen. It has
the advantage that the guest doesn't need to have network interfaces
attached to know its own identity.

Another possibility is to use a DHCP option if you're happy with a guest
needing networking to be able to find out about itself.

However, fiddling with the filesystem of a guest as it boots is not so
appealing in reality. Quite apart from the layering violation, it assumes:

  - the root filesystem is mounted by exactly one guest;
  - the host understands which filesystem is the root and can correctly
    unpick containers like LVM, RAID and encryption;
  - the host can correctly detect and understand the filesystem itself
    (Solaris ZFS on a Linux host? ADFS on anything modern?);
  - the filesystem is of a type that can be meaningfully be written to
    (CramFS root? NFS root for that matter?).

For each of the above assumptions, I can think of at least one customer on
our cluster who violates it. (I'd love to say we have at least one client
running an OS without a notion of filesystem at all, but sadly that isn't
true yet as far as I know.)

Cheers,

Chris.