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