[Engine-devel] [vdsm] RFC: Writeup on VDSM-libstoragemgmt integration

[Deepak C Shetty]

On 06/25/2012 08:28 PM, Ryan Harper wrote:
> * Andrew Cathrow<acathrow at redhat.com>  [2012-06-24 21:11]:
>>
>> ----- Original Message -----
>>> From: "Andy Grover"<agrover at redhat.com>
>>> To: "Shu Ming"<shuming at linux.vnet.ibm.com>
>>> Cc: libstoragemgmt-devel at lists.sourceforge.net, engine-devel at ovirt.org, "VDSM Project Development"
>>> <vdsm-devel at lists.fedorahosted.org>
>>> Sent: Sunday, June 24, 2012 10:05:45 PM
>>> Subject: Re: [vdsm] [Engine-devel] RFC: Writeup on VDSM-libstoragemgmt	integration
>>>
>>> On 06/24/2012 07:28 AM, Shu Ming wrote:
>>>> On 2012-6-23 20:40, Itamar Heim wrote:
>>>>> On 06/23/2012 03:09 AM, Andy Grover wrote:
>>>>>> On 06/22/2012 04:46 PM, Itamar Heim wrote:
>>>>>>> On 06/23/2012 02:31 AM, Andy Grover wrote:
>>>>>>>> On 06/18/2012 01:15 PM, Saggi Mizrahi wrote:
>>>>>>>>> Also, there is no mention on credentials in any part of the
>>>>>>>>> process.
>>>>>>>>> How does VDSM or the host get access to actually modify the
>>>>>>>>> storage
>>>>>>>>> array? Who holds the creds for that and how? How does the user
>>>>>>>>> set
>>>>>>>>> this up?
>>>>>>>> It seems to me more natural to have the oVirt-engine use
>>>>>>>> libstoragemgmt
>>>>>>>> directly to allocate and export a volume on the storage array,
>>>>>>>> and
>>>>>>>> then
>>>>>>>> pass this info to the vdsm on the node creating the vm. This
>>>>>>>> answers
>>>>>>>> Saggi's question about creds -- vdsm never needs array
>>>>>>>> modification
>>>>>>>> creds, it only gets handed the params needed to connect and use
>>>>>>>> the
>>>>>>>> new
>>>>>>>> block device (ip, iqn, chap, lun).
>>>>>>>>
>>>>>>>> Is this usage model made difficult or impossible by the current
>>>>>>>> software
>>>>>>>> architecture?
>>>>>>> what about live snapshots?
>>>>>> I'm not a virt guy, so extreme handwaving:
>>>>>>
>>>>>> vm X uses luns 1&   2
>>>>>>
>>>>>> engine ->   vdsm "pause vm X"
>>>>> that's pausing the VM. live snapshot isn't supposed to do so.
>>>> Tough we don't expect to do a pausing operation to the VM when live
>>>> snaphot is undergoing, the VM should be blocked on the access to
>>>> specific luns for a while.  The blocking time should be very short
>>>> to
>>>> avoid the storage IO time out in the VM.
>>> OK my mistake, we don't pause the VM during live snapshot, we block
>>> on
>>> access to the luns while snapshotting. Does this keep live snapshots
>>> working and mean ovirt-engine can use libsm to config the storage
>>> array
>>> instead of vdsm?
>>>
>>> Because that was really my main question, should we be talking about
>>> engine-libstoragemgmt integration rather than vdsm-libstoragemgmt
>>> integration.
>> for snapshotting wouldn't we want VDSM to handle the coordination of
>> the various atomic functions?
> Absolutely.  Requiring every management application (engine, etc) to
> integrate with libstoragemanagement is a win here.  We want to simplify
> working with KVM, storage, etc not require every mgmt application to
> know deep details about how to create a live VM snapshot.
>

Sorry, but not clear to me. Are you saying engine-libstoragemgmt 
integration is a win here ?
VDSM is the common factor here.. so integrating libstoragemgmt with VDSM 
helps anybody talkign with VDSM in future AFAIU.