Deploy_ova hitting error at uploading vmdk file

[bharatks]

Trying to use deploy_ova script, but hitting a road blocker at upload_disk method. OVA file is proper as I'm able to manually deploy it on esx. Please help.

Error: File "C:\Python27\lib\urllib2.py", line 556, in http_error_default raise HTTPError(req.get_full_url(), code, msg, hdrs, fp) urllib2.HTTPError: HTTP Error 500: Internal Server Error

esx hostd.log: 2017-08-09T11:50:56.998Z info hostd[FFFC2A70] [Originator@6876 sub=Httpnfcsvc] [HttpNfcServer] File: /ha-nfc/527b9342-9054-a468-0389-443496b724db/disk-0.vmdk 2017-08-09T11:50:56.998Z info hostd[793F3B70] [Originator@6876 sub=Httpnfcsvc] [DiskUploadWorker] POST request /ha-nfc/527b9342-9054-a468-0389-443496b724db/disk-0.vmdk 2017-08-09T11:50:57.011Z error hostd[793F3B70] [Originator@6876 sub=Httpnfcsvc] [DiskUploadWorker] Stream reader initialization failed: Not a supported disk format (invalid sparse VMDK header). 2017-08-09T11:50:57.290Z info hostd[79580B70] [Originator@6876 sub=Hostsvc.DatastoreSystem] RefreshVdiskDatastores: Done refreshing datastores.

[prziborowski]

It seems like it will get this error if the header doesn't start with what it expects ('KDMV', backwards of VMDK). It is possible that the script, or tarfile python module is not behaving well on windows (I only tested on linux and macos). I'll have to give that a try, but it might take me some time to get such an environment set up.

[bharatks]

I may be wrong, but if i deploy the ova manually on esx it works, is it possible that reading of header could be hit even when installing manually?

Is there a workaround? Or possibly a way of confirming that header is causing this issue?

[prziborowski]

Since you can deploy manually, I am assuming it is either a problem with the deploy_ova.py script or the tarfile module it also relies on.

The only workaround that comes to mind to try is extracting the ova, and using deploy_ovf.py script to deploy (assuming that one works). ova is basically a tar file, so any program that can extract tar (7z, winrar, winzip...) could extract an ova (you may have to rename it for that to work).

[bharatks]

Extracted the ova file and it had three files .mf, .ovf and .vmdk.gz. Is there a possibility .vmdk.gz could have resulted in error. Because it was searching for .vmdk, while the file was as .vmdk.gz.

I will quickly give a try using deploy_ovf script and get back to you on this.

[bharatks]

I had to extract .vmdk file from .vmdk.gz. Then only deploy_ovf script worked with little changes w.r.t curl and it was deployed successfully.

Deploy_ova script resulted in error because ova file had .vmdk.gz instead of .vmdk - Could this be a case?

[bharatks]

Thank you @prziborowski for directing me to use deploy_ovf script. Based on deploy_ovf script output, I'm suspecting the issue is because of .vmdk.gz file. I have passed the extracted file (.ovf and .vmdk.gz) to deploy_ovf script and it resulted in same error as reported in deploy_ova script. See execution details below Please help/guide me in moving ahead with deploy_ova script by overcoming .vmdk.gz file?

Execution logs: $ python deploy_ovf.py -s -u root -p *** -v "C:\Users\admin\ovafile\Appliance-x86_64-20170802-39-disk1.vmdk.gz" -f "C:\Users\admin\ovafile\Appliance-x86_64-20170802-39.ovf" -----------URL1--------------- https://10.71.71.138/ha-nfc/52048c52-5c49-1b8d-5ee5-921c5e74efa1/disk-0.vmdk ---------------------URL2-----------http://10.71.71.138/ha-nfc/52048c52-5c49-1b8d-5ee5-921c5e74efa1/disk-0.vmdk Not a supported disk format (invalid sparse VMDK header)**

Esx logs: 2017-08-09T16:53:06.256Z info hostd[7ACC1B70] [Originator@6876 sub=Httpnfcsvc] [DiskUploadWorker] POST request /ha-nfc/52048c52-5c49-1b8d-5ee5-921c5e74efa1/disk-0.vmdk 2017-08-09T16:53:06.276Z error hostd[7ACC1B70] [Originator@6876 sub=Httpnfcsvc] [DiskUploadWorker] Stream reader initialization failed: Not a supported disk format (invalid sparse VMDK header).

[prziborowski]

Thank you for that information. I was not aware that the vmdk file could be compressed as a gzip file. deploy_ova.py is going to send it over as-is, and likely other clients are extracting the contents and sending that over the wire. That is my guess.

[bharatks]

Thanks a lot for your quick responses. Finally i was able to pinpoint on the issue. Its is because of compressed *.vmdk file. We have used the ovftool to create ova file., in which we provide an option to compress. Compression is required, if compression is not used then ova file will be too large.

cmd: ovftool --compress=9 -tt=OVA $vmxFile $ovfname.ova

With compression option in place. Is there a way to handle this kind of ova file which includes *.vmdk.gz, ovf file?