- Launch the vSphere 6.x Certificate Manager:
/usr/lib/vmware-vmca/bin/certificate-manager
Saturday, July 18, 2020
Custom Certificate update/renew on External PSC, VCSA appliances and ESXi hosts on 6.5 U3 version.
Tuesday, July 7, 2020
Imported Virtual machine in vRA not showing IP address allocation in network profile
Imported Virtual machine in vRA not
showing IP address allocation in network profile
Hello Everyone,
Today, I am writing
this post for the issue which I encountered after bulk import of Virtual machine
into vRealize Automation 7.6 version.
I saw the behaviour
that imported virtual machine IP address is not showing allocated in Network profile
section.
Due to this
IP address allocation not updated in network profile, vRA allocates that same
IP to another VM during the VM deployment via vRA. This is default behaviour of
vRA because as per the vRA inventory that particular IP is not allocated to any
VM.
But when I raised
a VM provision request via vRA, it got stucked on customise the virtual machine
because it detects that the IP is already in use on the network so my VM
request got failed after 2 hrs. time out period.
Now, below
are the steps to update the IP address for the registered VMs into vRA via IAAS
SQL database so that IP address allocated in network profile and vRA come know
about that IP address as well.
1.
Login
to your IAAS SQL server.
2.
Open
the SQL server management studio with SA account or any other account which
should have full access on vRA database.
3.
Run
below search query to find out the details about that IP address.
select * from StaticIPv4Address where IPv4Address ='172.16.10.90'
4.
You
will get below details about this IP address.
5.
So
in above pictures, you can see Virtual Machine ID is NULL , and StaticIPv4AddressState
value is 1, this means IP is not allocated to any VM by vRA.
6.
Now,
we need to update Virtual Machine ID, IP address and StaticIPv4AddressState to “0”
via IAAS SQL database update command as shown below.
UPDATE StaticIPv4Address SET VirtualMachineID = '962982F5-06DD-4EF8-B03B-F173742D1028', StaticIPv4AddressState = '0' WHERE IPv4Address = '172.16.10.90'
7.
Now,
VM ID and IPv4 address details updated as shown below
8.
So,
if you check in vRA under Network profile section, you will see that above IP has
been allocated to the respective VM.
That’s all for this post, hope this
will informative to everyone, Cheers…..!!!!
Wednesday, June 24, 2020
vRealize Automation 7.6 cluster replica nodes AD joining issue
This article is for how to resolve the vRA replica nodes domain joining issues.
Let me tell you the background of this issue, I have upgraded my vRA environment 7.3 to 7.6 version successfully. After the upgrade, I introduced 2 replica nodes into vRA cluster to make it distributed deployment.
Once, i have added the replica nodes into vRA cluster successfully. I logged into my vRA portal default tenant and try to add these 2 nodes( which are basically called as connectors into vRA portal) to my Active Directory domain so that i can leverage the benefit of Load balancer and user authentication can be made via any nodes into the vRA cluster.
On vRA portal, go to Administration Tab, under Directories Management, click on Connectors tab
When i click on Join domain tab on my second Replica node, i got below error.
Connector communication failed with response: Certificate for <VRA002.cloudarena.com> doesn't match common name of the certificate subject: VRA001.cloudarena.com for the connector VRA002.cloudarena.com
This error is same for third Replica node as well.
Connector communication failed with response: Certificate for <VRA003.cloudarena.com> doesn't match common name of the certificate subject: VRA001.cloudarena.com for the connector VRA003.cloudarena.com
I checked my vRA certificate status and all my certificates are valid until Sep 2020.
I rebooted the whole stack of my vRA environment but still issue is same.
Then, we have a look on certificate part on replica nodes and figure out that
- As per the error, the newly deployed vRA replica
appliances were using the internal horizon certificate for the original
appliance VRA001.cloudarena.com
- This certificate is unrelated to the one we would have
generated and applied to vRA.
- We tried to run a command to update the certificates
locally on the 2 new replicas
- Run this command >>
- /usr/local/horizon/scripts/installExternalCertificate.hzn
--ca /usr/local/horizon/conf/root_ca.pem --cert
/usr/local/horizon/conf/VRA002.cloudarena.com_cert.pem --key
/usr/local/horizon/conf/VRA002.cloudarena.com_key.pem --alias
"horizoninternalcert"
/usr/local/horizon/conf/root_ca.pem --cert /usr/local/horizon/conf/VRA002.cloudarena.com_cert.pem --key /usr/local/horizon/conf/VRA002.cloudarena.com_key.pem --alias "horizoninternalcert" - This failed with the following error;
- keytool error: java.io.IOException: DER length more
than 4 bytes: 109
- Run steps to workaround this on both vRA replicas nodes;
- mkdir /root/tmp-bkp
- mv /usr/local/horizon/conf/flags/fips* /root/tmp-bkp
- /usr/local/horizon/scripts/secure/wizardssl.hzn
- mv /root/tmp-bkp/fips* /usr/local/horizon/conf/flags
- service horizon-workspace restart
- We now successfully joined the replica to AD domain.
Then we could add the load-balancer address to the directory config, to allow log in through the LB address.
Monday, June 15, 2020
LDAPs configuration for vCenter Server.
-----BEGIN CERTIFICATE-----
MwMDAwMDBaMBkxFzAVBgNVBAMTDmFkLmdzc2xhYnMub3JnMIIBIjANBgkqhkiG
9w0BAQEFAAOCAQ8AMIIBCgKCAQEA7JFQshqvAH+bsej+FE6IYf3LA38EpMmnsCJV
nvvX1RXoHs5tr8iwbm6fMggRHZA8jHY3Z/wnLkh1Ct+8MylrGVRL4MB1bXeSH7MT
TTCMCI/ikokCO6vkVlG1RP/YcMOIUCLERsgJiZ8qCEZYLdw8ioZuA1kaGQkiJRy8
KZI5lz4nqV9owks1e4TW5TtCTDqorYxBz2x2PsZLTih/fgLf9kRr0QUHc/f8TMuI
3LWdGdodxUKKAP7cHU5awhsOdiDjqWEuYA4gioog0Dd9sE111JvPP0opSPMgnMpf
CWOc04z8dqkR15BChG36Gvgqqbnf77vknDe1RgkFhyK6GjKGTQIDAQABoyQwIjAL
BgNVHQ8EBAMCBDAwEwYDVR0lBAwwCgYIKwYBBQUHAwEwDQYJKoZIhvcNAQEFBQAD
ggEBAC8sNBB5e5WffE9VjU5zcDqvOQqE24XD1bdFeKW/ud6aYwmF5YV4wFpEGkA9
bez2zI5TKVnm2XE4mpwyZHSbbiXzh2SbAQI1QTde9slTFTkib0HsMZYxBE5Xsgdq
RXUX6xvU2sMbHevj13zkGfoF71T72ddq78LTCbrX3EU0jYbHhrKTqRc6qHAv9fz4
2z8xKysVs+CCx8g+qEm+igMxb9/XdA2HUOA8l+NDlH/qS78e9ty0XNayl8ZC/7bZ
-----END CERTIFICATE-----
Choose identity source type is Active Directory over LDAP and then fill all details of Domain like below and also upload the certificate under section SSL Certificates which we had saved in Step2
Click ADD and if all details are correct then your identity source will add and show under identity Source Tab.
That's all for this LDAPs configuration. Hope, this will informative to all... Cheers..!!
Friday, June 12, 2020
Upgrading vRealize Automation from 7.3 to 7.6 version.
- /ect/vcac/
- /etc/vco/
- /etc/apache2/
- /etc/rabbitmq/
- Primary IaaS Website
- Microsoft SQL database
- Model Manager
- At least 15 GB on the root partition
- 5 GB on the /storage/db partition for the master
vRealize Automation appliance
- 15 GB on the root partition for each replica virtual
appliance
- Examine the files in the pgdata directory on the
master host before you upgrade the replica hosts.
- Navigate to the PostgreSQL data folder on the
master host at /var/vmware/vpostgres/current/pgdata/.
- Close and remove any .swp files in the pgdata
directory. Files with a .swp suffix require you to close the
VI session and delete the file.
- Verify that all files in this directory have the
correct owner name: postgres:<owner-group>
- ·
Make sure taking a snapshot of the master virtual appliance.
- ·
From the vRA VAMI, switch replication from sync to async if not
done previously.
- ·
Run below commands to vacuum the
database and remove lob entries.
- ·
su - postgres -c "/opt/vmware/vpostgres/current/bin/vacuumlo
-v -p 5432 vcac"
- ·
su - postgres -c "/opt/vmware/vpostgres/current/bin/vacuumdb
-f -p 5432 -t pg_largeobject -t pg_largeobject_metadata vcac"
- · To reclaim database space, use the vacuum full commands.
- ·
./psql -U postgres -d vcac
- ·
vacuum full
- · vacuum analyze
Edge node vmid not found on NSX manager
Hello There, Recently , we faced an issue in our NSX-T envrironment running with 3.2.x version. We saw below error message while running t...
-
VMware Cloud Foundation is VMware’s comprehensive software-defined infrastructure (SDI) platform for deploying and managing private and hy...
-
You can import an unmanaged virtual machine to a vRealize Automation environment. An unmanaged virtual machine exists in a vCenter but...
-
Native File Services on vSAN 7.0 Hello Everyone, Today, we are covering up about ...