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 wan
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 t
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
>
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
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 belie
