=head1 NAME
-virt-df - 'df'-like utility for virtualization stats
+virt-uname - system information for virtual machines
+
+virt-dmesg - print kernel messages for virtual machines
=head1 SUMMARY
-virt-df [-options]
+virt-uname [-options] [domains...]
+
+virt-dmesg [-options] [domains...]
=head1 DESCRIPTION
-virt-df is a L<df(1)>-like utility for showing the actual disk usage
-of guests. Many command line options are the same as for ordinary
-I<df>.
+These virtualization tools allow you to inspect the status of
+virtual machines running Linux.
-It uses libvirt so it is capable of showing stats across a variety of
-different virtualization systems.
+The tools all use libvirt so are capable of showing stats across a
+variety of different virtualization systems.
-=head1 OPTIONS
+=head1 COMMON OPTIONS
=over 4
-=item B<-a>, B<--all>
-
-Show all domains. The default is show only running (active) domains.
-
=item B<-c uri>, B<--connect uri>
Connect to libvirt URI. The default is to connect to the default
Print the results in CSV format, suitable for importing into a
spreadsheet or database.
-This option is only supported if virt-df was built with CSV support.
+This option is only supported if virt-mem was built with CSV support.
=item B<--debug>
Emit debugging information on stderr. Please supply this if you
report a bug.
-=item B<-h>, B<--human-readable>
-
-Display human-readable sizes (eg. "10GiB" instead of large numbers).
-
-=item B<-i>, B<--inodes>
-
-Display inode information.
-
-This option only works for Unix-like filesystems.
-
=item B<--help>
Display usage summary.
-=item B<-t diskimage>
+=item B<-t memoryimage>
Test mode. Instead of checking libvirt for domain information, this
-runs virt-df directly on the disk image (or device) supplied. You may
+runs the virt-mem tool directly on the memory image supplied. You may
specify the B<-t> option multiple times.
=item B<--version>
Display version and exit.
+=item B<-E auto|littleendian|bigendian>
+
+=item B<-T auto|i386|x86-64|I<address>>
+
+=item B<-W auto|32|64>
+
+These options force the endianness, text address, and word size for
+the subsequent domains listed on the command line (or if no domains
+are listed, then for all domains).
+
+These default to I<auto> which tries to do automatic detection (using
+libvirt, or details from the memory images themselves). You only need
+to use these options if virt-mem tools get the automatic detection
+wrong.
+
+Endianness (I<-E>) sets the memory endianness, for data, pointers and
+so on.
+
+Text address (I<-T>) sets the base address of the kernel image. I<-T
+i386> means to try some common addresses for i386-based kernels. I<-T
+x86-64> means to try some common addresses for x86-64-based kernels.
+I<-T I<address>> sets the address specifically (I<0x> prefix is
+allowed to specify hex addresses).
+
+Word size (I<-W>) sets the word size, 32 or 64 bits.
+
+=item B<-A auto|i386|x86-64|...>
+
+This option sets the architecture to one of a collection of known
+architectures. It is equivalent to setting endianness and wordsize in
+one go, but not text address.
+
=back
-=head1 EXAMPLE
+=head1 EXAMPLES
+
+ # virt-uname
+ f9x32kvm: Linux localhost.localdomain 2.6.24-0.155.rc7.git6.fc9 #1
+ SMP Tue Jan 15 17:52:31 EST 2008 i686 (none)
- # virt-df
- Filesystem 1K-blocks Used Available Type
- f9x32kvm:hda1 190740 24817 165923 Linux ext2/3
- f9x32kvm:VolGroup/LogVol00 6568348 3401656 3166692 Linux ext2/3
- f9x32kvm:VolGroup/LogVol01 1015808 Linux swap
+ # virt-dmesg f9x32kvm | tail
+ <6>Bluetooth: Core ver 2.11
+ <6>NET: Registered protocol family 31
+ <6>Bluetooth: HCI device and connection manager initialized
+ <6>Bluetooth: HCI socket layer initialized
+ <6>Bluetooth: L2CAP ver 2.9
+ <6>Bluetooth: L2CAP socket layer initialized
+ <6>Bluetooth: RFCOMM socket layer initialized
+ <6>Bluetooth: RFCOMM TTY layer initialized
+ <6>Bluetooth: RFCOMM ver 1.8
+ <7>eth0: no IPv6 routers present
=head1 SHORTCOMINGS
-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.
=head1 SECURITY
The current code tries hard to be secure against malicious guests, for
-example guests which set up malicious disk partitions.
+example guests which set up malicious kernel memory.
=head1 SEE ALSO
-L<df(1)>,
+L<uname(1)>,L<dmesg(1)>,
L<virsh(1)>,
L<xm(1)>,
L<http://www.libvirt.org/ocaml/>,
=head1 COPYRIGHT
-(C) Copyright 2007-2008 Red Hat Inc., Richard W.M. Jones
+(C) Copyright 2008 Red Hat Inc., Richard W.M. Jones
http://libvirt.org/
This program is free software; you can redistribute it and/or modify
Bugs can be viewed on the Red Hat Bugzilla page:
L<https://bugzilla.redhat.com/>.
-If you find a bug in virt-df, please follow these steps to report it:
+If you find a bug in virt-mem, please follow these steps to report it:
=over 4
Run
- virt-df --debug > virt-df.log 2>&1
+ virt-[program] --debug > virt-mem.log 2>&1
-and keep I<virt-df.log>. It contains error messages which you should
+and keep I<virt-mem.log>. It contains error messages which you should
submit with your bug report.
-=item 3. Get version of virt-df and version of libvirt.
+=item 3. Get version of virt-mem and version of libvirt.
Run
- virt-df --version
+ virt-[program] --version
=item 4. Submit a bug report.
git.annexia.org / virt-mem.git / blobdiff