SSH is disabled by default on the ESXi host and is 'unsupported' by Vmware.
 I've noticed this behavior as well, where the command succeeds but it is
not reflected in the return code.  You can enable SSH by going to the ESXi
console.  If you go the NFS route make sure to use the address of the NFS on
the exporting computer rather than address of the mount of the ESXi host or
you will run into the same problems if SSH is not enabled.  The idea that
the VCL developers have expressed is that using an NFS setup distributes the
workload among multiple drives which improves performance.

On Sat, May 29, 2010 at 2:21 PM, My LinuxHAList <>wrote:

> Replying to my own thread:
> >> (2) Any updates from an old issue:
> >>
> >>   The target is ESXi 3.5 host.
> To get familiarity of the software, I've been using ESXi 3.5 local
> disk storage; so I specify the datastore to be ESXi's IP:/PATH.
> Hence, during image capture phase, the ssh commands seem to be going
> off to the ESXi host.
> The command seems to succeed all the time; however the return code is
> mostly 255 and sometimes 0.
> It's weird because I'm certain that commands being sent were
> successful; I reproduced it manually the weird behavior
> ( similar to
> )
> I take that this is an sshd oddity on ESXi host.
> I saw entries of "localdisk" or "networkdisk" on vmprofile. Not sure
> how they are used.
> Is the setup of ESXi with local disk considered to be a supported option ?
> If so, how would I get around the sshd oddity for the ESXi's
> IP:/DATASTOREPATH issues during image capture ? Or I should do things
> differently for localdisk.
> I'll switch to NFS so that I can move forward.
> I wish to get some understanding on potentially what I did wrong or
> what I did was simply an "unsupported" setup.
> Thanks again.

Reply via email to