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
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
conf
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
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
