When a kubevirt OCP node is going through ignition, afterburn-hostname service is started. It writes the host short name to /sysroot/etc/hostname. Before teardown, ignition ignores propagating the hostname due to the existence of /sysroot/etc/hostname

Jan 30 15:49:20 control3.vtenant10-dev.np.k8s.l0.ms.com afterburn[1424]: Jan 30 15:49:20.776 INFO wrote hostname control3 to /sysroot/etc/hostname

Jan 30 15:49:22 control3.vtenant10-dev.np.k8s.l0.ms.com coreos-teardown-initramfs[1571]: info: hostname is defined in the real root

Jan 30 15:49:22 control3.vtenant10-dev.np.k8s.l0.ms.com coreos-teardown-initramfs[1571]: info: will not attempt to propagate initramfs hostname


This behavior is due to the addition of kubevirt to the list of platforms that afterburn-hostname service is enabled on.
https://github.com/coreos/afterburn/pull/1005/files

This was tested with OCP 4.16.25 using the following kubevirt image

RHCOS version 416.94.202410211619-0
quay.io/openshift-release-dev/ocp-v4.0-art-dev@sha256:8eb36bfb824edeaf091a039c99145721e695cabff9751412b2ff58f1351f2954

We install OCP clusters on top of OpenShift Virtualization in UPI mode with platform set to none. The image above is used for the OCP nodes and we pass in ignition via CloudInitConfigDrive similar to this
https://github.com/arvin-a/openshift-upi-automation/blob/master/src/ansible/roles/ozone-deploy-vm/templates/rhcos-vm.yaml#L88-L90

    I can reproduce this every time

    1. Install OCP in UPI mode with platform none on OpenShift Virtualization
    2. During ignition you will see the proper FQDN in the logs but it won't propagate after reboot.
    

    

    After running through ignition, all kubevirt nodes have hostname set to their shortname

    After running through ignition, all kubevirt nodes should have hostname set to the host's FQDN