RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1891923 - qga could not get new host name after guest set a new name
Summary: qga could not get new host name after guest set a new name
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: qemu-kvm
Version: 8.3
Hardware: ppc64le
OS: Linux
medium
medium
Target Milestone: rc
: 8.4
Assignee: Virtualization Maintenance
QA Contact: bfu
URL:
Whiteboard:
Depends On: 1845127
Blocks:
TreeView+ depends on / blocked
 
Reported: 2020-10-27 17:04 UTC by bfu
Modified: 2021-01-27 03:16 UTC (History)
13 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-11-30 04:32:55 UTC
Type: ---
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)

Description bfu 2020-10-27 17:04:44 UTC 
Description of problem:
after set a new hostname through guest with cmd:"hostnamectl set-hostname newhostname", could only show old name through qemu_guest_agent socket
/home/bfu/Documents/test_data/testresults/autobugs/guest_agent/39-Host_RHEL.m8.u3.product_rhel.qcow2.virtio_scsi.up.virtio_net.Guest.RHEL.8.3.0.ppc64le.io-github-autotest-qemu.qemu_guest_agent.virtio_serial.check_os_basic_info/debug.log

Version-Release number of selected component (if applicable):
host kernel version:4.18.0-240.el8.ppc64le
guest kernel version:4.18.0-240.el8.ppc64le
qemu version:qemu-img-5.1.0-14.module+el8.3.0+8438+644aff69.ppc64le

How reproducible:
100%

Steps to Reproduce:
1.boot up guest with:
/usr/libexec/qemu-kvm \
    -name 'vm1'  \
    -sandbox on  \
    -machine pseries,cap-ccf-assist=off  \
    -nodefaults \
    -device VGA,bus=pci.0,addr=0x2 \
    -m 4G,slots=4,maxmem=8G \
    -smp 8,maxcpus=8,cores=4,threads=1,sockets=2  \
    -cpu 'host' \
    -chardev socket,id=chardev_serial0,server,path=/tmp/bfu,nowait \
    -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x7,iommu_platform=on,disable-legacy=on,disable-modern=off \
    -chardev socket,path=/tmp/qga.sock,server,nowait,id=qga0 \
    -device virtserialport,bus=virtio-serial0.0,chardev=qga0,name=org.qemu.guest_agent.0 \
    -device spapr-vty,id=serial0,reg=0x30000000,chardev=chardev_serial0 \
    -device qemu-xhci,id=usb1,bus=pci.0,addr=0x6 \
    -device virtio-scsi-pci,id=virtio_scsi_pci0,bus=pci.0,addr=0x9 \
    -blockdev node-name=file_image1,driver=file,aio=threads,filename=rhel8301009.qcow2,cache.direct=off,cache.no-flush=on \
    -blockdev node-name=drive_image1,driver=qcow2,cache.direct=off,cache.no-flush=on,file=file_image1 \
    -device scsi-hd,id=image1,drive=drive_image1,write-cache=on \
    -device virtio-net-pci,mac=9a:f3:34:18:4d:a4,id=idxUm7Mp,netdev=idgKDzyu,bus=pci.0,addr=0x8  \
    -netdev tap,id=idgKDzyu,vhost=on \
    -device usb-tablet,id=usb-tablet1,bus=usb1.0,port=1  \
    -device usb-kbd,id=usb-kbdppc1,bus=usb1.0,port=2  \
    -vnc :32  \
    -qmp tcp:0:4444,server,nowait \
    -rtc base=utc,clock=host  \
    -boot menu=off,order=cdn,once=c,strict=off  \
    -enable-kvm \
    -monitor stdio \

2.set host name and check if it works through guest with:
hostnamectl set-hostname newhostname && cat /etc/hostname

3.check host name through qga socket with:
{"execute":"guest-get-host-name"} 

Actual results:
from qga: dhcp16-215-195.ibm2.lab.eng.bos.redhat.com

Expected results:
from qga:newhostname

Additional info:
Comment 1 bfu 2020-10-28 02:47:43 UTC 
@demeng , hi dehan, does x86 also have this bug?
Comment 2 dehanmeng 2020-10-28 02:52:30 UTC 
(In reply to bfu from comment #1)
> @demeng , hi dehan, does x86 also have this bug?

We hit it before as Bug-1845127, but it has been fixed and automated yet.
Comment 3 David Gibson 2020-10-28 03:40:50 UTC 
It's a bit hard to see what could be arch-specific about the fix for bug 1845127.
Comment 4 bfu 2020-10-28 10:58:11 UTC 
Hi david,
this bug also occurred with qemu_version:qemu-kvm-4.2.0-34.module+el8.3.0+7976+077be4ec.ppc64le, so this seems not a regression bug
Comment 5 Daniel Henrique Barboza (IBM) 2020-11-12 15:33:22 UTC 
The only way I can reproduce this bug is when I don't update the guest QGA to
the 5.1 version. Which makes sense, given that the fix was in QGA code.

bfu, can you please check the qemu-ga version you're using? I was using:

[root@localhost ~]# /usr/bin/qemu-ga --version
QEMU Guest Agent 4.2.0


And I got the exact behavior you described. When I updated the qemu-guest-agent
package - inside the guest - to the RHEL-AV version, the bug didn't occur:

# qemu-ga --version
QEMU Guest Agent 5.1.0

This is a series of commands changing the hostname in the guest:

[root@newhostname ~]# hostnamectl set-hostname newhostname && cat /etc/hostname
newhostname
[root@newhostname ~]# hostnamectl set-hostname newhostname2 && cat /etc/hostname 
newhostname2
[root@newhostname ~]# hostnamectl set-hostname newhostname-qga5.1


This is the output from the QGA socket:

[danielhb@ltc-boston115 ~]$ sudo nc -U /tmp/qga.sock
[sudo] password for danielhb: 
{"execute":"guest-get-host-name"}
{"return": {"host-name": "newhostname"}}
{"execute":"guest-get-host-name"}
{"return": {"host-name": "newhostname2"}}
{"execute":"guest-get-host-name"}
{"return": {"host-name": "newhostname-qga5.1"}}
Comment 6 bfu 2020-11-13 09:41:12 UTC 
(In reply to Daniel Henrique Barboza from comment #5)
> The only way I can reproduce this bug is when I don't update the guest QGA to
> the 5.1 version. Which makes sense, given that the fix was in QGA code.
> 
> bfu, can you please check the qemu-ga version you're using? I was using:
> 
> [root@localhost ~]# /usr/bin/qemu-ga --version
> QEMU Guest Agent 4.2.0
> 
> 
> And I got the exact behavior you described. When I updated the
> qemu-guest-agent
> package - inside the guest - to the RHEL-AV version, the bug didn't occur:
> 
> # qemu-ga --version
> QEMU Guest Agent 5.1.0
> 
> This is a series of commands changing the hostname in the guest:
> 
> [root@newhostname ~]# hostnamectl set-hostname newhostname && cat
> /etc/hostname
> newhostname
> [root@newhostname ~]# hostnamectl set-hostname newhostname2 && cat
> /etc/hostname 
> newhostname2
> [root@newhostname ~]# hostnamectl set-hostname newhostname-qga5.1
> 
> 
> This is the output from the QGA socket:
> 
> [danielhb@ltc-boston115 ~]$ sudo nc -U /tmp/qga.sock
> [sudo] password for danielhb: 
> {"execute":"guest-get-host-name"}
> {"return": {"host-name": "newhostname"}}
> {"execute":"guest-get-host-name"}
> {"return": {"host-name": "newhostname2"}}
> {"execute":"guest-get-host-name"}
> {"return": {"host-name": "newhostname-qga5.1"}}

Hi david,
   I checked with the qemu-ga version and it's QEMU Guest Agent 4.2.0 indeed, by the way how could I upgrade it?
Comment 8 Daniel Henrique Barboza (IBM) 2020-11-16 12:24:57 UTC 
(In reply to bfu from comment #6)
> (In reply to Daniel Henrique Barboza from comment #5)

[...]

> 
> Hi david,
>    I checked with the qemu-ga version and it's QEMU Guest Agent 4.2.0
> indeed, by the way how could I upgrade it?

Inside the guest, I added an ADVANCED-VIRT 8.3 repo in /etc/yum.repos.d,
then:

$ dnf module disable virt:rhel -y
$ dnf module enable virt:8.3 -y
$ dnf update qemu-guest-agent


This updated qemu-guest-agent to the AV version (5.1).
Comment 9 bfu 2020-11-17 06:54:51 UTC 
(In reply to Daniel Henrique Barboza from comment #8)
> (In reply to bfu from comment #6)
> > (In reply to Daniel Henrique Barboza from comment #5)
> 
> [...]
> 
> > 
> > Hi david,
> >    I checked with the qemu-ga version and it's QEMU Guest Agent 4.2.0
> > indeed, by the way how could I upgrade it?
> 
> Inside the guest, I added an ADVANCED-VIRT 8.3 repo in /etc/yum.repos.d,
> then:
> 
> $ dnf module disable virt:rhel -y
> $ dnf module enable virt:8.3 -y
> $ dnf update qemu-guest-agent
> 
> 
> This updated qemu-guest-agent to the AV version (5.1).

Hi Daniel,
 I try to use dnf update and seems it works but qga in guest could not be updated automatically also seems a problem, will you fix this ?
Comment 10 Daniel Henrique Barboza (IBM) 2020-11-17 12:23:16 UTC 
(In reply to bfu from comment #9)
> (In reply to Daniel Henrique Barboza from comment #8)

[...]

> Hi Daniel,
>  I try to use dnf update and seems it works but qga in guest could not be
> updated automatically also seems a problem, will you fix this ?

We can't do that. There is no guarantee that the user/sysadm wants to
automatically update packages on the guest (or the host, for that matter).

As state in comment #2, https://bugzilla.redhat.com/show_bug.cgi?id=1845127
fixed this issue for the RHEL-AV 8.3 package. A guest using QGA 4.2.0 will
need to update QGA to the AV version 5.1, and we can't automate that.
Comment 11 bfu 2020-11-17 12:56:28 UTC 
(In reply to Daniel Henrique Barboza from comment #10)
> (In reply to bfu from comment #9)
> > (In reply to Daniel Henrique Barboza from comment #8)
> 
> [...]
> 
> > Hi Daniel,
> >  I try to use dnf update and seems it works but qga in guest could not be
> > updated automatically also seems a problem, will you fix this ?
> 
> We can't do that. There is no guarantee that the user/sysadm wants to
> automatically update packages on the guest (or the host, for that matter).
> 
> As state in comment #2, https://bugzilla.redhat.com/show_bug.cgi?id=1845127
> fixed this issue for the RHEL-AV 8.3 package. A guest using QGA 4.2.0 will
> need to update QGA to the AV version 5.1, and we can't automate that.

followed with https://bugzilla.redhat.com/show_bug.cgi?id=1845127 in comment8
I could only check with this bug after qemu5.1 released so that I won't need to update qga in guest automatically cause it becomes the default qga version right?
Comment 12 bfu 2020-11-18 08:56:20 UTC 
Hi Daniel,
    I've changed this bug to rhel8 and are you going to fix it within qemu4.2? If not  maybe you could close it
Comment 13 bfu 2020-11-18 08:57:35 UTC 
@dbarboza
Comment 14 Daniel Henrique Barboza (IBM) 2020-11-24 10:08:33 UTC 
(In reply to bfu from comment #12)
> Hi Daniel,
>     I've changed this bug to rhel8 and are you going to fix it within
> qemu4.2? If not  maybe you could close it

In my opinion this doesn't look like the type of bug that warrants a backport.
However I'm also aware that the fix is in QEMU 5.1, and the non-AV QEMU
packages will stick with QEMU 4.2 for awhile.

I'll need some advice on what to do with this one. If the resolution "just tell
users to use QGA from RHEL-AV" is acceptable, then we can close it.
Comment 15 David Gibson 2020-11-30 04:32:55 UTC 
"just tell users to use QGA from RHEL-AV" doesn't quite work, because presumably people are using the non-AV versions because they don't have an AV entitlement.

That said, this is a fairly cosmetic problem, particularly with non-AV (no layered product) where we're probably dealing with a fairly basic management layer, and managing the hostname from within the guest is more likely.

Given that, I'm closing as WONTFIX.  We'll revisit this if a customer encounters the problem in the wild.
Note You need to log in before you can comment on or make changes to this bug.