[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH] libxl: made vm mac address assignment deterministic
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@xxxxxxxxxxxxxxxxxxxx https://lists.xenproject.org/mailman/listinfo/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |