Hi Silvio
Thanks for this - this does indeed look to be the core of the issue;
machine1# cat /etc/machine-id
57dcc3a1bbed44f6a97dc4c8058eb4d3
machine2# cat /etc/machine-id
57dcc3a1bbed44f6a97dc4c8058eb4d3
I don't know the history of these machines, but cloning does seem possible. Both machine co-existed on Spacewalk okay, but of course they used osad and rhnsd which presumably don't care about this value.
Thanks to you and Robert for your help - I think I'm good to take it on from here.
Regards
S
-----Original Message-----
From: Silvio Moioli
I'm puzzled - how could both machines get the same ID? Surely Uyuni issues it to the client during the bootstrap process?
The machine-id is a unique identifier that comes either from hardware, or from your virtualization software, or in worst case randomly generated - but it should really be unique. Uyuni does _not_ set it, rather it uses it to determine if a client is the same of another that's already registered or not (despite possible changes in hostname, IP addresses and so on). Note that the machine-id is very different from the minion key, or the name that you see in the Uyuni Web UI! You can learn more about machine-id here: https://www.man7.org/linux/man-pages/man5/machine-id.5.html It is a requirement that any Uyuni client has a unique and fixed machine-id. Note that if you clone VMs the machine-id might be cloned as well, so you need to change it. https://www.uyuni-project.org/uyuni-docs/uyuni/administration/tshoot-registe... HTH Regards, -- Silvio Moioli SUSE Manager Development Team -- To unsubscribe, e-mail: uyuni-users+unsubscribe@opensuse.org To contact the owner, e-mail: uyuni-users+owner@opensuse.org