i have install a new enviroment with this software version:
Esxi --> 6.7u3
Vcenter --> 6.7u3
Vcloud director --> 9.7.0.3
NSX-T --> 2.5
I have complete setup of NSX-T and Vcenter but i when to try join into vcloud director i receive this error "Could not register NSX Manger - /api/2.0/global/heartbeat, error code 98"
I tried to join from html5 or java interface but i receive same error
ALLenduser communication goes to the vCloud Cells.
You should check the "vCloud Directory Security" whitepaper, Chapter 5. The latest document i could find was for 9.5, but most this also apply to 9.7 / 10.
- Open only port 443 to the internet (if you have ConsoleProxy on the same ip, also the IP of consoleproxy (e.g. 8443) and use a firewall (see: Blocking Malicious Traffic)
- Always use valid certificates
- Enforce strong passwords on all users
- If possible use a WAF and prevent access to administrative URLs (Admin Portal, Admin API Endpoints)
this is not a technical question, instead i'd like to know you opinion about the requirement if a "CloudInit" compatible METADATA Service in vCloud Director.
For all who don't know what i am talking about:
All large public cloud provider (AWS, Azure) and Openstack providing a METADATA service which can access (mainly) via IP. All implementation i know uses "169.254.169.254" to enable access to the VM/instance specific METADATA.
Inside all linux "cloud ready" images you will find "CloudInit" which querys this metadata service to configure itself during boot (Hostname, IP, SSH keys, UserScripts etc). It is also possible to query information about the instance itself (which region, VM flavor, network, image name etc).
Whithin vCloud Director there is no such service avaiable. You can access the Metadata of a VM via vCloud API, but this requires access from the VM to the vCloud API and it also requires authentication to the vCloud API. The second way is to use OVF properties of VMs. But these properites must be set manual for each VM/properites and requires the VM to be powered off. Also there is no CloudInit provider for both ways.
I already spoke to many VMware representives (VMworld 2019 EU) regarding the topic but nobody is aware of this.
So my question is:
Is there really nobody who likes to have this features?
Test AMQP Broker Connection: Failed [ cce57418-888e-4137-b970-86cece744637 ] ACCESS_REFUSED - Login was refused using authentication mechanism PLAIN. For details see the broker logfile.
In the Flex UI to test I get a successful connection but when I browse to the vROPS Tenant App in vCloud Director I get this error:
Failed to get vRealize Operation Tennat App for vCloud Director endpoint!! Looks like AMQP Settings Invalid.
I don't think it's RabbitMQ, vCD connects to it even though the HTML5 UI test button doesn't work as expected.
Maybe the vROPS vCloud Director MP but I've got it configured with the AMQP password, not really sure where vROPS Tenant App is pulling it's AMQP settings from as it doesn't ask in the OVF deployment and I'm not seeing anything in the Tenant App UI to configure it.
We have a similar issue when we tested the connectivity between VCD 10 and Rabbit MQ with the same error, it turns out there is a bug with the HTML5 interface, we used the Flash UI and the communication was reported as OK. May be this info can help you.
With all due respect, your answer is (a) not correct; and (b) not helpful.
Nowhere is it mentioned that deploying vCD through ESXi is not supported. When you apply some logic to it, why would it not be supported? What would the resultant VM run on? Why the ESXi host itself! Whether I deploy through ESXi or vCenter, it should not make a difference.
Anyway, I finally got around to resolving this myself. So for those who may be stuck deploying any OVA/OVF directly to an ESXi host, this official VMware ovftool document says:
"If you are deploying with the ovftool command targeting an ESXi host, you must “inject” the parameters into the resulting VM when it is powered on. This is because the ESXi host lacks a cache to store the OVF parameters, as with vCenter Server. Therefore, you must use the --X:injectOvfEnv debug option with the --poweron flag in the command line"
To be clear, the hostname on the actual management appliance does not need to be the same as the public FQDN. In our environment we use our internal naming scheme to assign hostnames to the appliances and everything works fine from the Internet.
The trickiest thing I've found with vCAv is DNS resolution (depending if you're using split DNS) and the firewall rules depending if you deploy the components in the VMware recommended zones (trusted for all components except for the Tunnel which lives in the DMZ).
To the OP - are you still experiencing issues with your deployment?
I know they aren't listed in the Product Interoperability Matrices but am wondering if anyone is using the combination without any issues?
Next on my list is deploying vRO and integrating it into vCD and if I can just hop to the latest and greatest rather than wait that would be ideal so I don't have to bother upgrading it later.
I opened this post because looks like i dont understand how should looks like update process for operating systems. Issue starting after some operations in catalog during OS update.
We have opened SR: 19080739611
The problem looks that.
We have now affected all Windows Server template. After some long troubleshooting what we have.
When client download VM to OVA by tenant portal and next try import to vCD process is hanging on 1%
Problem is not observed when we have a fresh template (created inside vCD). When we create some new VMs we can download and import OVA with success.(by tenant client)
The problem started after some time. Last time we observed this issue after Windows Server 2019 update. Maybe this is not related to the specific OS but some activity on vCD level.
The process which we performed during update ( i received this from our OS engineer)
## Update process:
1. Deployment vAPP from Catalog (in Public ORG for templates):.
2. Start VM with network ==> UPDATE OS ==> Stop VM
3. Add to Catalog (with overwrite option and with Customize Vm settings)
4. Deployment vAPP from Catalog (in Public ORG for templates):.
5. Remove network (ORG VDC Network) from vAPP and VM
6. Add to Catalog (with overwrite option and with Customize Vm settings)
Im not sure why we are twice time adding to Catalog... but this is normal operation in my opinion.
From GSS support we not received the good solution. Because "they don't know what we did exactly during this update process".... and suggest importing new VMs from vCenter...( maybe every month ? )
Problem not exist in Flex client... which will be not available in next vCD version...
What is strange OVA from tenant and flex client is different inside.... (exactly that same VM)
1. You can utilize a wildcard cert for the CRM, but it MUST be unique between cloud sites.
2. DNS resolution is imperative for pairing to VCD - especially the communication path. Ensure the vCAv CRM has the proper route to the VCD instance for pairing.