Bug 1738820 - '-F' option of qemu-ga command cause the guest-fsfreeze-freeze command doesn't work
Summary: '-F' option of qemu-ga command cause the guest-fsfreeze-freeze command doesn...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux Advanced Virtualization
Classification: Red Hat
Component: qemu-kvm
Version: 8.3
Hardware: x86_64
OS: Linux
medium
medium
Target Milestone: rc
: 8.3
Assignee: Danilo de Paula
QA Contact: dehanmeng
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2019-08-08 08:39 UTC by FuXiangChun
Modified: 2020-11-17 17:45 UTC (History)
7 users (show)

Fixed In Version: qemu-kvm-5.1.0-8.module+el8.3.0+8141+3cd9cd43
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-11-17 17:45:27 UTC
Type: Bug
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description FuXiangChun 2019-08-08 08:39:32 UTC
Description of problem:
Start qemu-ga process with '-F' option inside RHEL8.1 as below.
#qemu-ga -m virtio-serial -p /dev/virtio-ports/org.qemu.guest_agent.0 -F -d

Then send 'guest-fsfreeze-freeze' command to guest.  

error message:
VAgentCmdError: Virt Agent command 'guest-fsfreeze-freeze' failed
(arguments: None,    error message: {'class': 'GenericError', 'desc':
"can't access fsfreeze hook '/etc/qemu-kvm/fsfreeze-hook': No such file
or directory"})

root reason:
-F option default fsfreeze-hook script path is /etc/qemu-kvm/fsfreeze-hook. 

Version-Release number of selected component (if applicable):
qemu-guest-agent-4.0.0-6.module+el8.1.0+3736+a2aefea3.x86_64

How reproducible:
always

Steps to Reproduce:
1.start qemu-ga with -F option inside RHEL8.1 guest
#qemu-ga -m virtio-serial -p /dev/virtio-ports/org.qemu.guest_agent.0 -F -d

2.sent 'guest-fsfreeze-freeze' command to guest.
3.

Actual results:
VAgentCmdError: Virt Agent command 'guest-fsfreeze-freeze' failed
(arguments: None,    error message: {'class': 'GenericError', 'desc':
"can't access fsfreeze hook '/etc/qemu-kvm/fsfreeze-hook': No such file
or directory"})

Expected results:
'guest-fsfreeze-freeze' works

Additional info:
without -F option. 'guest-fsfreeze-freeze' works well. and RHEL7 guest din't hit this issue.

Comment 1 xiagao 2019-09-12 06:32:04 UTC
Starting qemu-ga with -F,which will use default hook path.
#qemu-ga -m virtio-serial -p /dev/virtio-ports/org.qemu.guest_agent.0 -F

The default path is /etc/qemu-kvm/fsfreeze-hook which does not exist in RHEL8, so fsfreeze couldn't work.
The default path is /etc/qemu-ga/fsfreeze-hook which exists and works in RHEL7.


So developer, 
would you modify the default path in RHEL8 ?

You can refer to the following bugs which are related with fsfreeze-hook.
https://bugzilla.redhat.com/show_bug.cgi?id=1210707
https://bugzilla.redhat.com/show_bug.cgi?id=1644985#c9

Comment 2 Marc-Andre Lureau 2019-09-12 07:12:15 UTC
I don't think we support starting qemu-ga from command line with default values.

qemu-guest-agent.service & qemu-ga.sysconfig seem to correctly start qemu-ga service.

Having default values point to different locations would mean to run qemu configure again for qemu-ga.

Moving to Danilo for further discussion about packaging

Comment 4 Ademar Reis 2020-02-05 23:02:17 UTC
QEMU has been recently split into sub-components and as a one-time operation to avoid breakage of tools, we are setting the QEMU sub-component of this BZ to "General". Please review and change the sub-component if necessary the next time you review this BZ. Thanks

Comment 5 Danilo de Paula 2020-09-05 02:34:49 UTC
I came back to this problem after a long long time.

Long story short: When qemu-ga was introduced to RHEL-8, I used the bits from qemu-guest-agent from RHEL-7 as base.
In RHEL-7, qemu-guest-agent is built as standalone package, it's built as "qemu-ga", hence the "qemu-ga" folders. They should have been replaced to qemu-kvm in RHEL-8, but I missed it, and I'm afraid now it is too late.

My proposal is this: Instead of renaming /etc/qemu-ga/ to /etc/qemu-kvm, risking users using "/etc/qemu-ga/fsfreeze-hook.d" messing up their configuration, I suggest creating a link from /etc/qemu-ga/fsfreeze-hook to /etc/qemu-kvm/fsfreeze-hook so the script can be executed.

@QA/reporter: can you please check if creating a symlink works? The following subcommand should work:
$ sudo mkdir /etc/qemu-kvm/ && sudo ln -s /etc/qemu-ga/fsfreeze-hook /etc/qemu-kvm/fsfreeze-hook

Marc-Andre: Can you spot any problem with this approach?

Comment 7 Danilo de Paula 2020-09-05 02:37:43 UTC
Also asking Mirek for his opinion as well... ^^

Comment 8 Danilo de Paula 2020-09-05 02:38:58 UTC
Looks like the system missed my request for input from Mirek...

Comment 9 Marc-Andre Lureau 2020-09-06 09:08:30 UTC
(In reply to Danilo Cesar Lemes de Paula from comment #5)
> My proposal is this: Instead of renaming /etc/qemu-ga/ to /etc/qemu-kvm,
> risking users using "/etc/qemu-ga/fsfreeze-hook.d" messing up their
> configuration, I suggest creating a link from /etc/qemu-ga/fsfreeze-hook to
> /etc/qemu-kvm/fsfreeze-hook so the script can be executed.
> ...
> Marc-Andre: Can you spot any problem with this approach?

No, qga expects to have access(path, X_OK) and then be able to exec that path. That should work fine with a link too. Whether SElinux policy is sufficient, I can't easily tell from sesearch, but I tried making a link and the script was still run.

Comment 10 Miroslav Rezanina 2020-09-07 05:00:37 UTC
(In reply to Danilo Cesar Lemes de Paula from comment #5)
> I came back to this problem after a long long time.
> 
> Long story short: When qemu-ga was introduced to RHEL-8, I used the bits
> from qemu-guest-agent from RHEL-7 as base.
> In RHEL-7, qemu-guest-agent is built as standalone package, it's built as
> "qemu-ga", hence the "qemu-ga" folders. They should have been replaced to
> qemu-kvm in RHEL-8, but I missed it, and I'm afraid now it is too late.
> 
> My proposal is this: Instead of renaming /etc/qemu-ga/ to /etc/qemu-kvm,
> risking users using "/etc/qemu-ga/fsfreeze-hook.d" messing up their
> configuration, I suggest creating a link from /etc/qemu-ga/fsfreeze-hook to
> /etc/qemu-kvm/fsfreeze-hook so the script can be executed.
> 
> @QA/reporter: can you please check if creating a symlink works? The
> following subcommand should work:
> $ sudo mkdir /etc/qemu-kvm/ && sudo ln -s /etc/qemu-ga/fsfreeze-hook
> /etc/qemu-kvm/fsfreeze-hook
> 
> Marc-Andre: Can you spot any problem with this approach?


I think this is best approach to allow broken scenario without breaking
existing configurations.

Comment 11 Danilo de Paula 2020-09-09 15:45:37 UTC
Moving this to AV, then cloning to RHEL later on.

Comment 16 Danilo de Paula 2020-09-15 15:17:03 UTC
QA_ACK, please?

Comment 26 dehanmeng 2020-09-18 04:23:47 UTC
Reproduce with version qemu-guest-agent-5.1.0-7.module+el8.3.0+8099+dba2fe3e.x86_64

Version-Release number of selected component (if applicable):
qemu-kvm-5.1.0-7.module+el8.3.0+8099+dba2fe3e.x86_64
qemu-guest-agent-5.1.0-7.module+el8.3.0+8099+dba2fe3e.x86_64

Steps to Reproduce:
1.boot RHEL8 guest with qga installed:
2.Start qemu-ga process with '-F' option inside RHEL8 as below.
#qemu-ga -m virtio-serial -p /dev/virtio-ports/org.qemu.guest_agent.0 -F -d
3.Then send command 'guest-fsfreeze-freeze' to guest on host.

Actual result:
[root@dell-per440-06]# nc -U /tmp/qga.sock
{"execute":"guest-ping"}
{"return": {}}
{"execute":"guest-fsfreeze-freeze"}
{"error": {"class": "GenericError", "desc": "can't access fsfreeze hook '/etc/qemu-kvm/fsfreeze-hook': No such file or directory"}}

Expected results:
{"return":{}}

Verified with version qemu-guest-agent-5.1.0-8.module+el8.3.0+8141+3cd9cd43.x86_64

Version-Release number of selected component (if applicable):
qemu-kvm-5.1.0-8.module+el8.3.0+8141+3cd9cd43.x86_64
qemu-guest-agent-5.1.0-8.module+el8.3.0+8141+3cd9cd43.x86_64

Steps to verify as above:

Actual result:
[root@dell-per440-06]# nc -U /tmp/qga.sock
{"execute":"guest-ping"}
{"return": {}}
{"execute":"guest-fsfreeze-freeze"}
{"return": 2}

Expected results:
as above

Comment 29 errata-xmlrpc 2020-11-17 17:45:27 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (virt:8.3 bug fix and enhancement update), and where to find the updated
files, follow the link below.

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

https://access.redhat.com/errata/RHBA-2020:5137


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