Trying to install latest VCSA 7.0.1 trial in lab under VM Workstation but getting "Unable to save IP settings" during the set up phase no matter what I do.
VM is allocated 2 x Intel Core i7-10700, 11.7 GB memory. Its got a static IP and bridged to the local network which has a DNS server which I am confident is working because I can see the lookups and replies.
Wanting to get a lab running for NSX-T 3.0. Relatively new to this.
Thanks.
How exactly are you trying to deploy it?
I appreciate the reply.
Using a procedure I've found in a few places. One example is : https://diyvirtualization.com/2020/05/28/how-to-install-vcsa-7-in-vmware-workstation-15-step-by-step/
Stuck at step 11 shown.
Thanks.
It's likely a known bug which you are facing.
From VMware vCenter Server 7.0 Update 1 Release Notes
Deployment of a vCenter Server Appliance by using port 5480 at stage 2 fails with unable to save IP settings error
If you use
https://appliance-IP-address-or-FQDN:5480in a Web browser, go to the vCenter Server Appliance Management Interface for stage 2 of a newly deployed vCenter Server Appliance, and you configure a static IP or try to change the IP configuration, you see an error such asUnable to save IP settings.Workaround: None.
André
Thanks.
Workaround is to use another install method... I've made more progress using the installer to my ESXi host.
Okay so here is how I fixed it, thanks to Vijay!
This worked for me, it may not work for others, but I wanted to share the results as I was able to update the appliance okay I took a VM snapshot before I did anything in case it broke, thankfully it worked out okay.
Step 1 - cp /etc/applmgmt/appliance/update.conf /etc/applmgmt/appliance/update.conf2
Step 2 - rm /etc/applmgmt/appliance/update.conf
Step 3 - service-control --stop --all
Step 4 - service-control --start --all
Note: the update.conf is re-created on it's own but it still fails to work
Step 5 - visit https://vcsa_ipaddress:5480 and login, attempt to update, it will fail
Step 6 - vi /etc/applmgmt/appliance/update.conf and paste in the spare file Vijay included as an attachment here
Step 7 - service-control --stop vpxd
Step 8 - service-control --start vpxd
Step 9 - visit https://vcsa_ipaddress:5480 and login and attempt to update, all the screens showed up and populated okay and it pulled down the latest update from online
Upgrading to 6.7.0.45100 made the 7.X disappear as you wrote.
Thank you guys.
Christian,
We are facing the same issue. It appears to be that all our Datacenters and hosts are in folders. vCenter can not see networks of objects in folders. If we pull a Datacenter out of the folder and put it into the root of vCenter then Networks can be seen. VMware support are looking into it.
Best Regards
Rob
Hello:
I've been attempting to configure vCenter v6.7u3 to use an openLDAP server as a SSO using LDAPS and in the process been unsuccessful. The main problem is that vCenter will establish a tls connection and verify the certificate signatures, but will then close the connection immediately.
Here is an excerpt from when trying to submit the SSO configuration:
af4d4d42-75c4-403b-bdad-79f976bfd9a8 INFO com.vmware.identity.interop.ldap.SslX509EqualityMatchVerificationCallback] Server SSL certificate is a trusted certificate.
af4d4d42-75c4-403b-bdad-79f976bfd9a8 WARN com.vmware.identity.interop.ldap.LdapErrorChecker] Error received by LDAP client: com.vmware.identity.interop.ldap.OpenLdapClientLibrary, error code: -1
af4d4d42-75c4-403b-bdad-79f976bfd9a8 WARN com.vmware.identity.idm.server.ServerUtils] cannot bind connection: [ldaps://10.10.35.31, cn=admin,dc=example,dc=com]
af4d4d42-75c4-403b-bdad-79f976bfd9a8 ERROR com.vmware.identity.idm.server.ServerUtils] cannot establish connection with uri: ldaps://10.10.35.31
openLDAP logs show the vCenter establishing a tls connection and them promptly losing the connection.
With openssl s_client, I can connect to the port with the certificates I provide, but I can't find anything else that would be useful. I can also connect on LDAP:// as well, but I want to establish a TLS connection. Is there a particular way that the certificates should be made? I just want to get the LDAPS to work.
Struggling with the same issue. Did you find a solution? Thank you very much in advance.
This should be the marked answer, worked for me right away.
I have a vCenter (on Windows) server with the same issue. The OS volume has 6GB free, but I had the same free space errors in the logs starting on 9/24, and when the server rebooted for automatic updates on 10/14 it effectively broke the DB. I see the same "VCDB vc FATAL: the database system is starting up" error in the logs since then and I cannot get services to start. Did you find a resolution for your server?
What other option of installation is working?
The error was occurring when I tried to install VCSA directly onto Workstation (Pro 16) on my lab network. I have now installed it under ESXi which is also running on Workstation, using the installer. I wanted to avoid the nesting, but its running fine like that.
this work for me,
sometime later I've error again,
solved by migrate vCenter to another host,
surprise to me
Hey Tynenmhorn,
Could you please try the next:
I don't have a web interface running. How do I add a user to a group by cli? I tried it: "dir-cli group modify --name administrators" it didn't help.
Hello
I would like to configure a backup from a VCSA 7.0 to to a FTPS-Server (running on a Windows Server). I've installed Bitvise SSH server application on this Windows server and FTPS enabled on port 21. I'v set up the whole certificate things - and it seams when I start a backup from the VCSA (VAMI -> Backup), then it stucks during TLS negotiation. The VCSA backup reports "General system error reported by backup server."
This is what the Bitvise SSH/FTPS server says in his logs from the very start until the end of the session - the interesting part is red:
<event seq="103" time="2020-10-29 16:10:21.962619 +0100" app="BvSshServer 8.37" name="I_CONNECT_ACCEPTED" desc="Connection accepted.">
<session id="1012" service="FTP" remoteAddress="192.168.1.88:53812"/>
<parameters addressRule="AnyIP" listenAddress="192.168.1.50:21"/>
<sessions ssh="0" sshAuth="0" ftp="1" ftpAuth="0"/>
</event>
<event seq="104" time="2020-10-29 16:10:21.996486 +0100" app="BvSshServer 8.37" name="I_FTP_CONTROL_TLS_NEGOTIATED" desc="TLS algorithms for FTP control connection negotiated.">
<session id="1012" service="FTP" remoteAddress="192.168.1.88:53812"/>
<parameters negNr="1" protocol="TLS 1.2" cipherSuite="TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384"/>
</event>
<event seq="105" time="2020-10-29 16:10:22.076464 +0100" app="BvSshServer 8.37" name="I_LOGON_AUTH_SUCCEEDED" desc="User authentication succeeded.">
<session id="1012" service="FTP" remoteAddress="192.168.1.88:53812" virtualAccount="test" windowsAccount="VENUS\BvSsh_VirtualUsers"/>
<authentication attemptNr="1" serialize="completion" userName="test" method="password"/>
<parameters accountSettings="test" groupSettings="Virtual Users" tokenType="LogonUser" tokenLogonType="Network" tokenElevation="Restricted"/>
</event>
<event seq="106" time="2020-10-29 16:10:22.244984 +0100" app="BvSshServer 8.37" name="I_SFS_QUERY_HOME_DIRECTORY" desc="Virtual filesystem: query home directory.">
<session id="1012" service="FTP" remoteAddress="192.168.1.88:53812" virtualAccount="test" windowsAccount="VENUS\BvSsh_VirtualUsers"/>
<sfs moduleName="FlowSfsRoot" code="40000" desc="Querying home directory succeeded.">
<parameters homePath="/"/>
</sfs>
</event>
<event seq="107" time="2020-10-29 16:10:22.459125 +0100" app="BvSshServer 8.37" name="I_FTP_PASV_DISPATCHER_DATA_ACCEPTED" desc="FTP passive data connection accepted.">
<parameters remoteAddress="192.168.1.88:52498" listenAddress="0.0.0.0:61764" addressRule="AnyIP"/>
</event>
<event seq="108" time="2020-10-29 16:10:22.459887 +0100" app="BvSshServer 8.37" name="I_FTP_DATA_ACCEPTED" desc="Passive FTP data connection accepted.">
<session id="1012" service="FTP" remoteAddress="192.168.1.88:53812" virtualAccount="test" windowsAccount="VENUS\BvSsh_VirtualUsers"/>
<parameters remoteAddress="192.168.1.88:52498" listenAddress="0.0.0.0:61764" operation="Nlst"/>
</event>
<event seq="109" time="2020-10-29 16:10:22.463285 +0100" app="BvSshServer 8.37" name="I_FTP_DATA_ERROR" desc="FTP data connection failed.">
<session id="1012" service="FTP" remoteAddress="192.168.1.88:53812" virtualAccount="test" windowsAccount="VENUS\BvSsh_VirtualUsers"/>
<parameters remoteAddress="192.168.1.88:52498" operation="Nlst"/>
<error type="Exception" message="TLS session for the data connection was not resumed from the control connection."/>
<help message="To verify client identity, a TLS session for a data connection must be established using secret data negotiated in the original TLS session for the control connection. This client did not do this, so if this data connection was accepted, it could be hijacked. The client needs to use software that supports TLS session resume. If the feature is already available in the client software, it needs to be enabled by the user."/>
</event>
<event seq="110" time="2020-10-29 16:10:23.478112 +0100" app="BvSshServer 8.37" name="W_SESSION_DISCONNECTED_ABNORMALLY" desc="Session disconnected abnormally.">
<session id="1012" service="FTP" remoteAddress="192.168.1.88:53812" virtualAccount="test" windowsAccount="VENUS\BvSsh_VirtualUsers"/>
<parameters disconnectReason="Flow" socketBytesReceived="2139" socketBytesSent="8814" payloadBytesReceived="63" payloadBytesSent="248"/>
<error type="Flow" component="FtpManager/ftpControl" class="Flow" code="Unexpected" description="FtpControl: Received TLS shutdown"/>
<sessions ssh="0" sshAuth="0" ftp="0" ftpAuth="0"/>
</event>
Bitvise SSH/FTPS server say that the client does somehow not establish and resume the TLS session. So, it seams VCSA is the "guilty"?
The backup log file from the VCSA says nothing at all.
Has anybody any hint for me? I'm looking now quite long without any idea...
Kind regards
Roman
Use the connectivity string as ldaps://ip:636
No luck, logs show an attempt to connect to that port, and packet capture show that a TLS connection is established (Handshake finishes). I've run netstat to confirm that the port 636 is open as well, and the openldap server is logging the vCenter IP address.
This is all I see on openLDAP server:
conn=1001 fd=13 ACCEPT from IP=[vCenter IP Address]:34594 (IP=0.0.0.0:636)
conn=1001 fd=13 TLS established tls_ssf=256 ssf=256
conn=1001 fd=13 closed (connection lost)
So it looks like it makes a connection and then just gives up, and on the vCenter server I just have an LDAP error code of -1.
can you specify the User Bind DN?
Yes. I can successfully connect through normal LDAP. So I believe the DNs are correct.
Our customer cannot login on vcenter server using AD account. we already validated the time synchronization but still can't login the users.