[Ovirt-devel] Modeling LVM storage

[Steve Ofsthun]

Perry N. Myers wrote:
> Steve Ofsthun wrote:
>> 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.
>>
>> How do you plan to distinguish between LVM PVs/LVs created by 
>> ovirt/libvirt on iscsi LUNs from LVM PVs/LVs created by guest OSes on 
>> directly connected iscsi LUNs?  Just blindly running pvscan will run 
>> into all sorts of trouble.
> 
> All storage is virtualized.  Guests don't access iSCSI LUNs directly, 
> they access it through libvirt storage API.  So this shouldn't be an 
> issue.  If we allow guests to directly access iSCSI storage (or other 
> storage) directly it bypasses our ability to restrict via oVirt 
> permissions who can access what storage and limit storage usage by quotas.

I'm not being clear I think.  If libvirt/ovirt allows entire LUNs to be connected as virtual disks to a guest OS, the guest OS can create LVM PVs/LVs on the virtual disks.  These guest PVs/LVs are written directly onto the underlying physical LUNs.  Since these LUNs are also directly visible to the host virtualization software (libvirt, etc), any PVs/LVs created by the guest may be seen by LVM running in the host environment.  If this host environment naively runs pvscan, it will see both host created PVs and guest created PVs (on entire LUNS).  The host environment needs to use some method to positively operate on host create PVs/LVs only and ignore guest created PVs/LVs.  This can only happen when entire LUNs are passed to guest OSes.

Steve