On 09/12/2018 10:54 AM, Marcus Granado wrote:
>> Wei Liu writes ("Re: [PATCH] libxl: made vm mac address assignment
>> deterministic"):
>>> On Wed, Sep 05, 2018 at 12:25:55PM +0000, Joshua Perrett wrote:
>>> > Uses MD5 on the host mac address, vm name and vif index to generate
>>> the
>>> > last three bytes of the vm mac address (for each vm).
>>
>> There is no such thing as "the" host mac address. The host might
>> have several. However, generally there is a specific interface that
>> will be used for this guest, depending on the vif connection mode. In
>> bridge mode, for example, there is the mac address of the bridge. I
>> think you should make sure to use the right interface.
>>
>> I think you need to add something to the documentation. You should
>> mention that this approach is only deterministic *on the same host*
>> (so in setups where the guest might be started on multiple hosts, with
>> networked storage, it won't work) and only *with the same physical
>> nic* (so swapping out the physical nic will change all the guests'
>> addresses).
>
> As discussed, it looks like the use of a mac address from one of the
> host physical nics is actually a sort of fixed seed to create a
> non-changing context for the vm name and the vif index. I noticed two
> different, simpler to obtain seeds that are designed to be unique,
> non-changing values for a specific host:
>
> - systemd-based systems use /etc/machine-id as a unique
> id:https://www.freedesktop.org/software/systemd/man/machine-id.html
> - libc-based systems use gethostid() as a unique id:
> http://man7.org/linux/man-pages/man3/gethostid.3.html
>
>
> I wonder if it is sufficient for the purposes of
> https://xenproject.atlassian.net/browse/XEN-110 to create the
> non-changing seed using the following algorithm, instead of using a mac
> address:
>
> 1) if the seed is in the libxl config file, then use it. Useful to
> create a logical group of hosts sharing the same seed, so that the mac
> address won't change when vm migrates to another host in this group. Not
> to be added to the current patch being worked out, but can be easily
> added in the future.
>
> 2) if the seed is not present in the libxl config file, then use
> /etc/machine-id if present as the seed.
>
> 3) if /etc/machine-id is not present, then fall back to gethostid() as
> the seed. This call seems to be present in both linux and bsds' libc, so
> I believe this means it's always available for libxl. The reason for
> using gethostid() only as a fallback is that its man page says it
> attempts to return a unique id but it doesn't guarantee this in some
> situations.
This sounds like a good plan; unfortunately, I'm not sure gethostid() is
fit for purpose.
So it looks like the `hostid` command, part of coreutils, calls this and
returns the result [1]. I just ran `hostid` on both my desktop and
another machine under my desk, and got the same value:
---
$ hostname && hostid
elijah
007f0101
---
# hostname && hostid
immortal
007f0101
---
It looks like if /etc/hostid isn't set (which it doesn't seem to be on
three of my systems), this is actually derived from one of the host IP
addresses [2]; and in the above two cases for some reason it's picked up
127.0.1.1 as the IP address.
So although the description looks like exactly what we want, I don't
think we can rely on it to be unique.
-George
[1] https://github.com/coreutils/coreutils/blob/master/src/hostid.c
[2]
https://www.redhat.com/archives/redhat-install-list/2001-December/msg00014.html
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
