Hello,
i test an ESXi 6.0 (free license), hosting an OS X 10.10.x guest and have to implement a VM level backup workflow, as plain as possible: cold backup, no snapshots, entire VM.
Cloning has to happen script based and between local datastores (cold backup, performance) and cloning to a template is no option, the restore has immediately to be ready for operation.
Standard approach obviously:
vmkfstools -i source_path destination_path -d disk_format -a adapter_type
But when raising verbosity the following errors thrown upon execution always show up:
1) Adapter type:
DDB: "adapterType" = "ide" (was "lsilogic")
2) disk geometry:
DDB: "geometry.cylinders" = "16383" (was "10443")
DDB: "geometry.heads" = "16" (was "255")
3) cloning -flat.vmdk:
DISKLIB-LINK : DiskLinkNativeVmfsCloneExisting: Failed to create native clone. (24).
DISKLIB-LIB_CLONE : Failed to create native clone on destination handle : The specified feature is not supported by this version (24).
@1) Attempts to overrule this behaviour by forcing
-a "lsilogic"
gets ignored by vmkfstools (throws: "Option --adaptertype is deprecated and hence will be ignored").
This feature is important, because i don't want to postprocess the restore.
@2) More of an oddity here, obviously no real issue: monitoring disk geometry of original disk and cloned disk reports the exact same geometry, but both reported parameters are different from those reported by vmkfstools upon its operation...
@3) The clone process happens between 2 locally attached datastores, may this be relevant here?
Could anyone hint me how to tackle the adapter issue and the cloning of the *-flat.vmdk disk? Looks like a showstopper for the project otherwise...
Best regards
Hello,
in the meantime i dug deeper into the documentation of the API and now am not so sure that the corrupt clone is linked to what the cited log report had to tell, which simply may be the failure report of a specific cloning method always attempted by vmkfstools for any application...
@1: as stated by the log file: the adapter feature is deprecated.
I checked another VM set up from scratch, where i configured the controller to be "LSILogic". A cloning of the VM with the same method as before, but omitting the adapter switch left the controller type untouched this time... Not sure yet why, but obviously the shift from "lsilogic" to "ide" upon cloning observed the last time is not a programmatic thing to be expected from vmkfstools (> ESXi6) in general...
@3) :
1) obviously vmkfstools (in general/here?) attempts to offload the cloning by default, no matter the present underlying hardware that actually is available.
Obviously also the presence of linked clones is assumed/checked, because this could provide options to realise the linked clones via native array snapshots.
Both would speed up the cloning process substantially...
2) Therefore the error here may simply be the documentation that ESXi's built in "VAAI NAS plugin"'s attempts to offload the cloning process (or the related transfers rather) away from the VMKernel's network stack to an array ("hosting" the destination of the clone) failed, due to insufficient hardware, which is perfectly expected, since both datastores are simple local HDDs.
If that holds, the cloning process still should have succeeded, independent from that log file entry.
So reasons for the corrupt clone must be looked up somewhere else, if all my reading above is correct.
Could somebody with more insight confirm this interpretation?
Would be great...
Best...
