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

On 06/25/2012 10:14 AM, 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(a)redhat.com&gt; >>>> To: "Shu Ming" <shuming(a)linux.vnet.ibm.com&gt; >>>> Cc: libstoragemgmt-devel(a)lists.sourceforge.net, >>>> engine-devel(a)ovirt.org, "VDSM Project Development" >>>> <vdsm-devel(a)lists.fedorahosted.org&gt; >>>> 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 ? I may be misssing something, but afaiu you need to ask the guest to perform the quiesce, and i'm sure the storage array can't do that.