On Wed, Mar 14, 2007 at 09:17:37AM +0000, Richard W.M. Jones wrote: > Jim Meyering wrote: > >How important do you guys think having LVM support will be to ET projects? > >And when will you need it? > > For my point of view, as former sysadmin, virtualisation and LVM are > such a natural fit for each other that I can hardly imagine _not_ > provisioning new virtual servers from space in a VG. Yes, I'd see LVM as the primary backend for the majority of production level virtual machine deployments, particularly with Xen. Closely following that I'd see file based virtual disks as the next most likely backend. Traditional block device partitions I think will really be very much a niche case, except for people (fortunate) enough to have SAN storage. With the case of SAN though, the SAN administrator carves up the storage into chunks with the SAN speciifc managmenet tools, so libparted wouldn't be involved there. > I did look at the API for libparted a few months ago (actually from the > rather ancient released version on gnu.org) and it didn't look to me > like there was any way to express LVM notions through the API, so I > guess this will require a lot of new API calls and structures? The other option is to simply call the LVM commands directly from libvirt which is what pretty much every app seems todo when they need to talk to LVM. We already do this in the network driver backend to deal with iptables and it isn't all that evil. If the libparted developers are working on LVM APIs we should encourage them, but its not clear to me that its worth expending our own resources to develop full LVM support in libparted when libvirt will only ever need a tiny number of LVM operations to be invokved. > Some more open question to everyone else: > Do we need Python bindings? Yes, in so much as any libvirt API needs python (or other language) bindings. > Should libvirt's C API use/expose libparted structures directly? > (And how would this affect the remote case?) I'd say definitely not expose libpartd via libvirt APIs. I view libparted as an internal implementation detail. We're not seeking to turn libvirt into a general purpose parititioning tool, but rather just providing a minimal set of APIs for enumerating, creating and assigning virtual disks to machines. Such an API would be operating at a more abstract higher level than the libparted API, so exposing libparted would be a mistake in this respect. 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 -=|