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

[Ryan Harper]

* 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.


> > 
> > Thanks -- Regards -- Andy
> > _______________________________________________
> > vdsm-devel mailing list
> > vdsm-devel at lists.fedorahosted.org
> > https://fedorahosted.org/mailman/listinfo/vdsm-devel
> > 
> _______________________________________________
> vdsm-devel mailing list
> vdsm-devel at lists.fedorahosted.org
> https://fedorahosted.org/mailman/listinfo/vdsm-devel

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