643893 – RFE: "virt-top -b" should be more like "top -b"

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 643893 - RFE: "virt-top -b" should be more like "top -b"

Summary: RFE: "virt-top -b" should be more like "top -b"

Keywords:
Status:	CLOSED ERRATA
Alias:	None
Product:	Red Hat Enterprise Linux 6
Classification:	Red Hat
Component:	virt-top
Sub Component:
Version:	6.0
Hardware:	All
OS:	Linux
Priority:	high
Severity:	high
Target Milestone:	rc
Target Release:	---
Assignee:	Richard W.M. Jones
QA Contact:	Virtualization Bugs
Docs Contact:
URL:
Whiteboard:
Depends On:
Blocks:	700575
TreeView+	depends on / blocked

Reported:	2010-10-18 12:51 UTC by Sadique Puthen
Modified:	2018-11-14 16:49 UTC (History)
CC List:	5 users (show)
Fixed In Version:	virt-top-1.0.4-3.7.el6
Doc Type:	Enhancement
Doc Text:
Clone Of:
Environment:
Last Closed:	2011-05-19 14:10:48 UTC
Target Upstream Version:
Embargoed:

Attachments	(Terms of Use)

Links
System	ID	Private	Priority	Status	Summary	Last Updated
Red Hat Product Errata	RHBA-2011:0720	0	normal	SHIPPED_LIVE	virt-top bug fix update	2011-05-18 18:09:39 UTC

Description Sadique Puthen 2010-10-18 12:51:52 UTC

Description of problem:

Option "-b" as documented in man page of virt-top doesn't work as expected. It's expected to work like "top -b". There doesn't seem to be difference of the behavior between "virt-top -b" and its normal mode (virt-top).

Version-Release number of selected component (if applicable):

Red Hat Enterprise Linux Version Number: 6
Release Number: RC1
Architecture: x86_64
Kernel Version: kernel-2.6.32-71.el6.x86_64
Related Package Version: virt-top-1.0.4-3.1.el6.x86_64

How reproducible:

Always.

Steps to Reproduce:

1. Just run the virt-top with -b option and without -b option. There seems to be no difference.
  
Actual results:

"virt-top -b" doesn't work with batch mode. 

Expected results:

"virt-top -b" works with batch mode. 

Additional info:

Comment 6 Richard W.M. Jones 2011-01-06 10:47:01 UTC

This appears to work for me, both upstream and in RHEL 6.0.

The difference between virt-top and virt-top -b is that with
the -b option keypresses are ignored (except for ^C).

Try:

  virt-top -c test:///default

and hit the 'q' key.  virt-top quits immediately.

Then try:

  virt-top -c test:///default -b

and hit keys like 'q', 's' etc.  virt-top will ignore keypresses.
It still responds to ^C so you can exit, and when you exit you will
see the keys you pressed in the shell.

As I said, I have done this with both virt-top upstream (Fedora 15)
and virt-top in RHEL 6.0, and it works as expected in both.

Comment 10 Richard W.M. Jones 2011-01-24 14:45:15 UTC

I really think the best solution to this is to use:

  virt-top -b --script --csv /dev/stdout

The reason is that the output of 'top -b' is hard to parse accurately.
CSV is much better in this respect (see also:
https://bugzilla.redhat.com/show_bug.cgi?id=665817#c4
https://bugzilla.redhat.com/show_bug.cgi?id=665817#c5 )

With this option they'll get the following output:

# virt-top -b --script --csv /dev/stdout
Hostname,Time,Arch,Physical CPUs,Count,Running,Blocked,Paused,Shutdown,Shutoff,Crashed,Active,Inactive,%CPU,Total hardware memory (KB),Total memory (KB),Total guest memory (KB),Total CPU time (ns),Domain ID,Domain name,CPU (ns),%CPU,Block RDRQ,Block WRRQ,Net RXBY,Net TXBY
spin.home.annexia.org,14:44:09,x86_64,4,37,1,0,0,0,0,0,1,36,0.0,3832252,1048576,1048576,0,13,RHEL60x64,0.,0.,,,,
spin.home.annexia.org,14:44:12,x86_64,4,37,1,0,0,0,0,0,1,36,0.2,3832252,1048576,1048576,30000000,13,RHEL60x64,30000000.,0.244652070164,0,0,1418,2256
spin.home.annexia.org,14:44:15,x86_64,4,37,1,0,0,0,0,0,1,36,0.4,3832252,1048576,1048576,50000000,13,RHEL60x64,50000000.,0.41470537961,0,0,2002,2486
spin.home.annexia.org,14:44:18,x86_64,4,37,1,0,0,0,0,0,1,36,0.3,3832252,1048576,1048576,40000000,13,RHEL60x64,40000000.,0.324061824413,0,1,1974,2582
spin.home.annexia.org,14:44:21,x86_64,4,37,1,0,0,0,0,0,1,36,0.3,3832252,1048576,1048576,40000000,13,RHEL60x64,40000000.,0.331830683363,0,0,1272,2448
^C

Note that this already works with RHEL 6.0.

Comment 11 Richard W.M. Jones 2011-02-04 18:43:56 UTC

Fujitsu's Hiroyuki Kamezawa supplied the final patch
which adds --stream and --block-in-bytes options.

Upstream:
http://git.annexia.org/?p=virt-top.git;a=commitdiff;h=daf79631f3eff904ba89297148c4125ac7dfee39
http://git.annexia.org/?p=virt-top.git;a=commitdiff;h=dbef8dd3bf00417e75a12c851b053e49c9e1a79e

I have backported both of these to the virt-top-1.0.4-3.7.el6
package and we agree that this fixes the bug, although not
in exactly the way described.

To test use:

virt-top --stream
# output should go to stdout

virt-top --stream --block-in-bytes
# block I/O shown in bytes instead of requests

Also run virt-top normally and with the --block-in-bytes
options and try toggling using the 'b' key.

Brew build:
http://brewweb.devel.redhat.com/brew/taskinfo?taskID=3090650

Comment 14 koka xiong 2011-02-22 06:30:13 UTC

Verified with virt-top-1.0.4-3.7.el6.x86_64
1. virt-top --stream
virt-top time  13:02:44 Host kxiong x86_64 4/4CPU 3000MHz 7868MB 
   ID S RDRQ WRRQ RXBY TXBY %CPU %MEM   TIME    NAME
    2 R    0    0    0    0  0.0 13.0   0:10.52 test
qqvirt-top time  13:02:47 Host kxiong x86_64 4/4CPU 3000MHz 7868MB 
   ID S RDRQ WRRQ RXBY TXBY %CPU %MEM   TIME    NAME
    2 R    0    0   52    0  0.2 13.0   0:10.55 test
2. virt-top --stream --block-in-bytes
virt-top time  13:01:36 Host kxiong x86_64 4/4CPU 800MHz 7868MB 
   ID S RDBY WRBY RXBY TXBY %CPU %MEM   TIME    NAME
    2 R    0    0    0    0  0.0 13.0   0:08.70 test
virt-top time  13:01:39 Host kxiong x86_64 4/4CPU 800MHz 7868MB 
   ID S RDBY WRBY RXBY TXBY %CPU %MEM   TIME    NAME
    2 R    0    0   52    0  0.3 13.0   0:08.74 test
3. virt-top -b --block-in-bytes
virt-top 13:12:06 - x86_64 4/4CPU 1800MHz 7868MB 1.3%
2 domains, 1 active, 1 running, 0 sleeping, 0 paused, 1 inactive D:0 O:0 X:0
CPU: 1.3%  Mem: 1024 MB (1024 MB by guests)

    ID S RDBY WRBY RXBY TXBY %CPU %MEM    TIME NAME  
    2 R    0    0   52    0  1.3 13.0   0:20.98 test

Comment 17 errata-xmlrpc 2011-05-19 14:10:48 UTC

An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2011-0720.html

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