Randy Bias <randyb@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.