Re: parted/LVM for ET [Re: [Libvir] Storage manager initial requirements and thoughts
On Tue, 2007-03-20 at 14:32 +0000, Daniel P. Berrange wrote:
On Tue, Mar 20, 2007 at 12:06:39PM +0000, Mark McLoughlin wrote:
>
> I still haven't gone off the notion of a virtual storage pool :-)
>
> https://www.redhat.com/archives/libvir-list/2007-February/msg00057.html
I like the idea of storage pools too, but not the impl described in that
thread :-)
/me too. But right now, we are not just lacking storage pools, we are
also lacking reasonable local means to deal with storage. And robust
support for handling storage locally is needed as the foundation for
doing things like pools and non-local management.
In addition, for pools we'd want to abstract away some of the
differences between the various storage 'backends', i.e. you allocate a
10GB block device from pool 'foo' without having to worry whether that
is backed by a container file or by an LV. That should probably be a
layer that sits on top of the local API.
- There are a couple of different types of storage pool
- An LVM volume group
- Block devices
I don't like putting block devices at this level; after all an LVM LV is
a block device, too. And using partitions of a block device in analogy
to LV's in a VG adds additional constraints, e.g. because the number of
partitions is restricted. If a physical block device should become part
of a pool, it should just be added to a volume group.
- A directory on a filesystem
And then there's stuff like SAN's, which is another way to carve
physical storage into block devices, though I ahve no idea how we would
dela with that at this level.
That's pretty much it. I'd be inclined to implement regular
file based pool
in terms of /var/lib/xen/images (or /var/lib/libvirt/images?) as a first
target. Its by far the easiest since it merely requires use of POSIX apis,
and is also completely cross-platform portable (which LVM isn't).
That would be a really good first step for storage pools.
David