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

Ryan Harper ryanh at us.ibm.com
Mon Jun 25 15:17:10 UTC 2012


* Deepak C Shetty <deepakcs at linux.vnet.ibm.com> [2012-06-25 10:14]:
> 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 ?

Sorry if I wasn't clear.  To answer your question: No. 

The mgmt app should *NOT* have to learn all of the ins and outs of the
end-point storage and the management of it.

> VDSM is the common factor here.. so integrating libstoragemgmt with
> VDSM helps anybody talkign with VDSM in future AFAIU.

Yes.  100% agree.


-- 
Ryan Harper
Software Engineer; Linux Technology Center
IBM Corp., Austin, Tx
ryanh at us.ibm.com




More information about the Devel mailing list