RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1218937 - QEMU Guest Agent VSS Provider is not started after guest tools install
Summary: QEMU Guest Agent VSS Provider is not started after guest tools install
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: virtio-win
Version: 7.1
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: pre-dev-freeze
: 7.3
Assignee: Yvugenfi@redhat.com
QA Contact: Pavel Stehlik
URL:
Whiteboard:
Depends On:
Blocks: BUILD-WGT-3.6 1288337 1401400
TreeView+ depends on / blocked
 
Reported: 2015-05-06 08:44 UTC by Ondra Machacek
Modified: 2017-03-23 09:32 UTC (History)
19 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Cause: Wrong behaviour during package re-install Consequence: VSS server was removed and not restarted Fix: Change upgrade\re-install behaviour of the installer Result: VSS server works after re-install
Clone Of:
Environment:
Last Closed: 2017-03-23 09:32:23 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)
services screenshot (99.99 KB, image/png)
2015-05-13 08:38 UTC, Ondra Machacek
no flags Details

Description Ondra Machacek 2015-05-06 08:44:16 UTC
Description of problem:


Version-Release number of selected component (if applicable):
guest tools 3_5_9

How reproducible:
always

Steps to Reproduce:
1. Via rhevsetuptools install all apps.
2. Check if QEMU Guest Agent VSS Provider is started after installation

Actual results:
It's not started

Expected results:
It is started


Additional info:
Tested on Windows2012_64b, Windows2008R2_64b, Windows2008_32b, Windows2012R2_64b, Windows2012_64b

Comment 1 Sandro Bonazzola 2015-05-08 15:27:53 UTC
Lev, is this a WGT install issue? Or a sub-component issue?

Comment 2 Lev Veyde 2015-05-08 16:04:19 UTC
(In reply to Sandro Bonazzola from comment #1)
> Lev, is this a WGT install issue? Or a sub-component issue?

If any, it's an issue of Qemu GA installer, however we need to verify that the issue is real first.
I re-assigned the bug to Yossi Hindin.

Comment 3 Yvugenfi@redhat.com 2015-05-12 10:28:19 UTC
Hi Ondra,


Do you see the VSS provider service at all or the service exists and is in stopped state?

Can you please post screenshot of service manager? 


Best regards,
Yan.

Comment 4 Yvugenfi@redhat.com 2015-05-12 10:59:08 UTC
Hi,

Can you also please describes steps to reproduce the issue.

Best regards,
Yan.

Comment 5 Ondra Machacek 2015-05-13 08:38:27 UTC
Created attachment 1024958 [details]
services screenshot

Hi Yan,

I've attached sreenshot of services. Please note that this state is after installation without windows restart, service has setup to be started automatically so after restart - it's started.

The steps are in the description. I've just installed all applications with Rhev-tools installer and didn't restart windows.

Comment 6 Lev Veyde 2015-05-13 08:57:38 UTC
(In reply to Ondra Machacek from comment #5)
> Created attachment 1024958 [details]
> services screenshot
> 
> Hi Yan,
> 
> I've attached sreenshot of services. Please note that this state is after
> installation without windows restart, service has setup to be started
> automatically so after restart - it's started.
> 
> The steps are in the description. I've just installed all applications with
> Rhev-tools installer and didn't restart windows.

Hi Ondra,

My question is: is this a clean installation, or is it an update from any previous version of RHEV Tools?

I couldn't reproduce this with clean installation, but I had reproduced it with an update from a previous version of RHEV Tools (I used 3.5-1 as the base version with an update to 3.5-9).

The actual reason it happens with an update is due to a known issue, that Qemu-GA doesn't handles well a repair - a situation when the same version is installed over itself.

Comment 7 Ondra Machacek 2015-05-13 09:42:57 UTC
It's clean installation.

Comment 9 Yvugenfi@redhat.com 2015-08-16 15:27:40 UTC
How to test:

1. Install qemu-ga-win
2. Check that {"execute":"guest-ping"} works
3. Check that {"execute":"guest-fsfreeze-status"} works
4. Run same installer again 
5. Check that {"execute":"guest-ping"} works
6. Check that {"execute":"guest-fsfreeze-status"} works

Comment 10 Yvugenfi@redhat.com 2015-08-16 15:29:50 UTC
The build with fix:
https://brewweb.devel.redhat.com/buildinfo?buildID=452407

Comment 13 Yu Wang 2015-10-15 04:53:27 UTC
Please help to verify this bug.

Comment 14 weliao 2015-10-15 09:26:22 UTC
Host:
3.10.0-324.el7.x86_64
qemu-kvm-rhev-2.3.0-30.el7.x86_64
Tree:
url --url="http://download.englab.nay.redhat.com/pub/rhel/nightly/RHEL-7.2-20151012.n.0/compose/Server/x86_64/os"

Guest:
win2012-64
qemu-ga-x64.msi
http://download.devel.redhat.com/brewroot/packages/qemu-ga-win/7.2.1/1/win/qga/installer/x64/qemu-ga-x64.msi

Install qemu-ga-win-7.2.1-1 (clean installation);the QEMU Guest Agent VSS Provider server stop like Attachments, manual start this service, re-install qemu-ga, this service stop.

Guest:
win2008-32
qemu-ga-x86.msi
http://download.devel.redhat.com/brewroot/packages/qemu-ga-win/7.2.1/1/win/qga/installer/x86/qemu-ga-x86.msi

Install qemu-ga-win-7.2.1-1 (clean installation);the QEMU Guest Agent VSS Provider server stop like Attachments, manual start this service, re-install qemu-ga, this service stop.

How to test:

1. Install qemu-ga-win
2. Check that {"execute":"guest-ping"} works
3. Check that {"execute":"guest-fsfreeze-status"} works
4. Run same installer again 
5. Check that {"execute":"guest-ping"} works
6. Check that {"execute":"guest-fsfreeze-status"} works
--this result is ok
{"execute":"guest-ping"}
{"return": {}}

{"execute":"guest-fsfreeze-status"}
{"return": "thawed"}

cmd:
/usr/libexec/qemu-kvm -name rhel7.2 \
-M pc-i440fx-rhel7.2.0,accel=kvm,usb=off,vmport=off \
-cpu SandyBridge -m 4096 -realtime mlock=off -smp 4 \
-drive file=/home/win2008-32-virtio.qcow2,if=none,id=drive-virtio-disk0,format=qcow2 \
-device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x7,drive=drive-virtio-disk0,id=virtio-disk0 \
-boot menu=on \
-netdev tap,id=hostnet0,vhost=on,script=/etc/ovs-ifup,downscript=/etc/ovs-ifdown  \
-device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:55:66:77:88:99,bus=pci.0,addr=0x3 \
-device qxl-vga,id=video0,ram_size=67108864,vram_size=67108864,vgamem_mb=16,bus=pci.0,addr=0x2 \
-device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x6 \
-chardev socket,path=/tmp/qga.sock,server,nowait,id=qga0 \
-device virtserialport,bus=virtio-serial0.0,chardev=qga0,name=org.qemu.guest_agent.0 \
-spice port=6600,disable-ticketing, \
-monitor stdio \
-qmp tcp:0:4444,server,nowait


so I think this bug didn't fix

Comment 15 Yvugenfi@redhat.com 2015-10-18 07:37:32 UTC
But what about the command? {"execute":"guest-fsfreeze-status"}

The main problem was the the service was removed and not reinstalled at all.

In this case the service should be started on first use.


Best regards,
Yan.

Comment 16 weliao 2015-10-19 02:39:59 UTC
Hi Yan:
(In reply to Yan Vugenfirer from comment #15)
> But what about the command? {"execute":"guest-fsfreeze-status"}
> 
> The main problem was the the service was removed and not reinstalled at all.
> 
> In this case the service should be started on first use.
> 
> 
> Best regards,
> Yan.

 {"execute":"guest-fsfreeze-status"}---this comment 9 tell tested, if this service stop, the command can work well, so this service has relation with the command?{"execute":"guest-fsfreeze-status"}
 Install qemu-ga-win-7.2.1-1 (clean installation), the service didn't started on first use,must manual start or reboot system, this service can start. so I don't know where is this bug fixed point.

Comment 17 lijin 2015-10-20 02:20:14 UTC
Hi Yan,
As the erratum deadline is approaching,could you reply comment#16?
If this bug is not fixed,we need to remove it from the rhel7.2 errata.

Comment 18 Yvugenfi@redhat.com 2015-10-20 10:32:37 UTC
The main issue was that with VSS service none of the guest_fsfreeze* commands would work. If they work (the services is sorted after initial usage) - then the problem is solved.

Comment 19 weliao 2015-10-21 04:46:32 UTC
Hi Yan,
I retest on win2008R2_64, qemu-ga-win-7.0-9 and qemu-ga-win-7.2.1-1

Install qemu-ga-win, the VSS service did't started. and the guest_fsfreeze* commands can work well. after exec commands, this service still stop status.
so
qemu-ga-win-7.0.9 and qemu-ga-win-7.2.1.1 has the same result. which this problem fixed point or I can't reproduce this problem?

please correct me if I made wrong.

Thanks

Comment 20 Yvugenfi@redhat.com 2015-10-21 11:05:53 UTC
Let's reject it, until I will investigate the BZ.

Comment 21 lijin 2015-10-22 02:27:33 UTC
re-assign this bug according to comment#19 and comment#20.

Comment 24 xiagao 2017-03-23 07:56:42 UTC
Reproduced this bug in qemu-ga-win-7.4.2-1 according to comment 0.

pkg:
qemu-ga-win-7.4.2-1
virtio-win-1.9.0-3.el7

kernel-3.10.0-606.el7.x86_64
qemu-kvm-rhev-2.8.0-5.el7.x86_64

Steps:
1. install win2012r2 guest.
2. after installation, install serial driver
3. install qemu-ga-x64.msi
4. check service manager
5. run qemu-ga cmd in host
6. check service manager

results:
after step 4, QEMU Guest Agent VSS Provider is not started. (attachment)
after step 5,
# nc -U /tmp/qga.sock
{"execute":"guest-ping"}
{"return": {}}
{"execute":"guest-fsfreeze-status"}
{"return": "thawed"}
{"execute":"guest-fsfreeze-freeze"}  

{"return": 2}
after step 6,QEMU Guest Agent VSS Provider is started after exec {"execute":"guest-fsfreeze-freeze"} .

So, QEMU Guest Agent VSS Provider is still not started after qemu-ga installation. 
Reassign this bug.

Comment 25 Yvugenfi@redhat.com 2017-03-23 09:15:38 UTC
In any case the behaviour of the VSS server is changing.  There is no real need to start the VSS server after installation.
Agent will start it only during freeze command.

I will update the expected behaviour after the commits are submitted.

Comment 26 Yvugenfi@redhat.com 2017-03-23 09:32:23 UTC
Closing base on comment #25


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