Re: VMware Question

[Mike Tutkowski]

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



-- 
*Mike Tutkowski*
*Senior CloudStack Developer, SolidFire Inc.*
e: mike.tutkow...@solidfire.com
o: 303.746.7302
Advancing the way the world uses the
cloud
*™*

Re: VMware Question

[Mike Tutkowski]

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
>> *™*
>>
>
>
>
> --
> *Mike Tutkowski*
> *Senior CloudStack Developer, SolidFire Inc.*
> e: mike.tutkow...@solidfire.com
> o: 303.746.7302
> Advancing the way the world uses the 
> cloud
> *™*
>



-- 
*Mike Tutkowski*
*Senior CloudStack Developer, SolidFire Inc.*
e: mike.tutkow...@solidfire.com
o: 303.746.7302
Advancing the way the world uses the
cloud
*™*

Re: VMware Question

[Kelven Yang]

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" 
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
>>> **
>>>
>>
>>
>>
>> --
>> *Mike Tutkowski*
>> *Senior CloudStack Developer, SolidFire Inc.*
>> e: mike.tutkow...@solidfire.com
>> o: 303.746.7302
>> Advancing the way the world uses the
>>cloud
>> **
>>
>
>
>
>-- 
>*Mike Tutkowski*
>*Senior CloudStack Developer, SolidFire Inc.*
>e: mike.tutkow...@solidfire.com
>o: 303.746.7302
>Advancing the way the world uses the
>cloud
>**

Re: [VMware] Question about snapshots

[Mike Tutkowski]

Actually, I re-ran this scenario and this is what I observed:

ROOT-1.vmdk
^
|
ROOT-1-01.vmdk (Snapshot 1)

I take another snapshot of the VM:

ROOT-1.vmdk
^
|
ROOT-1-01.vmdk (Snapshot 1)
^
|
ROOT-1-02.vmdk (Snapshot 2)

Let's say I revert to Snapshot 1.

I see the following behavior:

ROOT-1.vmdk
^
|
ROOT-2-01.vmdk ROOT-2-03.vmdk

(ROOT-2-01.vmdk and ROOT-2-03.vmdk are children of ROOT-1.vmdk.)

This brings up a couple questions:

1) If those two snapshots are siblings, then why in the GUI do I see that
one is listed as the parent of the other?

2) What happened to the data that was stored in ROOT-1-02.vmdk? What
happens if I try to revert to Snapshot 2? That snapshot no longer appears
to be backed by a file on the datastore.

Thanks!


On Wed, Apr 23, 2014 at 7:21 PM, Mike Tutkowski <
mike.tutkow...@solidfire.com> wrote:

> Hi,
>
> I was working again with VMware snapshots today to test this functionality
> against CloudStack's managed storage.
>
> I have a question that perhaps one of you can answer:
>
> Let's say I have a root volume called ROOT-1.vmdk.
>
> I take a snapshot of the applicable VM, which produces the following
> configuration for its root volume:
>
> ROOT-1.vmdk
> ^
> |
> ROOT-1-01.vmdk (Snapshot 1)
>
> I take another snapshot of the VM:
>
> ROOT-1.vmdk
> ^
> |
> ROOT-1-01.vmdk (Snapshot 1)
> ^
> |
> ROOT-1-02.vmdk (Snapshot 2)
>
> Let's say I revert to Snapshot 1.
>
> I see the following behavior:
>
> ROOT-1.vmdk
> ^
> |
> ROOT-2-02.vmdk (Snapshot 2) ROOT-2-03.vmdk (Snapshot 1)
>
> From this, it appears both Snapshot 1 and Snapshot 2 have the same parent
> now.
>
> The only way I see this making sense is if the data in ROOT-1-01.vmdk
> was merged into ROOT-1-02.vmdk.
>
> Is this what happens in this situation?
>
> 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
> *(tm)*
>



-- 
*Mike Tutkowski*
*Senior CloudStack Developer, SolidFire Inc.*
e: mike.tutkow...@solidfire.com
o: 303.746.7302
Advancing the way the world uses the
cloud
*(tm)*

Re: [VMware] Question about snapshots

[Mike Tutkowski]

You know, the more I think about how VMware implemented this, the more it
becomes clear what's going on under the hood.

The -flat and -delta files contain the data and their corresponding VMDK
files contain metadata like who your parent, if any, is.

Then the VMSN files come into play when you want to revert to a snapshot. I
noticed the following info in one of those files:

ide0:1.fileName = "ROOT-11-01.vmdk"

So, if I were to revert to this snapshot, a new VMDK file would be created
that would use ROOT-11-01.vmdk as its parent.

That makes sense.


On Wed, Apr 23, 2014 at 11:32 PM, Mike Tutkowski <
mike.tutkow...@solidfire.com> wrote:

> Actually, I re-ran this scenario and this is what I observed:
>
> ROOT-1.vmdk
> ^
> |
> ROOT-1-01.vmdk (Snapshot 1)
>
> I take another snapshot of the VM:
>
> ROOT-1.vmdk
> ^
> |
> ROOT-1-01.vmdk (Snapshot 1)
> ^
> |
> ROOT-1-02.vmdk (Snapshot 2)
>
> Let's say I revert to Snapshot 1.
>
> I see the following behavior:
>
> ROOT-1.vmdk
> ^
> |
> ROOT-2-01.vmdk ROOT-2-03.vmdk
>
> (ROOT-2-01.vmdk and ROOT-2-03.vmdk are children of ROOT-1.vmdk.)
>
> This brings up a couple questions:
>
> 1) If those two snapshots are siblings, then why in the GUI do I see that
> one is listed as the parent of the other?
>
> 2) What happened to the data that was stored in ROOT-1-02.vmdk? What
> happens if I try to revert to Snapshot 2? That snapshot no longer appears
> to be backed by a file on the datastore.
>
> Thanks!
>
>
> On Wed, Apr 23, 2014 at 7:21 PM, Mike Tutkowski <
> mike.tutkow...@solidfire.com> wrote:
>
>> Hi,
>>
>> I was working again with VMware snapshots today to test this
>> functionality against CloudStack's managed storage.
>>
>> I have a question that perhaps one of you can answer:
>>
>> Let's say I have a root volume called ROOT-1.vmdk.
>>
>> I take a snapshot of the applicable VM, which produces the following
>> configuration for its root volume:
>>
>> ROOT-1.vmdk
>> ^
>> |
>> ROOT-1-01.vmdk (Snapshot 1)
>>
>> I take another snapshot of the VM:
>>
>> ROOT-1.vmdk
>> ^
>> |
>> ROOT-1-01.vmdk (Snapshot 1)
>> ^
>> |
>> ROOT-1-02.vmdk (Snapshot 2)
>>
>> Let's say I revert to Snapshot 1.
>>
>> I see the following behavior:
>>
>> ROOT-1.vmdk
>> ^
>> |
>> ROOT-2-02.vmdk (Snapshot 2) ROOT-2-03.vmdk (Snapshot 1)
>>
>> From this, it appears both Snapshot 1 and Snapshot 2 have the same parent
>> now.
>>
>> The only way I see this making sense is if the data in ROOT-1-01.vmdk
>> was merged into ROOT-1-02.vmdk.
>>
>> Is this what happens in this situation?
>>
>> 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
>> *(tm)*
>>
>
>
>
> --
> *Mike Tutkowski*
> *Senior CloudStack Developer, SolidFire Inc.*
> e: mike.tutkow...@solidfire.com
> o: 303.746.7302
> Advancing the way the world uses the 
> cloud
> *(tm)*
>



-- 
*Mike Tutkowski*
*Senior CloudStack Developer, SolidFire Inc.*
e: mike.tutkow...@solidfire.com
o: 303.746.7302
Advancing the way the world uses the
cloud
*(tm)*