Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 1632759

Summary: Guest agent info is not reported with latest vdsm
Product: [oVirt] vdsm Reporter: Petr Matyáš <pmatyas>
Component: GeneralAssignee: Milan Zamazal <mzamazal>
Status: CLOSED CURRENTRELEASE QA Contact: Petr Matyáš <pmatyas>
Severity: urgent Docs Contact:
Priority: urgent    
Version: 4.20.0CC: bugs, dyuan, fjin, jiyan, michal.skrivanek, mtessun, mzamazal, pmatyas, ratamir, xuzhang, yafu
Target Milestone: ovirt-4.2.8Keywords: Automation, AutomationBlocker, Regression
Target Release: ---Flags: rule-engine: ovirt-4.2+
rule-engine: blocker+
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: v4.20.45 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
: 1634765 (view as bug list) Environment:
Last Closed: 2019-01-22 10:23:04 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: Virt RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 1633389    
Bug Blocks:    
Attachments:
Description Flags
vdsm log
none
ovirt guest agent logs and /var/log/messages
none
engine log
none
engine log none

Description Petr Matyáš 2018-09-25 13:33:03 UTC
Created attachment 1486745 [details]
vdsm log

Description of problem:
Running a VM with guest agent (and even guest tools) on a host with latest vdsm doesn't show any info reported by guest agent (network info might be reported but I think it's just cached data).
This is also reproducible when migrating a VM from a host with older vdsm (all info reported correctly) to a host with latest vdsm (suddenly all info is gone).

Version-Release number of selected component (if applicable):
vdsm-4.20.40-1.el7ev.x86_64

How reproducible:
always

Steps to Reproduce:
1. run a VM with guest agent
2.
3.

Actual results:
no guest agent info is reported

Expected results:
guest agent info reported correctly

Additional info:
I have the env ready for investigation purposes or to provide additional logs.

Comment 1 Michal Skrivanek 2018-09-25 14:20:41 UTC
need guest logs, which agents are running, versions.

Comment 2 Petr Matyáš 2018-09-25 15:01:53 UTC
Created attachment 1486779 [details]
ovirt guest agent logs and /var/log/messages

There are both ovirt and qemu guest agents running:
qemu-guest-agent-2.8.0-2.el7.x86_64
ovirt-guest-agent-common-1.0.14-3.el7ev.noarch

I don't see anything relevant in either of those logs.

Comment 3 Michal Skrivanek 2018-09-25 17:08:00 UTC
still not very helpful...:)

- which VM?
- what's the engine version?
- engine logs?
- regression since what version/build?
- access details in case the env is still up?

Comment 4 Petr Matyáš 2018-09-26 07:13:53 UTC
Created attachment 1487037 [details]
engine log

This is a regression since 4.2.7-2 build

ovirt-engine-4.2.6.4-0.1.el7ev.noarch

Comment 5 Petr Matyáš 2018-09-26 07:34:29 UTC
Created attachment 1487051 [details]
engine log

Engine logs after also upgrading engine to 4.2.7

ovirt-engine-4.2.7.1-0.1.el7ev.noarch

Comment 9 Raz Tamir 2018-09-26 11:01:01 UTC
I think we started to see such issues when started to test RHEL7.6 on the vdsm (4.2.7).
There are more bugs around the ovirt-guest-agent not reporting info

Comment 10 Raz Tamir 2018-09-26 11:09:50 UTC
Going through our last regression cycle (4.2.7-3), I can see that most of the failures are because of this bug.

Raising severity to urgent (no W/A exists) + adding blocker?

Comment 11 Michal Skrivanek 2018-09-26 14:40:31 UTC
seems qemu or libvirt broke the assumption on agent channel permissions. It used to be qemu:qemu and now it's root:root and vdsm fails to connect then

Comment 12 Ademar Reis 2018-09-26 20:48:01 UTC
(In reply to Michal Skrivanek from comment #11)
> seems qemu or libvirt broke the assumption on agent channel permissions. It
> used to be qemu:qemu and now it's root:root and vdsm fails to connect then

Can you reproduce this outside of RHV, with RHEL components? If you can, please report the steps and change the component of this BZ to libvirt (or clone it, whatever you prefer).

Comment 13 Petr Matyáš 2018-09-27 08:03:35 UTC
(In reply to Ademar Reis from comment #12)
> (In reply to Michal Skrivanek from comment #11)
> > seems qemu or libvirt broke the assumption on agent channel permissions. It
> > used to be qemu:qemu and now it's root:root and vdsm fails to connect then
> 
> Can you reproduce this outside of RHV, with RHEL components? If you can,
> please report the steps and change the component of this BZ to libvirt (or
> clone it, whatever you prefer).

Sorry, but I'm not sure how. If you can provide some steps to test this I will, but you might want to shift this to libvirt QE.

Comment 14 jiyan 2018-09-27 08:21:59 UTC
Hi petr
I have commented for the libvirt bug, the permission issue truly exists.
https://bugzilla.redhat.com/show_bug.cgi?id=1633389#c5 

But I have some doubts and still checking in RHV env.
I checked the env you provided above. there are 2 slot* machines, both are libvirt-4.5.0-10.el7.x86_64.
Q1: 
Do you mean you can reproduce this issue in "libvirt-4.5.0-10.el7.x86_64 + vdsm-4.20.40.1-1.el7ev.x86_64"(which is in the build rhv-4.2.6-5), but can not hit this issue in "libvirt-4.5.0-10.el7.x86_64 + vdsm-4.20.39.1-1.el7ev.x86_64"(which is in the rhv-4.2.7-2 build)?

Q2:
We did not use guest agent info before, so I want to check do you mean, 
I need to enable 'guest agent' in web UI of VM, then enable and start qemu-guest-agent.service in VM, besides, install ovirt-guest-agent-common.noarch for the host than VM runs on.
The expected result should be there are /var/log/ovirt-guest-agent in the host, right?

Comment 15 Petr Matyáš 2018-09-27 09:16:58 UTC
(In reply to jiyan from comment #14)
> Hi petr
> I have commented for the libvirt bug, the permission issue truly exists.
> https://bugzilla.redhat.com/show_bug.cgi?id=1633389#c5 
> 
> But I have some doubts and still checking in RHV env.
> I checked the env you provided above. there are 2 slot* machines, both are
> libvirt-4.5.0-10.el7.x86_64.
> Q1: 
> Do you mean you can reproduce this issue in "libvirt-4.5.0-10.el7.x86_64 +
> vdsm-4.20.40.1-1.el7ev.x86_64"(which is in the build rhv-4.2.6-5), but can
> not hit this issue in "libvirt-4.5.0-10.el7.x86_64 +
> vdsm-4.20.39.1-1.el7ev.x86_64"(which is in the rhv-4.2.7-2 build)?

Yes, exactly. When you start the VMs on (migrate to) host slot-11 the info is actually reported correctly.

> 
> Q2:
> We did not use guest agent info before, so I want to check do you mean, 
> I need to enable 'guest agent' in web UI of VM, then enable and start
> qemu-guest-agent.service in VM, besides, install
> ovirt-guest-agent-common.noarch for the host than VM runs on.
> The expected result should be there are /var/log/ovirt-guest-agent in the
> host, right?

Yes, on the guest it should be enough to install and start ovirt/qemu-guest-agent, the host should get the info. The data is somewhere in vdsm.log.
You don't need guest agent on the host, just on the guest.

Comment 16 Michal Skrivanek 2018-10-29 10:30:16 UTC
tracking upstream libvirt 4.5 dependency

Comment 17 Petr Matyáš 2018-12-12 13:09:49 UTC
Verified on vdsm-4.20.45-1.gitbecd0d4.el7

Comment 18 Sandro Bonazzola 2019-01-22 10:23:04 UTC
This bugzilla is included in oVirt 4.2.8 release, published on January 22nd 2019.

Since the problem described in this bug report should be
resolved in oVirt 4.2.8 release, it has been closed with a resolution of CURRENT RELEASE.

If the solution does not work for you, please open a new bug report.