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 1347726 - events are flooded with 'Refresh image list succeeded for domain(s):' when console is open
Summary: events are flooded with 'Refresh image list succeeded for domain(s):' when co...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: virt-viewer
Version: 7.3
Hardware: Unspecified
OS: Unspecified
high
low
Target Milestone: rc
: ---
Assignee: Eduardo Lima (Etrunko)
QA Contact: SPICE QE bug list
URL:
Whiteboard:
Depends On: 1310624
Blocks: 1353627 1358809
TreeView+ depends on / blocked
 
Reported: 2016-06-17 13:23 UTC by Christophe Fergeau
Modified: 2016-11-04 01:21 UTC (History)
16 users (show)

Fixed In Version: virt-viewer-2.0-9.el7
Doc Type: Bug Fix
Doc Text:
Previously, opening a remote guest console with the remote-viewer utility in the Red Hat Enterprise Virtualization Manager caused the event log to be flooded with the "Refresh image list succeeded for domain(s)" message. This update significantly lowers the frequency of displaying messages about refreshing image list, so that they no longer flood the guest event log.
Clone Of: 1310624
: 1353627 1358809 (view as bug list)
Environment:
Last Closed: 2016-11-04 01:21:52 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2016:2229 0 normal SHIPPED_LIVE virt-viewer, libgovirt, spice-gtk, and usbredir bug fix and enhancement update 2016-11-03 13:26:58 UTC

Description Christophe Fergeau 2016-06-17 13:23:53 UTC
+++ This bug was initially created as a clone of Bug #1310624 +++

Description of problem:
due to foreign menu feature the events are folded with " Refresh image list succeeded for domain(s): XXX (All file type) event. 


Version-Release number of selected component (if applicable):
Red Hat Enterprise Virtualization Manager Version: 3.6.3.2-0.1.el6 


How reproducible:
100%

Steps to Reproduce:
1.connect to webadmin (with fqdn)
2.open console to a running VM and look at the events

Actual results:


Expected results:


Additional info:

--- Additional comment from Shira Maximov on 2016-02-22 06:43:05 EST ---

note: an ISO domain should be attached.

--- Additional comment from Shira Maximov on 2016-02-22 06:45 EST ---

the engine log is also flooded .

--- Additional comment from Michal Skrivanek on 2016-02-23 00:53:39 EST ---

HA reservation status log every 5s should also be tackled

--- Additional comment from Michal Skrivanek on 2016-02-24 07:16:06 EST ---

It shouldn't be so often, right?

--- Additional comment from Christophe Fergeau on 2016-02-29 11:17:59 EST ---

iirc remote-viewer is getting the ISO list every 5 seconds.
As I could not find a way to get a notification when a new ISO appears, I had to make a guess as to how long a user will accept to wait for an ISO to appear in the foreign menu after it's added to the ISO domain.

--- Additional comment from Michal Skrivanek on 2016-02-29 11:48:04 EST ---

Well, I wouldn't do that unless someone opens the menu. Would that be a big change? It's a small delay, but I think it's better than refreshing so often. Otherwise this can be used as a keepalive mechanism:) what do you think?

--- Additional comment from Christophe Fergeau on 2016-02-29 12:03:28 EST ---

I think (haven't tested) the menu is going to get closed if something changes while the menu is opened. And I don't think that's a very good UI if you want to use an ISO you just added to the domain, especially if the connection to the ovirt instance is slow.
But apart from your suggestion or the current polling, I can't really think of a smart way of doing things (well, apart from getting events from oVirt but I'm not holding my breath for that ;)

--- Additional comment from Tomas Jelinek on 2016-03-01 03:56:39 EST ---

But imagine we have hundreds of clients concurrently accessing the VMs using remote viewer. Only the amount of data transferred over the line every 5 seconds is going to be significant. Not to mention the additional load on the engine side.

Any chance you could investigate a bit more the Michal's suggestion with loading only when the menu opens? Because we are not getting events in near future for sure even we all would love to see them :)

--- Additional comment from Christophe Fergeau on 2016-03-01 09:10:45 EST ---

We could do the refresh much less often (how often would be acceptable ? every 5 minutes ?) and have Michal's suggestion as a poor-man's refresh. But in situations like in bug #1310450 (look at CD menu, disable ISO damain, look at CD menu), things are going to be odd.

--- Additional comment from Tomas Jelinek on 2016-03-02 03:00:45 EST ---

Every 5 minutes sounds good enough - you typically don't change the content of the ISO domain too often.
What you mean by odd? The fact that you will see one CD in the menu and when open than it will disappear? Or something else?

--- Additional comment from Christophe Fergeau on 2016-03-02 04:25:00 EST ---

(In reply to Tomas Jelinek from comment #10)
> What you mean by odd? The fact that you will see one CD in the menu and when
> open than it will disappear? Or something else?

I'm not fully sure about the exact behaviour if the list changes while the menu is opened. But if you are on a slow link and add a new ISO that you want to use, 
you'll open the menu, the ISO is not there, you wait a bit, open the menu (assuming you decide to try again!), the ISO is magically there. That's very unexpected ;)

--- Additional comment from Tomas Jelinek on 2016-03-11 08:49:03 EST ---

(In reply to Christophe Fergeau from comment #11)
> you'll open the menu, the ISO is not there, you wait a bit, open the menu
> (assuming you decide to try again!), the ISO is magically there. That's very
> unexpected ;)

than the only thing I can think of is a specific "refresh" button in the menu. Not beautiful but at least no polling needed at all and the user will know why did the new ISO magically appeared.

--- Additional comment from Christophe Fergeau on 2016-03-11 11:41:27 EST ---

I think we can go with the suggestion from comment #9, but I'm not going to be hugely enthusiastic when bugs are reported against this behaviour...

--- Additional comment from Tomas Jelinek on 2016-03-14 04:08:02 EDT ---

(In reply to Christophe Fergeau from comment #13)
> I think we can go with the suggestion from comment #9, but I'm not going to
> be hugely enthusiastic when bugs are reported against this behaviour...

if there could be some kind of a loading indicator somewhere indicating that you are loading the new list the behavior would be much less odd. Do you think you could put it somewhere?

--- Additional comment from Tomas Jelinek on 2016-04-06 03:08:27 EDT ---

@Christophe: so how have you decided?

--- Additional comment from Eduardo Lima (Etrunko) on 2016-06-17 08:14:40 EDT ---

So, this is a virt-viewer issue, yes. I will investigate a way of doing this check only on demand, or as last resource We could adopt the longer timer for a quick fix.

Comment 3 Xiaodai Wang 2016-07-01 11:02:46 UTC
I can reproduce it with virt-viewer-2.0-8.el7.x86_64:

Steps:
1. Download console.vv file from ovirt server.
2. Open the vv file by "G_MESSAGES_DEBUG=all remote-viewer console.vv".
3. Check the refreshing iso list logs in terminal.

Result:
"remote-viewer-DEBUG: Refreshing foreign menu iso list" displays every 15 seconds.

then verified it with virt-viewer-2.0-9.el7.x86_64:

"remote-viewer-DEBUG: Refreshing foreign menu iso list" displays every 5 minutes.


From above information, the flooding event log is fixed.

I'm gonna move the bug from ON_QA to VERIFIED.

Comment 4 Xiaodai Wang 2016-07-01 11:08:22 UTC
And i verified the situation which an iso image is removed from iso domain and the foreign menu refresh timer has not been triggered. 

1. If foreign menu is opened when the timer time out, the foreign menu disappears, you can reopen it again and can get correct iso list.
I think this would not affect user.

2. If open it directly in firefox, active an inexistent iso item, there is no response. You cannot get any errors.
3. If open the guest by "remote-viewer console.vv" after downloading the vv file. If you set an inexistent iso item, "(remote-viewer:11442): remote-viewer-WARNING **: failed to update cdrom resource: Bad Request" will display.  This warning is not friendly and cannot get some usefull info about why it failed.
4. If open the guest by "G_MESSAGES_DEBUG=all remote-viewer console.vv" after downloading the vv file, you can find below debugging messages.

(remote-viewer:11442): remote-viewer-WARNING **: failed to update cdrom resource: Bad Request
(remote-viewer:11442): remote-viewer-DEBUG: setting OvirtCdrom:file back to '(null)'

(remote-viewer:11442): remote-viewer-WARNING **: failed to update cdrom resource: Bad Request
(remote-viewer:11442): remote-viewer-DEBUG: setting OvirtCdrom:file back to 'RHEV-toolsSetup_4.0_2.iso'
(remote-viewer:11442): remote-viewer-DEBUG: 'virtio-win-1.8.0.iso' clicked
(remote-viewer:11442): remote-viewer-DEBUG: Updating VM cdrom image to 'virtio-win-1.8.0.iso'
(remote-viewer:11442): remote-viewer-DEBUG: Finished updating cdrom content


The result is it's not friendly for giving user a good hint about why failed to active an iso item and for users who open the guest directly in firefox, they will not get any errors.

I'm thinking how about adding a refresh menu item in foreign menu to refresh manually by users?

Comment 5 Eduardo Lima (Etrunko) 2016-07-04 12:49:52 UTC
(In reply to xiaodwan from comment #4)
> The result is it's not friendly for giving user a good hint about why failed
> to active an iso item and for users who open the guest directly in firefox,
> they will not get any errors.
> 
> I'm thinking how about adding a refresh menu item in foreign menu to refresh
> manually by users?

I am working on the fix for this issue by changing the menu with a dialog that will have a button for manual refresh of the list. This will also solve the problem we have when the list is too big to show. For the moment we will keep this extended timer as a temporary fix.

Comment 9 errata-xmlrpc 2016-11-04 01:21:52 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, 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://rhn.redhat.com/errata/RHBA-2016-2229.html


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