Skip to main content

vCD portal is not accessible after the installation

 I wanted to share my experience in fixing NFS issue during vCD 9.7 Linux based installation. 

It is my first cell in the server group with CentOS 7 as operating system. The NFS server(centos) and client versions are v4. After configuring the first cell in the environment, the vCD service started successfully however when I tried to access vCD web port it was not accessible. 


 

vCD service status as below 

# service vmware-vcd status

vmware-vcd-watchdog is running

vmware-vcd-cell is running

 cell.log

======

Application Initialization: 'com.vmware.vcloud.common.core' 95% complete. Subsystem 'com.vmware.vcloud.jax-rs-servlet' started

Application Initialization: 'com.vmware.vcloud.common.core' 100% complete. Subsystem 'com.vmware.vcloud.ui-vcloud-webapp' started

Application Initialization: 'com.vmware.vcloud.common.core' complete.

Successfully handled all queued events.

Successfully verified transfer spooling area: /opt/vmware/vcloud-director/data/transfer

Cell startup completed in 0m 48s

 

While checking my installation prereqs noticed the transfer share directory was mounted and had ownership as nobody:nobody instead of vcloud user and group.


 Troubleshooting steps followed are 

  • Changed the ownership to vcloud:vcloud using command chown -R vcloud:vcloud /opt/vmware/vcloud-director/data/transfer
  • Confirmed the nfs share is set to no_root_squash
  • Created new share in nfs server
  • Unmounted and remounted transfer share directory
  • Created Windows share still it mounted with permission as nobody:nobody on client machine
  • Configured domain name in /etc/idmapd.conf file in both nfs server and client and then restarted rpcidmapd & nfs service

Solution: 

 The solution eventually is to mount nfs volume with version 3

  • mount -t nfs -o vers=3 nfs_ip:/nfs_folder /opt/vmware/vcloud-director/data/transfer 

The ownership changed to vcloud user after that and vCD portal is accessible. It is good now to proceed with additional cell installation in the server group.

Labels:

Comments

Post a Comment

Popular posts from this blog

Deleting stale kubernetes clusters in vCD

Unlike the previous version the CSE 4.x is a stateless appliance and its data is stored in VMware Cloud Director Database.  The cluster creation and deletion compared with CSE 3.x version has improved. Besides, there are some scenarios where the cluster deletion is failing even when the "Force Delete" option is chosen. We can use vCD API explorer to delete it, the following are the API queries you can execute  Under definedEntity POST /1.0.0/entities/{id}/resolve DELETE /1.0.0/entities/{id}
Post a Comment
Read more

Building My First AI Chatbot with Azure OpenAI Services

In April 2024, I embarked on an exciting journey into the world of artificial intelligence (AI), starting with learning Python. Coming from an infrastructure-focused background, diving into AI development felt like a monumental shift. Without prior coding experience, I realized that building AI tools or training models from scratch would require a long-term commitment. However, I was determined to take small, practical steps toward understanding this fascinating field. Exploring cloud AI services from providers like AWS and Azure led me to Azure OpenAI services. This platform showed me how AI could be leveraged to create applications— like chatbots—without deep coding expertise. I was especially intrigued by concepts such as indexing, semantic search, and retrieval-augmented generation (RAG). These tools enabled me to build my first business use case: a Microsoft Teams chatbot designed to resolve internal queries and reduce dependency on subject matter experts (SMEs). This blog is a s...
Post a Comment
Read more

How to enforce Day2 Action Policy in vRA 8.x

It's bit different when compared to vRA 7.x versions. If you do not have any Day 2 Action policies defined, then no governance is applied and all users have access to all the actions by default in vRA 8.x.Okay, let see this with an example By default all the deployments/machines are entitled with all actions for all users in the organization Once you a define Day 2 Action policy it goes into effect for specified users of vRA service broker and Cloud assembly. As a result, only the users for whom the first policy is true can run the selected actions. All others are excluded. I have created a Day2 Action policy to change deployment lease and create snapshot of cloud machine for Administrator user in the entire organization(includes all projects in the organization). As you can see below I logged in with an project administrator user and I am entitled with enforced Day2 action created and this will be applied for existing deployment as well. When I logged as a project member user as...
Post a Comment
Read more