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' I don't know whether this is supported scenario, but I can imagine when customer have some old templates and upgrade his engine from 4.1 to 4.2, his machines will not report back to engine until guest agent gets updated as well. Version-Release number of selected component (if applicable): Guest agent: rhevm-guest-agent-common-1.0.11-5.el7ev.noarch Guest OS: Red Hat Enterprise Linux Server release 7.4 (Maipo) Engine: ovirt-4.2-master How reproducible: 100% Steps to Reproduce: 1. Deploy ovirt-4.2 engine 2. Spawn vm with RHEL7.4 and install guest agent from latest 3.6 repository 3. Try to start agent Actual results: 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' Expected results: Agent get started and reports back to engine Additional info:
@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