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

[Shu Ming]

On 2012-6-25 22:14, Deepak C Shetty wrote:
> On 06/25/2012 07:47 AM, Shu Ming wrote:
>> On 2012-6-25 10:10, Andrew Cathrow wrote:
>>>
>>> ----- 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?
>>
>> I think VDSM-libstoragemgmt will let the storage array itself to make 
>> the snapshot and handle the coordination of the various atomic 
>> functions. VDSM should be blocked on the following access to the 
>> specific luns which are under snapshotting.
>
> I kind of agree. If snapshot is being done at the array level, then 
> the array takes care of quiesing the I/O, taking the snapshot and 
> allowing the I/O, why does VDSM have to worry about anything here, it 
> should all happen transparently for VDSM, isnt it ?
The only issue is the quiesing may time out the VDSM io functions if it 
takes a non-trivial time.  Not sure if VDSM can handle all the time out 
gracefully.



-- 
Shu Ming <shuming at linux.vnet.ibm.com>
IBM China Systems and Technology Laboratory