Created attachment 1543517 [details] fedora.yaml Description of problem: Create a VM with a hostname in the cloud-init section, once it's running, check the VM FQDN on overview page, the FQDN is the VM's name which is provided on UI, but not the hostname of the VM. Version-Release number of selected component (if applicable): kubevirt-web-ui:v1.4.0-14.1 How reproducible: Steps to Reproduce: 1. create a vm with a hostname in cloud-init. 2. start the vm 3. check vm FQDN on vm overview page Actual results: The FQDN is not the hostname. Expected results: The FQDN should be the vm's hostname. Additional info: The vm yaml is attached.
Can you please also provide the vmi and the launcher pod yamls?
Created attachment 1545863 [details] fedora-pod.yaml
Created attachment 1545864 [details] fedora-vmi.yaml The pod and vmi yaml are attached now.
ok, first of all we should probably not call it in UI "fqdn" since it actually is "hostname". But anyway, it looks like the hostname is not reported by the backend correctly. @Fabian: any idea why is the hostname not reported correctly?
Yes, it can only be about hostname, not FQDN. FQDN is a cluster assigned attribute. cloud-init is a best effort, we cna not know ahead of time if it will be effective or not. There is no paste or screenshot here which actually shows the UI contents. Thus I don't know what's shown there. I also don't know what the UI is using to determine the hostname of the VM. Today VMI.spec.hostname and cloud-init hostname are overlapping. The best way to set a hostname is to use VMI.spec.hstname https://kubevirt.io/api-reference/v0.15.0/definitions.html#_v1_virtualmachineinstancespec
@Fabian, thank you for the quick answer, some more clarifications, questions: 1: In VM the object the cloud init sets the hostname to "test.example.com". That is what would we like to see in the UI. Instead we see "fedora". 2: We are using the pod.spec.hostname which in this case has the value: fedora. Should we not use that one? 3: There is no "hostname" field in "vmi" (at least in this case). Why would that be?
> @Fabian, thank you for the quick answer, some more clarifications, questions: This answer is quicker! > 1: In VM the object the cloud init sets the hostname to "test.example.com". That is what would we like to see in the UI. Instead we see "fedora". Right. understood. But that can not be achieved from the KubeVirt VM API, as cloud-init is a best effort. Also, setting an FQDN should not be possible, as this does not necessarily man that the fqdn is reachable from outside of the vmi. > 2: We are using the pod.spec.hostname which in this case has the value: fedora. Should we not use that one? Yes > 3: There is no "hostname" field in "vmi" (at least in this case). Why would that be? VMI.spec.hostname, check this link (as in my previous comment) https://kubevirt.io/api-reference/v0.15.0/definitions.html#_v1_virtualmachineinstancespec
(In reply to Fabian Deutsch from comment #7) > > @Fabian, thank you for the quick answer, some more clarifications, questions: > > This answer is quicker! we are on fire today! > > > 1: In VM the object the cloud init sets the hostname to "test.example.com". That is what would we like to see in the UI. Instead we see "fedora". > > Right. understood. But that can not be achieved from the KubeVirt VM API, as > cloud-init is a best effort. > Also, setting an FQDN should not be possible, as this does not necessarily > man that the fqdn is reachable from outside of the vmi. understood, will rename to hostname. > > > 2: We are using the pod.spec.hostname which in this case has the value: fedora. Should we not use that one? > > Yes > > > 3: There is no "hostname" field in "vmi" (at least in this case). Why would that be? > > VMI.spec.hostname, check this link (as in my previous comment) > https://kubevirt.io/api-reference/v0.15.0/definitions. > html#_v1_virtualmachineinstancespec I did... To summarize: would the correct solution be to have a label called "hostname" and a value either the value of "vmi.spec.hostname" or "---" when the "hostname" is missing from the vmi.spec.hostname? e.g. given the example of the yamls in this BZ, we would show "---".
>To summarize: would the correct solution be to have a label called "hostname" and a value either the value of "vmi.spec.hostname" or "---" when the "hostname" is missing from the vmi.spec.hostname? e.g. given the example of the yamls in this BZ, we would show "---". Yes, a UI field should set vmi.spec.hostname, and it can show whatever the UI shows if this field is emtpy.
To make it very exact: 1: rename the "fqdn" to "hostname" UI 2: in new VM, if the cloud init is not used, set the VM's name into the vmi.spec.hostname 3: in new VM, if the cloud init is used, set the cloud-init hostname into the vmi.spec.hostname 4: show the vmi.spec.hostname as the VM's hostname, if it is set 5: show "---" if the vmi.spec.hostname is not set
When I create the VM from YAML provided in attachments (which has hostname 'test.example.com' specified in cloud init), the vmi.spec.hostname is set to 'fedora' instead of 'test.example.com'. Additionally, the VM Overview page displays dashes (---) instead of the value specified in vmi.spec.hostname. Version: 2.0.0-14.5 Moving back to assigned.
@rhrazdil, Create vm from cli, it will not set "spec.template.spec.hostname", so it's "---" on vm overview. Create vm from UI will set 'spec.template.spec.hostname', however, there is a new bug https://bugzilla.redhat.com/show_bug.cgi?id=1712725.
@gouyang I'm not sure about 'spec.template.spec.hostname', Comment 10 mentions spec.hostname on VMI, and it does have a value set. Therefore, according to Comment 10 number 4, it should be shown as VM hostname.
@rhrazdil I didn't see vmi.spec.hostname is set when create the fedora vm from the attachment yaml. Create vm from yaml will not set that field unless you use the wizard.
@guohua I see! I got confused with what is in the virt-launcher Pod and the VirtualMachineInstance manifest. With this cleared up, I believe there is nothing blocking us from moving this one to verified. version 2.0.0-15.5
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, 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/RHEA-2019:1850