Bug 487533
| Summary: | [RHEL5]: virt-top doesn't show disk transfer statistics | ||
|---|---|---|---|
| Product: | [Fedora] Fedora EPEL | Reporter: | Chris Lalancette <clalance> |
| Component: | virt-top | Assignee: | Richard W.M. Jones <rjones> |
| Status: | CLOSED DUPLICATE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | medium | Docs Contact: | |
| Priority: | low | ||
| Version: | el5 | CC: | ajia, fedora-ocaml-list, mastahnke, pcfe, redhat, rjones, sluskyb, tremble, virt-maint, wolfram, w.schlich |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | ActualBug | ||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2010-10-26 14:02:00 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
I don't have my RHEL 5.3 box at the moment, but the easiest way to find out if it's virt-top or libvirt is to try listing the disk stats using virsh, ie: virsh domblkstat <domain> <blkdev> where <domain> is the domain name and <blkdev> is the target block device name from the XML, eg. hda or xvda OK I had a look at this on my RHEL 5.3 machine and there is a problem. 'virsh domblkstat' works, at least for PV block devices (not for FV ones). # virsh domblkstat F10PV64 xvda xvda rd_req 3550 xvda rd_bytes 61593088 xvda wr_req 405 xvda wr_bytes 5040128 xvda errs 0 # virsh domblkstat RHEL39FV32 xvdb xvdb rd_req 1 xvdb rd_bytes 4096 xvdb wr_req 0 xvdb wr_bytes 0 xvdb errs 0 # virsh domblkstat RHEL39FV32 hda libvir: Xen error : this function is not supported by the hypervisor: read_bd_stats: Frontend block device not connected error: Failed to get block stats RHEL39FV32 hda But virt-top still doesn't see them. I'll have to take a closer look at the version of virt-top in EPEL to see what's wrong. the problem is still exist on RHEL5.3 machine.and 'virsh domblkstat' works for xen PV block devices,but FV fail. (kernel:2.6.18-128.1.6.el5xen;libvirt-0.6.2-1.el5) for PV: [root@dhcp-66-70-18 /]# virsh domblkstat test xvda xvda rd_req 5539 xvda rd_bytes 153436160 xvda wr_req 1289 xvda wr_bytes 9679872 xvda errs 0 for FV: [root@dhcp-66-70-18 domain]# virsh domblkstat test hda error: Failed to get block stats test hda error: internal error read_bd_stats: Frontend block device not connected Alex, Chris, Richard, We're trying to do some tidying up of the EPEL bug list, The whole virtualisation stack including virt-top has been significantly modified in the last 18 months is this bug still valid with the RHEL-5.5 and virt-top-1.0.4-3.1.el5? I've just checked and the bug is still present in RHEL 5.5. *** This bug has been marked as a duplicate of bug 597690 *** |
Description of problem: Despite the work that went into RHEL-5.3 to show disk transfer statistics of blktap devices, virt-top is still not showing them. That is, if I start up virt-top on my dom0, I see output similar to: virt-top 11:07:03 - x86_64 8/8CPU 2000MHz 15102MB 17 domains, 16 active, 4 running, 12 sleeping, 0 paused, 1 inactive D:0 O:0 X:0 CPU: 0.0% Mem: 12838 MB (11813 MB by guests) ID S RDRQ WRRQ RXBY TXBY %CPU %MEM TIME NAME 0 R 0.0 6.0 52:14.09 Domain-0 27 S 0.0 6.0 1:50.03 f10pv_i386 26 R 0.0 5.0 2:21.34 f10pv_x86_64 13 S 0.0 5.0 10:15.87 f8pv_i386 14 S 0.0 5.0 11:21.37 f8pv_x86_64 11 S 0.0 5.0 22:22.51 f9pv_i386 12 S 0.0 5.0 20:35.55 f9pv_x86_64 29 S 0.0 5.0 2:30.98 rhel3fv_i386 37 R 0.0 5.0 2:42.97 rhel4fv_i386 38 S 0.0 5.0 0:48.74 rhel4fv_x86_64 7 S 0.0 5.0 6:41.64 rhel4pv_i386 8 S 0.0 5.0 13:03.53 rhel4pv_x86_64 21 S 0.0 5.0 27:49.61 rhel5fv_i386 36 R 0.0 5.0 2:46.24 rhel5fv_x86_64 39 S 0.0 5.0 0:38.62 rhel5pv_i386 40 S 0.0 5.0 0:37.07 rhel5pv_x86_64 But the RDRQ and WRRQ columns are always blank, for both FV and PV guests. I'm not quite sure if this is a libvirt problem or a problem with virt-top itself, but I thought I'd start with virt-top and we can go from there.