[Libvir] virt-df (a 'df' tool for virtual domains)
Brave (or foolhardy?) souls may want to try out the almost-working version of 'virt-df' that I wrote: hg clone http://hg.et.redhat.com/virt/applications/virt-top--devel Usage is similar to ordinary 'df'. It understands the -h (human-readable) and -i (show inodes) options. You need to run it on the dom0, it won't work remotely. # virt-df.opt -c qemu:///system debian32kvm /dev/hda (3.9 GiB) /var/lib/xen/images/debian32kvm.img hda1 3662792 990276 2672516 Linux ext2/3 hda5 232908 Linux swap [The numbers are 1K blocks total, used, available] # virt-df.opt -c qemu:///system -h debian32kvm /dev/hda (3.9 GiB) /var/lib/xen/images/debian32kvm.img hda1 3.5 GiB 967.1 MiB 2.5 GiB Linux ext2/3 hda5 227.4 MiB Linux swap From the README file: virt-df is a 'df' tool for printing out the used and available disk space in all active and inactive domains. Without this tool you would need to log in to each domain individually or set up monitoring. It is only a proof-of-concept. Please bare in mind the following limitations when using this tool: (1) It does not work over remote connections. Part of the reason why I wrote virt-df was to get an idea of how the remote storage API for libvirt might look. (2) 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, EBR, 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 simple formats (MBR, EBR, ext2/3, not LVM yet but coming soon). In future we should use something like libparted. (3) 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 fsync(2) [that is my reading of the ext2/3 source code at least]. $ wc -l virt-df/*.ml 84 virt-df/virt_df_ext2.ml 24 virt-df/virt_df_linux_swap.ml 22 virt-df/virt_df_lvm2.ml 5 virt-df/virt_df_main.ml 460 virt-df/virt_df.ml 595 total Rich. -- Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/ Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 03798903
On Thu, Sep 27, 2007 at 07:07:00PM +0100, Richard W.M. Jones wrote:
(2) 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, EBR, 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.
Note that extending libfsimage would be the way to go for the latter part of this (understanding file systems), I think. regards, john
John Levon wrote:
On Thu, Sep 27, 2007 at 07:07:00PM +0100, Richard W.M. Jones wrote:
(2) 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, EBR, 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.
Note that extending libfsimage would be the way to go for the latter part of this (understanding file systems), I think.
Yes ... There are (at least) four separate reimplementations of filesystem / partition parsing code: - fdisk - libparted - grub (from which libfsimage seems to be derived) - Linux kernel Unfortunately libparted & GRUB don't understand LVM which is kind of a problem because everyone's using LVM nowadays. (Well, everyone in the Linux world, obviously different on Solaris). There is some work that I'm aware of to "librarify" LVM and to get LVM support into libparted. Having said all that, the hand-written code I wrote deals with MBRs, EBRs and ext2/3 and it's under 600 lines of code, and even with LVM support I can't see it going over 1,500 lines in total. The big question is what sort of API could libvirt export? For the general provisioning scenario, perhaps it would be something like this: https://www.redhat.com/archives/libvir-list/2007-September/thread.html#00119 Reading and understanding the contents of block devices OTOH is way beyond what libvirt can or ought to provide. Instead it can export a way to snoop on the contents of the block devices (simple operations like: read the size, seek to an offset, read some bytes); then we could extend libparted to abstract away the Unix syscalls so it can work on the libvirt "virtual block device". Rich. -- Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/ Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 03798903
On Thu, Sep 27, 2007 at 07:46:53PM +0100, Richard W.M. Jones wrote:
John Levon wrote:
On Thu, Sep 27, 2007 at 07:07:00PM +0100, Richard W.M. Jones wrote:
(2) 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, EBR, 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.
Note that extending libfsimage would be the way to go for the latter part of this (understanding file systems), I think.
Yes ... There are (at least) four separate reimplementations of filesystem / partition parsing code:
- fdisk - libparted - grub (from which libfsimage seems to be derived) - Linux kernel
Unfortunately libparted & GRUB don't understand LVM which is kind of a problem because everyone's using LVM nowadays. (Well, everyone in the Linux world, obviously different on Solaris).
There is some work that I'm aware of to "librarify" LVM and to get LVM support into libparted.
Having said all that, the hand-written code I wrote deals with MBRs, EBRs and ext2/3 and it's under 600 lines of code, and even with LVM support I can't see it going over 1,500 lines in total.
The big question is what sort of API could libvirt export? For the general provisioning scenario, perhaps it would be something like this:
https://www.redhat.com/archives/libvir-list/2007-September/thread.html#00119
There is the prior discussion on storage requirements too: http://www.redhat.com/archives/libvir-list/2007-February/msg00010.html http://www.redhat.com/archives/libvir-list/2007-February/msg00057.html None of these threads really considered the case of iSCSI, or SAN storage in sufficient detail yet, or the latest SCSI storage adapter virtaulization capabilities that are now appearing. We really need to get a better conceptual model of what we want to represent & enable before diving into APIs. There are two clearly different sets of APIs we're talking about here, but they're getting mixed up. There are APIs for managing storage volumes, and then there are the APIs for dealing with filesystems within them. I could see the libfsimage being useful, except that it is GPL licensed at the moment. Getting free space stats is handy for monitoring. Being able to ask whether there is a valid MBR, and/or Grub config is also handy to tell whether an install was succcess - virt-install for example has a hack to read the first few bytes and look for an MBR to check install status. Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|
On Thu, Sep 27, 2007 at 08:05:10PM +0100, Daniel P. Berrange wrote:
On Thu, Sep 27, 2007 at 07:46:53PM +0100, Richard W.M. Jones wrote:
John Levon wrote:
On Thu, Sep 27, 2007 at 07:07:00PM +0100, Richard W.M. Jones wrote:
(2) 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, EBR, 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.
Note that extending libfsimage would be the way to go for the latter part of this (understanding file systems), I think.
Yes ... There are (at least) four separate reimplementations of filesystem / partition parsing code:
- fdisk - libparted - grub (from which libfsimage seems to be derived) - Linux kernel
Unfortunately libparted & GRUB don't understand LVM which is kind of a problem because everyone's using LVM nowadays. (Well, everyone in the Linux world, obviously different on Solaris).
There is some work that I'm aware of to "librarify" LVM and to get LVM support into libparted.
Having said all that, the hand-written code I wrote deals with MBRs, EBRs and ext2/3 and it's under 600 lines of code, and even with LVM support I can't see it going over 1,500 lines in total.
The big question is what sort of API could libvirt export? For the general provisioning scenario, perhaps it would be something like this:
https://www.redhat.com/archives/libvir-list/2007-September/thread.html#00119
There is the prior discussion on storage requirements too:
http://www.redhat.com/archives/libvir-list/2007-February/msg00010.html http://www.redhat.com/archives/libvir-list/2007-February/msg00057.html
None of these threads really considered the case of iSCSI, or SAN storage in sufficient detail yet, or the latest SCSI storage adapter virtaulization capabilities that are now appearing. We really need to get a better conceptual model of what we want to represent & enable before diving into APIs.
There are two clearly different sets of APIs we're talking about here, but they're getting mixed up. There are APIs for managing storage volumes, and then there are the APIs for dealing with filesystems within them.
I could see the libfsimage being useful, except that it is GPL licensed at the moment. Getting free space stats is handy for monitoring. Being able to ask whether there is a valid MBR, and/or Grub config is also handy to tell whether an install was succcess - virt-install for example has a hack to read the first few bytes and look for an MBR to check install status.
John pointed out to me on IRC that its only the plugins which are GPL. The core library is BSD licensed. The plugins are dl-open() by the main lib - not yet sure what that implies license-wise though... Depending on the way we do the storage APIs this may or may not be an issue. ie, only the libvirt.so needs to be LGPL. If the daemon itself becomes GPL by virtue of loading a GPL library that's not neccessarily a terminal problem if we decide that is worth it, since no end user apps link to the daemon. Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|
participants (3)
-
Daniel P. Berrange -
John Levon -
Richard W.M. Jones