Vmware Download File Http Error 500

[Marguerite Gilbeau]

Onething I love about the VMware Community is the constant sharing of knowledge and information on a regular basis. I always enjoy discovering new tricks and tidbits from the community, especially as it helps me refine my own knowledge and understanding of a given technology or solution.

which is actually not unique to a Nested environment. In fact, this cryptic error message was observed even in the first release of vSphere with Tanzu which used to be called vSphere with Kubernetes with the release of vSphere 7.0 release.

Although Paul's conclusion on why his fixed work was not exactly correct, it was the fix itself that I was actually most interested in. Even with the initial vSphere 7.0 release, I had assumed this was just a cosmetic vCenter Server error message. It was not ideal, but like many other customers, I just ignored it as the enablement of Workload Management was still successful.

What helped me connect the dots was the fact that Paul solved the problem by disabling the ESXi firewall, which meant this was actually an ESXi issue. Given this was related to the OVF deployment, I immediately knew what this was actually referring to and is related to an earlier blog post I had shared about a new feature that would allow ESXi to "pull" remote OVF/OVA files from a HTTP(s) endpoint. In this case, it was not OVFTool driving the deployment but rather vCenter Server and the Content Library service, which is also responsible for OVF/OVA deployments.

It turns out that as part of deploying the Supervisor VMs, instead of using the typical "push" method for uploading an OVA, vCenter is instructing the ESXi host to "pull" the OVA files remotely which are actually hosted on the vCenter Server Appliance (VCSA) itself. What ends up happening is that because ESXi does not have the correct port in which the OVA is hosted on the VCSA, the "pull" method fails and it automatically falls back to the old "push" method. This is why you see the error message and then progress is immediately progressing.

It took a bit more digging to figure out what port VCSA was actually serving the OVA file, because I would have assumed it was on 443. It turns out, it is being served on 5480 which is also the same port for hosting the Virtual Appliance Management Interface (VAMI), which I suspect is due to the fact that it has a lighthtpd running. The way I figured out 5480 was actually because I had been spending some time with vSphere with Tanzu configuration file which is stored under /etc/vmware/wcp/wcpsvc.yaml and there is a commented out configuration mentioning where the WCP Agent VM which is another word for Supervisor VM:

As you can see from the example, it defaults to 5480. Looking at the URL path, I was able to determine where these files actually lived on the VCSA filesystem and I found there was a symlink from /opt/vmware/share/htdocs/wcpagent pointing to /storage/lifecycle/vmware-wcp/wcpagent which is where the Supervisor VM (Photon) OVAs are stored on the VCSA.

To actually confirm my suspicion, we need to configure our ESXi host to allow for outbound connectivity to 5480. To do that, I had to use one of my older blog articles back in 2011 on how to create a custom ESXi firewall rule, since 5480 was not one of the default ports that is available for configuration.

So now that we know why this happening, the custom ESXi firewall rule is not really a good solution. Since we do not allow for any custom firewall policies in ESXi, customers must create this XML file and then package it up into a custom VIB for any type of automated and scalable solution. It is also not ideal because the optimized deployment workflow should just work out of the box and if we do require ports opened on ESXi, it should be done as part of the service and then disabled when not required.

Lastly, I did find it strange that we would host the OVA files behind something other than 443 which is pretty common when serving HTTP(s) files. The VCSA does have another web server which I thought would have made more sense, which is the main landing page and is served on 443. Since the OVA files is not actually stored in the current htdocs folder but rather symlinked. A quicker and more ideal permanent solution is to just symlink the OVA files to VCSA primary htdocs directory and then update the OVA URL in the wcpsvc.yaml configuration file. The other really nice benefit is that you do not have to make any changes to the ESXi firewall nor mess with custom firewall policies.

So there you have it, the reason and solution to why the HTTP 404 error is showing up when enabling vSphere with Tanzu. I definitely will be sharing this analysis with the Engineering team in case they were not aware and hopefully this will be resolved in a future update and this error will no longer show up and the system will automatically do the right thing.

Nice, many of us where intrigued by this error, specially while trying to troubleshoot why deployment would not work.

Now in your snippet for firewall rule you put porttype "src", but if this is the ESXi consuming the file, wouldn't it be "dst" ?

Sorry, sir.

It was my mistake in confusing situations.

The remote file download and OVF deployment fail on the first attempt, but the OVF deployment is attempted again and succeeds.

The supervisor node configuration fails, but this seems to be a different issue.

It works fine.

William is Senior Staff Solution Architect in the VMware Cloud Foundation (VCF) Division at Broadcom. He focuses on Cloud Native, Automation, Integration and Operation for both VMware vSphere Foundation (VVF) & VMware Cloud Foundation (VCF) across Private, Hybrid and Public Cloud

I am running a vcenter server, and created a desktop shortcut for the vsphere webclient login, it works well, but after a certain time, around 2 weeks the desktop shortcut will no longer work, and instead display a http error 403, if i mnually enter the FQDN of my vCenter Server i can connect to the vSphere webclient no problem, is there a way to fix this, so i don't have to create a new desktop shortcut every few weeks ?

Its replication of several VMs in VMware. The replication will run fine for days then for no apparent reason it fails with many different errors. A reboot sorted it for the first couple of times but now its more frequent. Also, its a new backup server and new ESX servers.

Can you try telnetting from the Veeam host to your vCenter server on port 443? Does it connect? If not, troubleshoot network connection issues and or problems with the vCenter server (can you run the vmware client and connect to the vCenter server)

Before clicking on "Play virtual Machine", click on "Edit virtual machine settings" -> in the "Hardware" tab, select "Network Adapter" -> In the settings displayed, select "Host-only: A private network shared with the host" option -> click ok.

Thank you for posting your query in the PSC. This looks like an inactive post and hence, we suggest you create a new post for your query. Click on the Write Post button here. Once created, please reply back here with the URL of the new post.

VmWare: the solution described by NARAYANA is the way to go. Just switch your Network Adapter to Host-Only option. This will allow you to run your VM even without internet connection after the first launch. Also, sometimes when you are trying to add a new VM, it throws an error that SHA1 does not match manifest. Go to the folder, where your downloaded VM files are, simply delete the .mf file and try again.

VirtualBox: Bridged Adapter network setting is the only one that worked for me. You may notice that in some networks it doesn't work - only showing :9080 URL after VM starts up. In order to solve it, you need to expand Advanced settings on the bridged network adapter, and indicate the real physical address (MAC) of the network you are in (Settings->Wi-fi or Ethernet->'Name of the active network connection' on Windows or similar on other OS), instead of a generated one.

Hi, this is the same issue I am having on my mac using VirtualBox, but expanding the advanced settings shows the (MAC) address as a set of numbers which are not editable (greyed out) - unless I power off the console. So after powering off the console, I grabbed the wifi ip address from settings>network on my mac and though I actually have no idea what I am doing, (just carefully following the instructions provided), when re started, the console did then provide a full IP with port num :9080. Unfortunately when I put this into any browser no page loaded. The browser simply timed out. Repeat attempts have not yielded the full ip url in the console again, just the original error with port num and no IP.

Thanks Miki - actually - I am not trying to access the Customer Service Foundation course - rather the System Architect Essentials -architect-essentials . I just searched for this error and found this thread - sorry I should have clarified I was on a different course.

I was picking my hair about this for some time and was looking through all different Tanzu articles on the web looking for an answer. All I knew was that the error was related to the Content Library URL: -content.vmware.com/v2/latest/lib.json

3a8082e126