-virt-df spies on the guest's disk image to try to work out how much
-disk space it is actually using. There are some shortcomings to this,
-described here.
-
-(1) It only understands a limited set of partition types. Assuming
-that the files and partitions that we get back from libvirt / Xen
-correspond to block devices in the guests, we can go some way towards
-manually parsing those partitions to find out what they contain. We
-can read the MBR, LVM, superblocks and so on. However that's a lot of
-parsing work, and currently there is no library which understands a
-wide range of partition schemes and filesystem types (not even
-libparted which doesn't support LVM yet). The Linux kernel does
-support that, but there's not really any good way to access that work.
-
-The current implementation uses a hand-coded parser which understands
-some formats (MBR, LVM2, ext2/3, DOS FAT, Windows NTFS, Linux swap and
-Linux suspend partitions).
-
-(2) The statistics you get are delayed. The real state of, for
-example, an ext2 filesystem is only stored in the memory of the
-guest's kernel. The ext2 superblock contains some meta-information
-about blocks used and free, but this superblock is not up to date. In
-fact the guest kernel may not update it even on a 'sync', not until
-the filesystem is unmounted. Some operations do appear to write the
-superblock, for example L<fsync(2)> [that is my reading of the ext2/3
-source code at least].
+The virt-mem tools spy on the guest's memory image. There are some
+shortcomings to this, described here.
+
+(1) Only works on specific, tested releases of Linux kernels. Support
+for arbitrary Linux kernel versions may be patchy because of changes
+in the internal structures used. Support for non-Linux kernels is
+currently non-existent, and probably impossible for Windows because of
+lack of an acceptable source license.
+
+(2) Heuristics are used which may mean in the worst case that the
+output is wrong.
+
+(3) Structures which are frequently modified may cause errors. This
+could be a problem if, for example, the process table in the guest is
+being rapidly updated.
+
+(4) We have to scan memory to find kernel symbols, etc., which can be
+quite slow. Optimizing the memory scanner would help, and caching the
+base address of the symbol table(s) would make it dramatically faster.