cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Tutkowski <mike.tutkow...@solidfire.com>
Subject Re: Create VMware Datastore
Date Thu, 28 Mar 2013 21:19:48 GMT
Hi,

Thanks for taking a look at the code and commenting.

I'm including the CloudStack distribution list in replies so others can
chime in, if they'd like.  I sent the first e-mail directly to you guys
because it included an attachment and those get taken out by the CloudStack
mail system.

I put my comments below in blue.

Talk to you later!


On Thu, Mar 28, 2013 at 2:09 PM, Vladimir Popovski <
vladimir@zadarastorage.com> wrote:

> Hi Mike,
>
>
>
> Thanks for sharing the code. Let me ask you couple question and see if I
> understood it properly.
>
>
>
> Here is the very simplified sequence:
>
> 1.       It retrieves the relevant datacenter & cluster information
>
> 2.       Connects to the iSCSI target from all hosts of this cluster and
> performs a Rescan
>
> 3.       Creates a datastore with some random number on top of the 1stavailable disk
>
> Yes, totally correct.  I notice with XenServer I don't have to do so much
work, but with VMware it expects you to add the iSCSI target to each host
in the cluster.

I wrote this in a TODO, but I wonder if we should add the iSCSI target to
each iSCSI initiator of each host (right now I'm only adding it to the
first iSCSI initiator of each host).  I expect a host can have more than
one iSCSI initiator?

>
>
> Some obvious ones here (and you covered them in the TODO) are:
>
> -          It looks like this function must know on top of which volume
> it supposed to create a DataStore. So, probably some parameter there will
> help.
>
It looks like you are supposed to specify which SCSI disk to place the
Datastore on.  Once our iSCSI target has been detected, a new SCSI device
shows up.  We want to place the Datastore on that SCSI disk.  In the end,
we'll have to change this function to access several items...including the
IQN of the iSCSI target.

> -          You probably need to specify through which interface you would
> like to connect (especially for VMware).
>

Just to make sure I follow you here, are you referring to which HBA?  It
looks like VMware documentation even calls an iSCSI initiator an HBA.  We
need to add our target to that HBA and - if there are multiple iSCSI
initiators for the given host - we have to decide what to do there.

> -          It should find a relevant device(-s) and use it instead of the
> 1st available one.
>
Exactly...I'm trying to determine (not in the code yet) how to detect that
a SCSI disk exists because of an iSCSI target we added.

>
>
> So:
>
> -          How about zone-wide storage? Will you need to connect to the
> this target from all hosts of the zone (I’m not sure if your Target will be
> capable to support that many iSCSI connections/sessions).
>
Really good question.  At the moment, I am happy with a given iSCSI target
(volume/LUN) being accessible to all hosts in a cluster.

> -          Will you always expose volumes to all nodes of the cluster?
>
I believe so.  What are your thoughts about that?

> -          For zone-wide storage (if you plan to support it), it may have
> sense to perform an attachment & discovery just prior to attaching the
> volume to the instance. I thought that grantAccess/revokeAccess were
> supposed to handle it.
>
For zone wide, I think that totally makes sense.  We don't want to be
writing code that attaches, say, 1000s of hosts to the volume/LUN.  :)

> -          I’m not familiar with CS concepts, but you are retrieving
> hostDatastoreSystem from every node and, according to the code, using the
> last one. I guess the main assumption here is that all nodes in a cluster
> will have the same architecture, right?
>
That part of the code is a bit ugly.  It looks like all HostSystem objects
have access to what is called a DatastoreSystem object.  I happen to be
iterating over the hosts anyways, so I just grabbed a reference to the
DatastoreSystem object each time.  I could have only assigned it on the
first iteration, but figured it was just easier to skip the "if" logic and
assign it each time.  You might even be able to get a reference to it from
somewhere else and not assign it in the loop at all.

>
>
> Regards,
>
> -Vladimir
>
>
>
>
>
> *From:* Mike Tutkowski [mailto:mike.tutkowski@solidfire.com]
> *Sent:* Thursday, March 28, 2013 12:14 PM
> *To:* Edison Su; Vladimir Popovski
> *Subject:* Create VMware Datastore
>
>
>
> Hi Edison and Vladimir,
>
>
>
> I've been throwing together some code to create a VMware Datastore.
>
>
>
> It's not complete yet (there are three @TODOs in the attached code), but I
> just wanted to give you both a more detailed idea of where I was going with
> this.
>
>
>
> This code makes use of Steve Jin's open source VI Java API (as opposed to
> the oficial VMware-produced VI API or VI SDK).
>
>
>
> At the moment, I have a bunch of hard-coded values in the code, but I plan
> to refactor it once its functionality is all in place.
>
>
>
> Let me know if you have any comments.
>
>
>
> Edison - Since you've written the storage plug-in framework, where do you
> expect code such as what I've attached to reside?  Vladimir and I were
> hoping the storage plug-ins would only be responsible for creating
> (deleting, etc.) volumes on our storage arrays and that the framework
> within CS would take output from the plug-ins and use code such as what
> I've attached to hook up the storage to a hypervisor.
>
>
>
> Thanks!
>
>
>
> --
> *Mike Tutkowski*
>
> *Senior CloudStack Developer, SolidFire Inc.*
>
> e: mike.tutkowski@solidfire.com
>
> o: 303.746.7302
>
> Advancing the way the world uses the cloud<http://solidfire.com/solution/overview/?video=play>
> *™*
>



-- 
*Mike Tutkowski*
*Senior CloudStack Developer, SolidFire Inc.*
e: mike.tutkowski@solidfire.com
o: 303.746.7302
Advancing the way the world uses the
cloud<http://solidfire.com/solution/overview/?video=play>
*™*

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message