Re: [et-mgmt-tools] Re: [Libvir] virt-df (a 'df' tool for virtual domains)

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.