On 07/25/2011 01:20 AM, Andrew Beekhof wrote:
On Sat, Jul 23, 2011 at 2:40 AM, Mark McLoughlin
> Hi Andrew,
> On Fri, 2011-07-22 at 08:19 +1000, Andrew Beekhof wrote:
>> Are there any conditions under which /etc/machine-id would get
>> regenerated? If so that would rule it out.
>> These were my initial thoughts:
>> Immutable: /etc/machine-id (systemd)
On reflection, I think Filesystem might be a better label for this scope.
>> Hardware: ? Something on top of the smbios API
>> Reboot: ? /var/lib/dbus/machine-id (dbus)
>> Agent: In memory using the libuuid API
>> User: /etc/custom-machine-id
> Okay, AIUI it (and I've take a quick look to confirm),
> both /etc/machine-id and /var/lib/dbus/machine-id are basically
> equivalent concepts
> They are both a UUID that should be generated when the machine is
> installed or booted for the first time and not change thereafter.
Ok, so it looks like the dbus uuid is of no use for the reboot scope
and needs to be substituted with something else.
I suspected as much - which is why I put a '?' in front of it.
Taking a step back here, what is the point of 'reboot scope' uuid anyhow?
I suspect the simplest path forward is to put something generated by
libuuid into /var/run/matahari-reboot-id
> Looking at the code, I think dbus and systemd make an effort to have
> these UUIDs be identical, but I'm not 100% sure. Hmm, I just checked an
> F-16 machine and the two UUIDs are different.
It seems that on a fresh install of F15 or rawhide the id's will not be
the same. But when I upgraded an F14 machine to F15 because the
/var/lib/dbus/machine-id already existed prior to systemd being
installed they ended up being the same
I wonder if this is just an oversight or if it's intentional on F15
fresh installs that they're different... yaay uuid proliferation <sigh>
> The reference you've probably seen in the dbus docs to the
> on reboot only applies to stateless systems - the UUID is stored on a
> part of the filesystem which may not persist across reboots. That could
> equally apply to /etc/machine-id too.
Based on your summary at the end I think we're arguing the same thing,
but clearly in order to have a persistent UUID you need to have access
to persistent storage. If we don't have that, we can't use that kind
of UUID. End of story.
There's a bit of confusion here. Guests in the cloud that _are
persistent_ have access to persistent storage. However, there are a lot
of instances where the guests literally evaporate on reboot. In that
case, the lifetime of a particular guest (and therefore it's UUID) can
and should be limited to a single boot, no?
If people don't want to pre-configure something, then a hardware
(either read from the hardware or generated based on what is
installed) is really the only option.
I'm quite happy to have Matahari's 'Hardware' UUID use smbios if
available* and do something with MAC addresses (and/or some other
hardware identifier) if smbios is empty/unavailable.
* From what I can tell, RHEV, VMware and EC2 all support smbios...
anyone who doesn't?
Greg, do you know?
> In VM disk images, both of these UUIDs should be deleted so that they
> are generated when a new VM is booted from the image. Similar to what is
> done for host SSH keys.
> On the RHEV-M side, there's a UUID in SMBIOS that has nothing to do with
> dbus or systemd. This UUID corresponds to the instance ID you'd see in
> the deltacloud API.
> When you launch a deployable, you'll get the list of deltacloud instance
> IDs back. I'm guessing you want Matahari to reliably report this UUID
> back as a "system hardware UUID"?
I did list smbios as an option for the Hardware UUID but not because
it has anything to do with deployables.
Matahari is not a cloud-specific project.
> In that case, the answer when running under RHEV-M is to read the UUID
> from SMBIOS.
> Under EC2, you get the ID from:
> and this isn't a UUID at all. I'm not sure about other clouds.
As long as its unique, Matahari doesn't care which uuid format (if any) its in.
> Now, config server seems to have its notion of a machine UUID. This is
> passed to the instance at launch time and the audrey startup script has
> logic to find it. The idea is that this is supplied to config server by
> whatever is launching the instance. I'm not sure why this wouldn't also
> be the deltacloud ID.
> - For the HA stuff, I think you need Matahari to be able to reliably
> report the deltacloud instance ID a "system hardware ID" or similar
You basically mean something persistent right?
Matahari isn't going to have a notion of a deltacloud ID, but if
deltacloud arranges for its ID to be available (either via something
like smbios or but pre-populating a known file on disk), then Matahari
will happily return it.
> - That's unrelated to the systemd and dbus IDs, but these IDs should
> be unique to each machine too.
> - You should be able to determine the deltacloud instance ID from
> inside each VM.
> - This deltacloud instance ID should be what Audrey is using when
> contacting config server.
> - Audrey and Matahari should have the same logic for figuring this ID
Sooo... Where did we end up here?
Filesystem: /etc/machine-id (systemd) falling back to /var/lib
/dbus/machine-id for pre-systemd guests
(persistent as long as the root filesystem is persistent)
Hardware: provided by either bare metal hardware, or by the cloud
platform (EC2, RHEV, VMware) via smbios
Agent: Generated by libuuid when each agent starts and exists only
for the duration of that agent (disappears on agent restart)
User: Location of this is tbd, but could be smth like