[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [Ovirt-devel] Modeling LVM storage

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.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]