[Ovirt-devel] Modeling LVM storage
sseago at redhat.com
Tue Sep 16 16:49:05 UTC 2008
Chris Lalancette wrote:
> We can follow the same sort of model for ovirt. That is, we currently have a
> StoragePool defined in the model, which contains 0 or more StorageVolumes. So
> the idea is that we now add a new type of StoragePool, LVM, which consists of
> one or more iSCSI StorageVolumes, and on top of that, you have a new type of
> StorageVolume, LVM, which is what you eventually assign to guests.
Just to clarify above part, as I think the above gives a bit of a wrong
idea. Right now, each StoragePool has 0 or more StorageVolumes. The
volumes must be of the same 'type' as the pool. Thus an NfsStoragePool
as 0 or more NfsStorageVolumes, an IscsiStoragePool has 0 or more
IscsiStorageVolumes. Following the same pattern, an LvmStoragePool has 0
or more LvmStorageVolumes. For all 3 types, the StorageVolumes can
potentially be assigned to guests.
In additon, for LvmStoragePools, we have a new association defined
between it and StorageVolumes. an LvmStoragePool has 1 or more "source
storage volumes" (I'm open to different names here -- I just didn't want
the name to be iSCSI-specific), which for the moment must be
IscsiStorageVolumes. When determining which storage volumes are
available for guests, we'll have to filter out storage volumes which are
connected to LvmStoragePools.
> Note that the above model should eventually support binding multiple iSCSI LUNs
> into a single LVMPool, although we won't expose that functionality to the user
> for the moment.
More information about the ovirt-devel