We need a more intelligent way to detect real ³local storage² on the host. The logic was intended for auto-discovery of attached local storage(s) on the ESXi host.
Kelven On 12/27/13, 5:23 PM, "Mike Tutkowski" <mike.tutkow...@solidfire.com> wrote: >Investigating this a bit more today, I came to the conclusion that the NFS >datastore was not being added to CloudStack as primary storage. > >It appears I must have had one more dynamically created iSCSI-based >datastore that was being added to CloudStack as primary storage. > >I went ahead and checked in a fix to stop VMware logic from adding these >kinds (dynamically created) of datastores to CloudStack as primary >storage. > > >On Thu, Dec 26, 2013 at 11:42 PM, Mike Tutkowski < >mike.tutkow...@solidfire.com> wrote: > >> I can see the problem is in HostMO.getLocalDatastoreOnHost. >> >> My datastore (as well as the NFS datastore that was automatically >>created >> to download an ISO) shows up as DatastoreSummary.isMultipleHostAccess == >> false (along with a couple other fields) and this qualifies it as >>"local" >> storage. >> >> I believe I've never seen this before because vCenter Server probably >> changes DatastoreSummary.isMultipleHostAccess to true when you have more >> than one host in the cluster that can access the datastore (I usually >>have >> more than one host in a VMware cluster, but don't right now). >> >> It seems DatastoreSummary.isMultipleHostAccess is not sufficient to use >>to >> declare if something is local storage. >> >> >> On Thu, Dec 26, 2013 at 11:18 PM, Mike Tutkowski < >> mike.tutkow...@solidfire.com> wrote: >> >>> Hi, >>> >>> I have a question about the initializeLocalStorage method in >>> VmwareResource. >>> >>> When an ISO is downloaded from secondary storage to an ESX host, we >>> create an NFS datastore on the host. >>> >>> When the host connects to a management server, initializeLocalStorage >>>is >>> run and this method sees the new NFS datastore as new local storage and >>> this ends up being added as a new primary storage in CloudStack. >>> >>> I doubt this behavior is intended. >>> >>> I actually have a similar problem with how initializeLocalStorage >>>treats >>> iSCSI-based datastores that I dynamically create. >>> >>> In my case, a user executes a Disk Offering based on my plug-in. An >>> iSCSI-based datastore (with a single VMDK file in it) is dynamically >>> created and made accessible to all hosts in the cluster (although of >>>course >>> only a single host is running the VM that has the VMDK file attached >>>as a >>> data disk). >>> >>> Later on, if the host reconnects to a management server, >>> initializeLocalStorage sees the new datastore as new local storage and >>> tells the management server to add it to CloudStack as a new primary >>> storage, which is not ideal. >>> >>> Any thoughts from people on a good way to stop this behavior? When I >>> create a datastore, can I tag it a certain way and then look for that >>>tag >>> in initializeLocalStorage? >>> >>> Thanks! >>> >>> -- >>> *Mike Tutkowski* >>> *Senior CloudStack Developer, SolidFire Inc.* >>> e: mike.tutkow...@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.tutkow...@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.tutkow...@solidfire.com >o: 303.746.7302 >Advancing the way the world uses the >cloud<http://solidfire.com/solution/overview/?video=play> >**
