[Ovirt-devel] Modeling LVM storage

Scott Seago 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 mailing list