Documentation survey

Troubleshooting Registering Cloned Clients

If you are using SUSE Multi-Linux Manager to manage virtual machines, you might find it useful to create clones of your VMs. A clone is a VM that uses a primary disk that is an exact copy of an existing disk.

While cloning VMs can save you a lot of time, the duplicated identifying information on the disk can sometimes cause problems.

If you have a client that is already registered, you create a clone of that client, and then try and register the clone, you probably want SUSE Multi-Linux Manager to register them as two separate clients. However, if the machine ID in both the original client and the clone is the same, SUSE Multi-Linux Manager registers both clients as one system, and the existing client data is overwritten with that of the clone.

This can be resolved by changing the machine ID of the clone, so that SUSE Multi-Linux Manager recognizes them as two different clients.

Each step of this procedure is performed on the cloned client. This procedure does not manipulate the original client, which remains registered to SUSE Multi-Linux Manager.
Procedure: Resolving Duplicate Machine IDs in Cloned Salt Clients

  1. Initial System Configuration

  2. On the cloned machine, change the hostname and IP addresses. Make sure /etc/hosts contains the changes you made and the correct host entries.

  3. Resolving Duplicate Machine IDs

  4. For distributions that support systemd: If your machines have the same machine ID, as root, delete the files on each duplicated client and re-create it:

    rm /etc/machine-id
rm /var/lib/dbus/machine-id
rm /var/lib/zypp/AnonymousUniqueId
dbus-uuidgen --ensure
systemd-machine-id-setup

  5. If the cloned machine also has a folder in /var/log/journal/ it needs to be renamed accordingly to the new machine ID. If names do not match, journalctl could not retrieve any log and podman logs would not show anything.

    mv /var/log/journal/* /var/log/journal/$(cat /etc/machine-id)

  6. For distributions that do not support systemd: As root, generate a machine ID from dbus:

    rm /var/lib/dbus/machine-id
rm /var/lib/zypp/AnonymousUniqueId
dbus-uuidgen --ensure

  7. Fixing Kernel Entries on Red Hat Enterprise Linux 8.10

  8. If you are cloning a Red Hat Enterprise Linux 8.10 server that will later be liberated to SUSE Liberty Linux, you must perform extra steps to fix the kernel configuration files.

    Red Hat Enterprise Linux uses the machine ID to generate kernel entries in /boot/loader/entries. Not performing these steps will result in a mix of old and new kernel entries after the liberation, as SUSE Liberty Linux kernels will create new entries instead of replacing the old ones.

  9. After changing the machine ID and before liberating, run:

    sudo rm -rf /boot/loader/entries/
sudo  for ver in $(rpm -q kernel --qf '%{VERSION}-%{RELEASE}.%{ARCH}\n'); do echo "Reinstalling kernel $ver..."; sudo kernel-install add $ver /lib/modules/$ver; done
sudo grub2-mkconfig -o /boot/efi/EFI/redhat/grub.cfg

    For more information and example on liberating Red Hat Enterprise Linux 8.10 server, see Liberate Red Hat Enterprise Linux 8.10 with secureboot.

  10. Reconfiguring Salt Clients

  11. If your clients still have the same Salt client ID, delete the minion_id file on each client (FQDN is used when it is regenerated on client restart). For Salt Minion clients:

    rm /etc/salt/minion_id
rm -rf /etc/salt/pki

    For Salt Bundle clients:

    rm /etc/venv-salt-minion/minion_id
rm -rf /etc/venv-salt-minion/pki

  12. Delete accepted keys from the onboarding page and the system profile from SUSE Multi-Linux Manager, and restart the client with. For Salt Minion clients:

    service salt-minion restart

    For Salt Bundle clients:

    service venv-salt-minion restart

  13. Re-register the clients. Each client now has a different /etc/machine-id and should be correctly displayed on the System Overview page.