Can you share your /etc/hosts. As far as I remember there was an entry like: 127.0.1.2 hostname So you have to comment it out. Best Regards, Strahil Nikolov На 16 юли 2020 г. 16:53:36 GMT+03:00, Florian Schmid via Users <users(a)ovirt.org&gt; написа: >Hi, > >I have a problem with Ubuntu 20.04 VM reporting the correct FQDN to the >engine. >Starting with this release, the ovirt-guest-agent is not available >anymore. > >Therefore, I have installed qemu-geust-agent with package defaults. > >Now in the Engine, I only see the hostname under FQDN tab, instead the >real full name with domain. > >I'm running an oVirt environment on 4.3.8. > >The VM is resolveable, forward and reverse DNS entries are working. >hostname -f shows the correct FQDN. > >Even adding IP and FQDN to /etc/hosts file doesn't change anything. > >qemu-guest-agent version: 4.2-3ubuntu6.3 > >I manage this VM via ansible 2.9 and ansible is able to get the FQDN of >the VM without any issues... > >What can I do here to debug my issue? >Does the engine cache the wrong result? Even after stopping and >starting the VM again, engine is only showing the hostname instead of >the FQDN. > >Best regards, >Florian >_______________________________________________ >Users mailing list -- users(a)ovirt.org >To unsubscribe send an email to users-leave(a)ovirt.org >Privacy Statement: https://www.ovirt.org/privacy-policy.html >oVirt Code of Conduct: >https://www.ovirt.org/community/about/community-guidelines/ >List Archives: >https://lists.ovirt.org/archives/list/users@ovirt.org/message/BGGFBU24SQAJICU5OR7VOZLBQUZ3CWNJ/

Il giorno gio 16 lug 2020 alle ore 15:55 Florian Schmid via Users < users(a)ovirt.org&gt; ha scritto: +Tomas Golembiovsky <tgolembi(a)redhat.com&gt; can you help here? -- Sandro Bonazzola MANAGER, SOFTWARE ENGINEERING, EMEA R&D RHV Red Hat EMEA <https://www.redhat.com/> sbonazzo(a)redhat.com <https://www.redhat.com/> *Red Hat respects your work life balance. Therefore there is no need to answer this email out of your office hours. <https://mojo.redhat.com/docs/DOC-1199578>*

Hi, after digging a bit deeper, it looks like it is the problem with the qemu-guest-agent. It does only report the hostname and nothing more. It uses this function: g_get_host_name () This function always returns the value in /etc/hostname and this is normally the short name of the VM without the domain part. It looks like, that the ovirt-guest-agent made this different, but this is not working anymore with python 3. There was a recent patch for qga -> [ https://bugzilla.redhat.com/show_bug.cgi?id=1845127 | https://bugzilla.redhat.com/show_bug.cgi?id=1845127 ] but this won't help me, because even when this patch would add the FQDN to oVirt back, there won't be a package for this for Ubuntu 20.04 and probably also not for RedHat/CentOS 8. BR Florian Von: "users" <users(a)ovirt.org&gt; An: "Sandro Bonazzola" <sbonazzo(a)redhat.com&gt; CC: "users" <users(a)ovirt.org&gt; Gesendet: Montag, 20. Juli 2020 09:06:30 Betreff: [ovirt-users] Re: qemu-guest-agent on Ubuntu doesn't report FQDN Hi, when setting hostnamectl set-hostname "FQDN", then engine will report the real and correct "FQDN", but this is not a good fix. With our older Debian and Ubuntu VMs, it is working correctly, although hostname is only reporting the short hostname. hostname -f is reporting here the correct FQDN. BR Florian -------------------------------------------------------------------------------------------------------------------- UBIMET GmbH - weather matters Ing. Florian Schmid • IT Infrastruktur Austria A-1220 Wien • Donau-City-Straße 11 • Tel +43 1 263 11 22 DW 469 • Fax +43 1 263 11 22 219 fschmid(a)ubimet.com • www.ubimet.com • Mobile: +43 664 8323379 Sitz: Wien • Firmenbuchgericht: Handelsgericht Wien • FN 248415 t -------------------------------------------------------------------------------------------------------------------- The information contained in this message (including any attachments) is confidential and may be legally privileged or otherwise protected from disclosure. This message is intended solely for the addressee(s). If you are not the intended recipient, please notify the sender by return e-mail and delete this message from your system. Any unauthorized use, reproduction, or dissemination of this message is strictly prohibited. Please note that e-mails are susceptible to change. UBIMET GmbH shall not be liable for the improper or incomplete transmission of the information contained in this communication, nor shall it be liable for any delay in its receipt. UBIMET GmbH accepts no liability for loss or damage caused by software viruses and you are advised to carry out a virus check on any attachments contained in this message. Von: "Sandro Bonazzola" <sbonazzo(a)redhat.com&gt; An: "Florian Schmid" <fschmid(a)ubimet.com&gt;, "Tomas Golembiovsky" <tgolembi(a)redhat.com&gt; CC: "users" <users(a)ovirt.org&gt; Gesendet: Freitag, 17. Juli 2020 09:21:37 Betreff: Re: [ovirt-users] qemu-guest-agent on Ubuntu doesn't report FQDN Il giorno gio 16 lug 2020 alle ore 15:55 Florian Schmid via Users < [ mailto:users@ovirt.org | users(a)ovirt.org ] > ha scritto: Hi, I have a problem with Ubuntu 20.04 VM reporting the correct FQDN to the engine. Starting with this release, the ovirt-guest-agent is not available anymore. Therefore, I have installed qemu-geust-agent with package defaults. Now in the Engine, I only see the hostname under FQDN tab, instead the real full name with domain. I'm running an oVirt environment on 4.3.8. The VM is resolveable, forward and reverse DNS entries are working. hostname -f shows the correct FQDN. Even adding IP and FQDN to /etc/hosts file doesn't change anything. qemu-guest-agent version: 4.2-3ubuntu6.3 I manage this VM via ansible 2.9 and ansible is able to get the FQDN of the VM without any issues... What can I do here to debug my issue? Does the engine cache the wrong result? Even after stopping and starting the VM again, engine is only showing the hostname instead of the FQDN. [ mailto:tgolembi@redhat.com | +Tomas Golembiovsky ] can you help here? BQ_BEGIN Best regards, Florian _______________________________________________ Users mailing list -- [ mailto:users@ovirt.org | users(a)ovirt.org ] To unsubscribe send an email to [ mailto:users-leave@ovirt.org | users-leave(a)ovirt.org ] Privacy Statement: [ https://www.ovirt.org/privacy-policy.html | https://www.ovirt.org/privacy-policy.html ] oVirt Code of Conduct: [ https://www.ovirt.org/community/about/community-guidelines/ | https://www.ovirt.org/community/about/community-guidelines/ ] List Archives: [ https://lists.ovirt.org/archives/list/users@ovirt.org/message/BGGFBU24SQA... | https://lists.ovirt.org/archives/list/users@ovirt.org/message/BGGFBU24SQA... ] BQ_END -- Sandro Bonazzola MANAGER, SOFTWARE ENGINEERING, EMEA R&D RHV [ https://www.redhat.com/ | Red Hat EMEA ] [ mailto:sbonazzo@redhat.com | sbonazzo(a)redhat.com ] [ https://www.redhat.com/ ] [ https://mojo.redhat.com/docs/DOC-1199578 | Red Hat respects your work life balance. Therefore there is no need to answer this email out of your office hours. ] _______________________________________________ Users mailing list -- users(a)ovirt.org To unsubscribe send an email to users-leave(a)ovirt.org Privacy Statement: https://www.ovirt.org/privacy-policy.html oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/message/7WNIFONNDBB...

On Wed, Jul 22, 2020 at 5:34 PM Florian Schmid via Users <users(a)ovirt.org&gt; wrote: Indeed, and from checking the git log, it seems like it did this since the very first commit - already then, ovirt-guest-agent/GuestAgentLinux2.py had: def getMachineName(self): return socket.getfqdn() If in "this" you refer to ovirt-guest-agent, then it's deprecated: https://bugzilla.redhat.com/show_bug.cgi?id=1672732 This bug seems to discuss something else, not directly related to your own issue. Not sure what you mean here. The bug is on qga, and fixing it (or your own issue) is unrelated to oga's deprecation. Your issue seems to be, to me: 1. oga used to report the FQDN, as returned by python's socket.getfqdn() 2. qga returns something else (and this something else might be changed, following above bug, but likely not to what you want). 3. oVirt now uses qga instead of oga, thus changing its past behavior. 4. You want the old behavior back - basically, claiming this is a regression. If so, then: 1. You are welcome to open a bug about this, on qga. 2. Your request *might* be rejected, on the ground of breaking compatibility for existing/old users of qga (say, using virt-manager or whatever other virt tool, without oga installed) Alternatively, or if this bug is rejected, you can open two new bugs: 1. one on qga, to provide the fqdn (using, hopefully, logic similar to python's getfqdn, although qga is written in C) 2. other on the oVirt engine, to use this new functionality of qga instead of the existing one. You also have another alternative - just adapt your machines to have the fqdn as the hostname. I personally think this is the best way to go. Have 'hostname' return the FQDN you want, and only use 'hostname -s' where you really want it to be short. How do you set the hostnames of your machines? Best regards, -- Didi

On Thu, Jul 23, 2020 at 10:23 AM Florian Schmid <fschmid(a)ubimet.com&gt; wrote: I use this on all my machines (CentOS/RHEL ones, anyway) and all seems ok. I do recommend, obviously, that you do your own research/testing. The only actual drawback I can think of is that the hostname is limited to 64 chars, whereas the FQDN can be up to 255 chars. So if you want a longer FQDN, you can't use it as the hostname. Another obvious drawback is that applications that use the full hostname for reporting, as opposed to explicitly using 'hostname -s', will now have the FQDN in their reports, which you might find too long etc. I personally consider this an advantage, not a drawback. Memory and disk space are cheap these days, but time is still expensive - if you get a report about "servera" instead of "servera.somedomain" and it causes you to spend time understanding what server this is, it's more waste, IMO, than having "servera.somedomain" everywhere. But that's obviously a personal matter... Best regards, -- Didi