Bug 1472293
Summary: | guest agent from 3.6 repository is failing to start on vm guest running on 4.2 engine | ||
---|---|---|---|
Product: | [oVirt] ovirt-guest-agent | Reporter: | Lukas Bednar <lbednar> |
Component: | Core | Assignee: | Tomáš Golembiovský <tgolembi> |
Status: | CLOSED DEFERRED | QA Contact: | Pavel Stehlik <pstehlik> |
Severity: | high | Docs Contact: | |
Priority: | unspecified | ||
Version: | 1.0.11 | CC: | avasudev, bugs, lbednar, michal.skrivanek, mkalinin, mtessun, obockows, schandle, tdosek, tgolembi, tjelinek, ykaul |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | If docs needed, set a value | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2018-05-07 15:25:24 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: |
Description
Lukas Bednar
2017-07-18 11:44:06 UTC
@Martin: the problem here boils down to the question if we want to support 3.6 guest agent in 4.2 engine. Do we? (In reply to Tomas Jelinek from comment #1) > @Martin: the problem here boils down to the question if we want to support > 3.6 guest agent in 4.2 engine. Do we? So I expect, we will have a 4.2 guest-agent that is shipped to all repos that currently have the guest-agent shipped. Still in that case, we would need to at least inform all our customers that they need to upgrade their guest-agent package as they typically have their patch windows (which typically do not align to the RHV update). So for a timeline perspective, my questions are: - Does the guest-agent we shipped with 4.0 work with 4.2? - Does the guest-agent we shipped with 3.6 work in 4.1? If both questions are answered with "yes", I would assume that it is safe to drop 3.6 guest-agent with 4.2 as we had a quite long grace period. Nevertheless, we need to document that the guest agent needs to be upgraded to current 4.x version in order to work with 4.2. Does this make sense? Martin (In reply to Martin Tessun from comment #2) > (In reply to Tomas Jelinek from comment #1) > > @Martin: the problem here boils down to the question if we want to support > > 3.6 guest agent in 4.2 engine. Do we? > > So I expect, we will have a 4.2 guest-agent that is shipped to all repos > that currently have the guest-agent shipped. > > Still in that case, we would need to at least inform all our customers that > they need to upgrade their guest-agent package as they typically have their > patch windows (which typically do not align to the RHV update). > > So for a timeline perspective, my questions are: > - Does the guest-agent we shipped with 4.0 work with 4.2? Answer to this one is "no". The support of new channel name is in guest agent since 4.1. > - Does the guest-agent we shipped with 3.6 work in 4.1? Yes, 3.6 guest agent works with 4.1 engine. > If both questions are answered with "yes", I would assume that it is safe to > drop 3.6 guest-agent with 4.2 as we had a quite long grace period. > Nevertheless, we need to document that the guest agent needs to be upgraded > to current 4.x version in order to work with 4.2. > > Does this make sense? > Martin (In reply to Lukas Bednar from comment #0) > Description of problem: > > Guest Agent which is available in 3.6 repository doesn't work on ovirt-4.2. > > When starting service it fails on > > File "/usr/share/ovirt-guest-agent/VirtIoChannel.py", line 132, in __init__ > self._vport = os.open(vport_name, os.O_RDWR) > OSError: [Errno 2] No such file or directory: > '/dev/virtio-ports/com.redhat.rhevm.vdsm' > > I checked virtio-ports on the guest, I found: > /dev/virtio-ports/ovirt-guest-agent.0 > > So I changed value in /etc/ovirt-guest-agent.conf to look like: > [virtio] > # device = /dev/virtio-ports/com.redhat.rhevm.vdsm > device = /dev/virtio-ports/ovirt-guest-agent.0 > > And tried it again and fails on diff error: > File "/usr/share/ovirt-guest-agent/VirtIoChannel.py", line 132, in __init__ > self._vport = os.open(vport_name, os.O_RDWR) > OSError: [Errno 13] Permission denied: > '/dev/virtio-ports/ovirt-guest-agent.0' > That's because guest agent does not have permissions to access the channel. To complete the workaround for this create file with udev rules and notify udev subsystem about the change (or reboot the VM). Like this: # cat /etc/udev/rules.d/55-ovirt-guest-agent.rules SYMLINK=="virtio-ports/ovirt-guest-agent.0", OWNER="ovirtagent", GROUP="ovirtagent" # udevadm trigger --subsystem-match="virtio-ports" (In reply to Tomáš Golembiovský from comment #3) > (In reply to Martin Tessun from comment #2) > > (In reply to Tomas Jelinek from comment #1) > > > @Martin: the problem here boils down to the question if we want to support > > > 3.6 guest agent in 4.2 engine. Do we? > > > > So I expect, we will have a 4.2 guest-agent that is shipped to all repos > > that currently have the guest-agent shipped. > > > > Still in that case, we would need to at least inform all our customers that > > they need to upgrade their guest-agent package as they typically have their > > patch windows (which typically do not align to the RHV update). > > > > So for a timeline perspective, my questions are: > > - Does the guest-agent we shipped with 4.0 work with 4.2? > > Answer to this one is "no". The support of new channel name is in guest agent > since 4.1. > > > - Does the guest-agent we shipped with 3.6 work in 4.1? > > Yes, 3.6 guest agent works with 4.1 engine. > > > If both questions are answered with "yes", I would assume that it is safe to > > drop 3.6 guest-agent with 4.2 as we had a quite long grace period. > > Nevertheless, we need to document that the guest agent needs to be upgraded > > to current 4.x version in order to work with 4.2. this holds - the current 4.x will be newer than 4.0. Also, there is a workaround for older versions described in Comment 4. So I think it is safe to go ahead and turn this into a doc bug and write a KCS to explain to workaround. > > > > Does this make sense? > > Martin I'm not sure if it's not too late for this, but are we going to do anything about it for 4.2 or can we close the bug? (In reply to Tomáš Golembiovský from comment #8) > I'm not sure if it's not too late for this, but are we going to do anything > about it for 4.2 or can we close the bug? not from implementation standpoint, but we still need to notify the customers or write some KB or something. @Tomas, any news on that? (see comment 7) (In reply to Tomas Jelinek from comment #9) > (In reply to Tomáš Golembiovský from comment #8) > > I'm not sure if it's not too late for this, but are we going to do anything > > about it for 4.2 or can we close the bug? > > not from implementation standpoint, but we still need to notify the > customers or write some KB or something. > > @Tomas, any news on that? (see comment 7) Marina? ping? Lets write a KB article on this and get this published. IMO, that will be better than reaching out to all customers (which is practically difficult). (In reply to Arun Vasudevan from comment #12) > Lets write a KB article on this and get this published. IMO, that will be > better than reaching out to all customers (which is practically difficult). We are working the KCS article now. We should have it available soon. Hey, please check the attached solution and review. If all good, we can wide spread it. https://access.redhat.com/solutions/3422711 Tomas, Can you please review the solution? And if you approve it, let's close the bug deferred. Closing the bug as deferred for now. Here is the solution to address it, if impossible to upgrade the agent to latest: https://access.redhat.com/solutions/3422711 |