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