parted/LVM for ET [Re: [Libvir] Storage manager initial requirements and thoughts

[Daniel P. Berrange]

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  -=|