[Ovirt-devel] Modeling LVM storage

[Hugh O. Brock]

On Tue, Sep 16, 2008 at 06:37:50PM +0200, Chris Lalancette wrote:
> sseago and I (and variously, other folks) had a somewhat longish conversation on
> IRC today about carving up storage with LVM.  This is the second time we've
> beaten this horse, so hopefully we are somewhat OK now.  The basic idea is that,
> given an iSCSI LUN (and SCSI and FC LUNs in the future), we want to either:
> 
> 1)  Assign the entire LUN to a guest (this is the way that ovirt works right now)
> 2)  Carve up the LUN using LVM, and then hand out individual logical volumes to
> guests.
> 
> Libvirt handles this case sort of implicitly; that is, you first build a storage
> pool for iscsi, and find all of the volumes on it.  Then you build an LVM
> storage pool out of the iSCSI LUN, and then you can create volumes on top of that.
> 
> 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.
> 
> 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.
> 
> Once those model changes are in place, then we just need the backend taskomatic
> code to handle this (I've worked on that somewhat today, so I have a pretty good
> handle on what it will require), and the frontend WUI pieces.  This latter can
> get somewhat complex, so for the time being, we will have pretty rudimentary
> support.  That is, during VM creation time, we'll allow a user to either choose
> an existing whole LUN for the guest, choose an already existing (but not in use)
> LVM volume for the guest, or carve out a new LVM volume for the guest (subject
> to physical disk space and user quota, naturally).  Later on we'll add more
> complicated handling of LVM, such as deletion, resizing, etc. etc.

This looks good to me. One of the outstanding questions I have is what
(if anything) to do about deleting storage volumes when a user deletes
a VM, but that question goes beyond LVM specifically so I'm willing to
table it for now.

Take care,
--Hugh