Bug 1472293 - guest agent from 3.6 repository is failing to start on vm guest running on 4.2 engine
Summary: guest agent from 3.6 repository is failing to start on vm guest running on 4....
Keywords:
Status: CLOSED DEFERRED
Alias: None
Product: ovirt-guest-agent
Classification: oVirt
Component: Core
Version: 1.0.11
Hardware: Unspecified
OS: Unspecified
unspecified
high vote
Target Milestone: ---
: ---
Assignee: Tomáš Golembiovský
QA Contact: Pavel Stehlik
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-07-18 11:44 UTC by Lukas Bednar
Modified: 2019-04-28 09:02 UTC (History)
12 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-05-07 15:25:24 UTC
oVirt Team: Virt


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Knowledge Base (Solution) 3422711 None None None 2018-04-24 19:51:05 UTC

Description Lukas Bednar 2017-07-18 11:44:06 UTC
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:

Comment 1 Tomas Jelinek 2017-08-01 10:34:20 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?

Comment 2 Martin Tessun 2017-08-03 07:31:22 UTC
(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

Comment 3 Tomáš Golembiovský 2017-08-07 14:19:51 UTC
(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

Comment 4 Tomáš Golembiovský 2017-08-07 14:32:34 UTC
(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"

Comment 5 Tomas Jelinek 2017-08-29 08:30:22 UTC
(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

Comment 8 Tomáš Golembiovský 2017-12-04 18:43:59 UTC
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?

Comment 9 Tomas Jelinek 2017-12-05 08:03:22 UTC
(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)

Comment 10 Yaniv Kaul 2018-03-13 07:28:31 UTC
(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?

Comment 11 Michal Skrivanek 2018-04-16 13:24:13 UTC
ping?

Comment 12 Arun Vasudevan 2018-04-18 08:38:29 UTC
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).

Comment 13 schandle 2018-04-20 12:53:52 UTC
(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.

Comment 17 Marina Kalinin 2018-04-30 19:03:42 UTC
Hey, please check the attached solution and review.
If all good, we can wide spread it.
https://access.redhat.com/solutions/3422711

Comment 18 Marina Kalinin 2018-05-01 14:08:19 UTC
Tomas,
Can you please review the solution?
And if you approve it, let's close the bug deferred.

Comment 20 Marina Kalinin 2018-05-07 15:25:24 UTC
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


Note You need to log in before you can comment on or make changes to this bug.