[Ovirt-devel] Modeling LVM storage

Konrad Rzeszutek konrad at virtualiron.com
Tue Sep 16 17:13:30 UTC 2008


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

Ah, sorry I missed it.

> 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

When you say volumes, do you mean PVs/VGs? or just logical disks? 

> storage pool out of the iSCSI LUN, and then you can create volumes on top of that.

Creating the storage pool implies then that uninitialized LUNs would go
through the 'pvcreate/vgcreate/vgchange' process?

This would also imply that for FC you would need to create a storage pool for the
FC.. HBA and from there get the SCSI LUNs? What about the asynchronous nature of
the FC wherein the remote ports can show up and new disks would appear without
the need to setup a storage pool? 

With multipath in this picture this is going to get a bit tricky. It would seem
as it would sit on top of the storage pool for iSCSI. And that would mean
the LVM operations MUST be disallowed on the iSCSI/FC layer but "moved" up
to the multipath storage pool?




More information about the ovirt-devel mailing list