Description of problem: When a template is created with option "seal template" from a VM Snapshot. Specific VM information is not removed. A new VM created from same template copies the Hostname & IP address of Original VM. Version-Release number of selected component (if applicable): RHV 4.3.10 How reproducible: 100% Steps to Reproduce: 1. Create a template from VM snapshot with option "seal template" 2. Create a new VM from same template and check for Hostname & Ip information. Actual results: Hostname & IP address of Original VM are retained on new VM. Expected results: Specific information from Original VM should be removed Additional info: We see no errors in logs for seal template attempt. Seal template completes successfully but the VM specific information is not removed.
Richard, 1. Can it be that virt-sysprep doesn't default the hostname to localhost.localdomain anymore and we need to specify it explicitly? 2. As for the IP, we only clear the MAC address AFAIK (which indeed changes), so it's possible for the VM to be assigned with the same IP, right?
How was the hostname determined? from the network? set within the guest? How was the IP address determined? statically? DHCP?
Virt-sysprep never set the hostname to localhost.localdomain (or any other default). What it actually does it to remove the hostname from some configuration files, removing HOSTNAME= and DHCP_HOSTNAME= entries from /etc/sysconfig/network-scripts/ifcfg-* files. Since it's very unlikely that modern guests would be using these files, this likely does nothing at all. But also you can specify the optional --hostname parameter to virt-sysprep which will set the hostname of the guest to a specific string, usually by modifying /etc/hostname, /etc/sysconfig/network, the Windows Registry, etc. Would need to see the full virt-sysprep log to say more.
Code is here: (1) Removing the hostname from ifcfg files: https://github.com/libguestfs/libguestfs/blob/master/sysprep/sysprep_operation_net_hostname.ml (2) Removing MAC address from ifcfg files: https://github.com/libguestfs/libguestfs/blob/master/sysprep/sysprep_operation_net_hwaddr.ml (3) Setting the hostname from the optional --hostname parameter: https://github.com/libguestfs/libguestfs/blob/master/customize/hostname.ml
Thanks Richard, the reason for asking that about the hostname was a quick look at [1] (the "If not given, defaults to "localhost.localdomain" part). Setting back the needinfo as per comment 3. Please also provide the virt-sysprep log. [1] https://linux.die.net/man/1/virt-sysprep
That copy of the man page is very old - 2011 :-) I can't actually remember if virt-sysprep did ever set the hostname to localhost.localdomain, and git history isn't helping me right now. But I think most likely is that copy of the man page is simply wrong. The latest version doesn't mention localhost.localdomain: http://libguestfs.org/virt-sysprep.1.html
Oh I see, it was a possibly unintentional change in behaviour (but still an improvement, not a bug) in this 2014 commit: https://github.com/libguestfs/libguestfs/commit/ae6f726ecc3bc1b67fd76e51a7b1e1a33d4dcfc0
Ack, if that's something that may have changed back in 2014 then it's unlikely to be the root cause of this since we started to use virt-sysprep in ovirt in 2017
As already mentioned the hostname is not reset. But we could run virt-sysprep with '--hostname localhost' to set it to some default value. I was also able to reproduce the issue with IP being reused, but it does not happen every time. This happens even when the MAC is different. It is possible the DHCP leases were not cleared properly, but I don't have logs from virt-sysprep anymore. I will run some more test to reproduce it again.
(In reply to Tomáš Golembiovský from comment #16) > As already mentioned the hostname is not reset. But we could run > virt-sysprep with '--hostname localhost' to set it to some default value. Yeah, specifying '--hostname localhost' to virt-sysprep so users won't end up with the hostname of the original VM in case they don't configure it with cloud-init/sysprep makes sense to me. > I was also able to reproduce the issue with IP being reused, but it does not > happen every time. This happens even when the MAC is different. It is > possible the DHCP leases were not cleared properly, but I don't have logs > from virt-sysprep anymore. I will run some more test to reproduce it again. Interesting, yeah, let's see if we can nail down the reason for this
Since we cannot reproduce the IP issue and we don't have enough information to pin-point where the problem could be I suggest to leave the bug only for the hostname issue. If the IP issue can still be reproduced by the customer or anyone else I suggest to open a new bug with proper information. Notably we need to know: - information on the VM used as a source for template -- does it still exist in the environment or was it removed after creating template? what are/were the MAC addresses? - information on the new VM -- what are the MAC addresses? - what is the network & dhcp configuration in the guest? - what is the configuration of DHCP server in the network? - logs for virt-sysprep -- we made it easier to get those, they are now stored in /var/log/vdsm/commands (bug 1895843) - is cloud-init involved in any way?
As part of the fix we also added --selinux-relabel to enforce relabeling of the files because the context on some files may be wrong after after running virt-sysprep. Notably on files that did not exist in the guest before and were created by virt-sysprep. I am quite surprised this went so long without us noticing. The downside to this is that the first boot of new VMs created from sealed templates will take little bit longer.
For many guests, --selinux-relabel is able to the relabelling at the time (using setfiles). The relabelling is only done at boot in some cases where the guest/host is incompatible.
Thanks for the clarification.
Verified with: vdsm-4.40.50.5-1.el8ev.x86_64 ovirt-engine-4.4.5.5-0.13.el8ev.noarch Steps: 1. Create a VM from template RHEL8.3, run vm and set hostname, # hostnamectl set-hostname seal.testing.com 2. Create a snapshot. 3. Create a sealed template from the snapshot. 4. Create a new VM from the sealed template, check hostname. Results: The new VM created from the sealed template gets a new hostname. On original VM: # hostname seal.testing.com On new VM: # hostname vm-30-109.qa.lab.tlv.redhat.com # ls -Z /etc/machine-info system_u:object_r:hostname_etc_t:s0 /etc/machine-info
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory (Moderate: RHV RHEL Host (ovirt-host) 4.4.z [ovirt-4.4.5] security, bug fix, enhancement), and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHSA-2021:1184
Due to QE capacity, we are not going to cover this issue in our automation