I have 3 vmware ESXi 3.5 servers. Servers A & B are altering checksums on files when they are transferred in via SCP. The error is very easy to reproduce! The error or condition does not exist on server C which
is at 3.5.0, 153875. Please note that file checksums are being changed on files regardless of the size, date, etc.
What can be done to fix this issue, backing out the patch is not a solid fix.
Servers / Patch Levels:
A & B: 3.5.0, 163429
C: ---> 3.5.0, 153875
Thanks
VMware engineers.... there is a problem with patch -->163429 which I believe equates to U5 or U4. Out of frustration I rebuilt one of my problem VM hosts & did not patch. Currently its sits at patch level 153875, without any problems of file corruption or changes to MD5 checksums.
This testing was accomplished on HP dl380s Gen 4 - Which were loaded with the HP Specific ISO, please also note the HP HW is listed on the compatible HW list.
http://www.vmware.com/resources/compatibility/search.php
Please note my frustration, as we have been researching this issue for over four weeks as originally posted here:
A couple of things:
1. Why are you scp'ing files to the ESXi host? It's not a supported function thus complaining about it will likely fall on deaf ears.
2. If you're still troubled, you should open an SR with VMware, this is a support forum for users, and while the occasional VMware employee comes through the forums, it's not the 'official' way to get support.
3. Patching the host doesn't require you to scp files, again I'm confused to why exactly you're doing this.
1. I realize SCP is not supported, troll the ESXi forum threads, this author is not the first to enable SSH.
2. It doesn't change the fact the the patch 163429 changes file checksums.
3. Try to perform an install that validates checksums, the guest install will fail consistently.
4. A patch should not modify the checksums, that throws file/system integrity out the window.
5. I've spoke to VMware Tech Support, they suggested I post my issue here.
1. I realize SCP is not supported, troll the ESXi forum threads, this author is not the first to enable SSH.
2. It doesn't change the fact the the patch 163429 changes file checksums.
3. Try to perform an install that validates checksums, the guest install will fail consistently.
4. A patch should not modify the checksums, that throws file/system integrity out the window.
5. I've spoke to VMware Tech Support, they suggested I post my issue here.
Right, when you enable ssh you have to first type "unsupported" which should be the first sign that what you're going to do will be... well... unsupported.
You still haven't explained why you're scp'ing files to the ESXi host anyway, which files are having their md5sum modified?
We keep our ISOs on headless *Nix boxes, the ISOs are moved in to install guest operating systems. Any files that are moved in via SCP are altered. Just so its clear VMhosts that are not up to patch level 163429 do not alter files.
Have you used the datastore browser function to upload the file, or the vifs.pl ( part of the RCLI ) to transfer files to the host? If so did the md5sum fingerprint change?