bumped into this one by accident while looking for something else, but it’s most handy to keep an eye on the local VMs from the console1, including network and disk I/O! it could have come in handy a year ago…

virt-top obtains the data from libvirt, so you need to have that going first. on the positive side, perhaps the libvirt indirection will allow it to support stuff other than KVM (i may have seen Xen mentioned somewhere). it’s in the official Fedora (and EPEL) repos, so just:

# yum install virt-top
# virt-top

admittedly, the similarity to top is… superficial, and the output takes some getting used to, but most of it is fairly straightforward to puzzle out, and [presumably by popular demand] there are some annotated screenshots on virt-top home page just in case (scroll down to the end of that page).

the default view is “domains display” (in the libvirt “guest domains“ sense, not DNS), and it looks along the lines of:

virt-top 22:29:19 - x86_64 4/4CPU 1452MHz 7950MB 1.8% 1.5%
5 domains, 2 active, 2 running, 0 sleeping, 0 paused, 3 inactive D:0 O:0 X:0
CPU: 1.4%  Mem: 1408 MB (1408 MB by guests)

   ID S RDRQ WRRQ RXBY TXBY %CPU %MEM    TIME   NAME                                      
    1 R    0    0  104    0  0.7  4.4  63:20.37 f15-server-1
    2 R    0    0  104    0  0.7 13.3   2:02.74 f15-client-3
    -                                           (f15-client-2)
    -                                           (centos-nfs-server)
    -                                           (centos-client-2)

it combines disk (*RQ), net (*BY) and CPU/mem load of each VM, including VMs that are not currently running (er… why?). keyboard shortcut: 0.

dedicated disk (strictly speaking: block device, shortcut: 3) and net (2) views only provide additional breakdown by individual disk and NIC, respectively, plus present the same info in more than one way (requests and packets, respectively, in addition to bytes), so you’ll probably resort to either of those only once you’ve spotted a problem with a VM as a whole.

the dedicated “physical CPU” (shortcut: 1) will typically be quite useless, both due to the way it’s implemented (cores are horizontal lines, VMs are sets of columns), and due to the nature of the info (usually you don’t quite care which of the cores a given VM is hogging, only that that it does).

as the name hints, virt-top sticks to its limited scope: providing at-a-glance overview of which host resources which VMs are hogging, without requiring X. it’s not a replacement for proper virtualisation management solutions, nor even for virt-manager (unfortunately!), but it’s lightweight and is perfect for keeping an eye on VMs on a lappy or an odd server2.

  1. virt-manager is still only partially usable and turning on CPU/net visualisation usually puts it smack into the “unusable” category, at least on my F15…

    [return]

  2. as is typical for libvirt and friends there are some provisions for remote connectivity using -c <URI> cmd-line switch, but i never bothered: the beauty of virt-top is that you can just ssh to that odd server and invoke virt-top directly, whether that server is sitting right next door or in a colo on the other side of the pond.

    [return]