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.
need guest logs, which agents are running, versions.
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.
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?
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
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
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
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?
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
(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).
(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.
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?
(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.
tracking upstream libvirt 4.5 dependency
Verified on vdsm-4.20.45-1.gitbecd0d4.el7
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.