Failed to clone the volume mounted on '/' from <source>

[ahachenberg]

I'm having a problem with a P2V that fails at 3% with the error code "Failed to clone the volume mounted on '/' from server.domain.tld"

After applying the DNS suffix to the helper configuration I was able to

get to 4% but then the same error occured. Did i do something else wrong? I

tried setting up the P2V after applying the DNS suffix fix with source

information as just the DNS name, no suffix and then the FQDN, and even

the IP. all fail.

my source machine is SLES 9. if that makes any difference?

attached log

PS. by request i made this a new post. I originally posted this as a response to this thread:http://communities.vmware.com/message/1341411#1341411

[vmweathers]

hi again. Can you please post the helper log? It's deeply embedded in the log bundle that you get when you export the logs from the task. Just keep going down the temp directory zip files until you can no longer do so, then go into var/log/... and grab the converter helper log file.

(If your question has been resolved please mark the answers as "Helpful" or "Correct".)

[vmweathers]

Actually, I don't need the helper logs for now. The agent log has the actual error embedded in the Fault it received from the Helper VM:

\[#5\] Warning: Permanently added 'kronosdb.seton.org,10.20.13.232' (RSA) to the list of known hosts.

\[#5\] tar: ./dev/log: socket ignored

\[#5\] Received disconnect from UNKNOWN: 2: Bad packet length 1797553480.

\[#5\] tar: Unexpected EOF in archive

\[#5\] tar: Unexpected EOF in archive

\[#5\] tar: Error is not recoverable: exiting now

Here is the interesting line:

Received disconnect from UNKNOWN: 2: Bad packet length 1797553480.

This error is printed by the ssh client in the helper VM. However, the following portion of the message was actually sent from the ssh server (the source machine) to the ssh client: 2: Bad packet length 1797553480.

So, there is a problem in the ssh communication channel between the Helper and the source. I would look for logs in the source about ssh errros. Also you could use wireshark to capture the ssh traffic between the Helper VM and the source, and then look at the ssh packets to see if there is an obvious problem in the last few ssh packets. Unfortunately, it seems that wireshark does not provide a facility for decrypting SSH packets (it exists for SSL), and specifying none as the cipher with SSH is generally not supported.

BTW, can you post the exact version of the source's ssh server?

Unfortunately, I don't see how we'll be of any help in solving this problem, it's some bug in either the openssh v5.1p1 client the Helper VM is using, or the ssh server on the source.

(If your question has been resolved please mark the answers as "Helpful" or "Correct".)

[ahachenberg]

Vmweathers,

Thanks for your continued assistance and detailed input. Here is a copy of the SSH version request from the source machine: "ssh -V

OpenSSH_3.8p1, SSH protocols 1.5/2.0, OpenSSL 0.9.7d 17 Mar 2004"

....Interestingly enough our test environment for this server works perfectly with a P2V and is running the same version of SSH. We have two SLES servers running Oracle. The test server P2V'd with no problem so since they are running the same version of SSH I'm hoping the difference is a configuration of the SSH server.

[vmweathers]

If you cannot find differences in the sshd_config files, then you might try downloading and installing a new version of sshd. You can probably just build a new one and temporarily replace the old binary with the new one.

(If your question has been resolved please mark the answers as "Helpful" or "Correct".)

[ahachenberg]

I had a colleague of mine run a differencing check on sshd_config files of a server that worked and the server that's giving me this error. There was only one difference reported:

Working server:

#Protocol 2,1

This server (non working)

Protocol 2,1

So, the server that's throwing the error has 'Protocol 2,1' commented out. I'll try changing that and report my findings. In the mean time, do you have any knowledge of turing this on/off in relation to VMWAre Converter P2V's?

thanks!