You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cloudstack.apache.org by Mike Tutkowski <mi...@solidfire.com> on 2013/12/27 07:18:38 UTC
VMware Question
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.tutkowski@solidfire.com
o: 303.746.7302
Advancing the way the world uses the
cloud<http://solidfire.com/solution/overview/?video=play>
*™*
Re: VMware Question
Posted by Kelven Yang <ke...@citrix.com>.
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" <mi...@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.tutkowski@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.tutkowski@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.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>
>> **
>>
>
>
>
>--
>*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>
>**
Re: VMware Question
Posted by Mike Tutkowski <mi...@solidfire.com>.
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.tutkowski@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.tutkowski@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.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>
> *™*
>
--
*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>
*™*
Re: VMware Question
Posted by Mike Tutkowski <mi...@solidfire.com>.
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.tutkowski@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.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>
*™*