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
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
virt-top home page just in case (scroll down to the end of that page).
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:
dedicated disk (strictly speaking: block device, shortcut:
3) and net (
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.
virt-manageris still only partially usable and turning on CPU/net visualisation usually puts it smack into the “unusable” category, at least on my F15…
as is typical for[return]
libvirtand friends there are some provisions for remote connectivity using
-c <URI>cmd-line switch, but i never bothered: the beauty of
virt-topis that you can just ssh to that odd server and invoke
virt-topdirectly, whether that server is sitting right next door or in a colo on the other side of the pond.