I am working with some images with complex multiple network interfaces. I would like to rename the VNIC to match the Guest VM interface name.
Is there anyway to rename from network and network1 to eth0, fastethernet0 etc. I'm OK GUI or digging into config files.
I was looking though some old posts (circa 2015) and back then there was no GUI option. I am unsure if this is still true.
I am on Fusion Pro 11.0.3. I attached a .png showing what I need.
Thanks in advance,
Neal
It is happening again right now. Started at 850am. Here are the live logs.
Cool thanks for the tip. We have another team here that has a script that renames Mac images, but they don't use vRA, they use something more customized, so that script could work when I find the workflow to use thru vRO.
Which monitoring tool are you using?
There are 100's of connections to DB:
2019-04-05 17:08:31.617 UTC 5ca78b8f.9110 0 VCDB vc FATAL: remaining connection slots are reserved for non-replication superuser connections
2019-04-05 17:08:31.618 UTC 5ca78b8f.9111 0 VCDB vc FATAL: remaining connection slots are reserved for non-replication superuser connections
2019-04-05 17:08:31.618 UTC 5ca78b8f.9112 0 VCDB vc FATAL: remaining connection slots are reserved for non-replication superuser connections
2019-04-05 17:08:31.619 UTC 5ca78b8f.9113 0 VCDB vc FATAL: remaining connection slots are reserved for non-replication superuser connections
2019-04-05 17:08:31.677 UTC 5ca78b8f.9114 0 VCDB vc FATAL: remaining connection slots are reserved for non-replication superuser connections
Please share output of below command:
cat /storage/db/vpostgres/postgresql.conf | grep -i "max_connections"
netstat -tulnap | grep -i 443 --> And check if there are several connections from specific IP
*moved to Player forum*
The issue you're hitting is because you have security features enabled on Windows that block 3rd party hypervisor applications from running.
To work around it, you must disable Credential Guard and/or Device Guard, just like the error message states.
The link from the error should provide instructions on how to do that.
Did you click it and perform the instructions?
Did your PC come from an employer, or did it come from the factory with this setting enabled?
Did you install VMware Tools from Workstation or did you install with apt-get install open-vm-tools-desktop?
VMware Tools is the key for all the areas you're referring to.
cat /storage/db/vpostgres/postgresql.conf | grep -i "max_connections"
max_connections = 100 # (change requires restart)
root@vc-irv [ ~ ]# netstat -tulnap | grep -i 443
tcp 0 0 0.0.0.0:443 0.0.0.0:* LISTEN 2390/rhttpproxy
tcp 0 0 0.0.0.0:5443 0.0.0.0:* LISTEN 2548/vsphere-ui.lau
tcp 0 0 0.0.0.0:9443 0.0.0.0:* LISTEN 2547/vsphere-client
tcp 1 0 127.0.0.1:33700 127.0.0.1:443 CLOSE_WAIT 5400/vmware-content
tcp 0 0 127.0.0.1:47412 127.0.0.1:443 TIME_WAIT -
tcp 1 0 127.0.0.1:42442 127.0.0.1:443 CLOSE_WAIT 5400/vmware-content
tcp 1 0 127.0.0.1:5432 127.0.0.1:44330 CLOSE_WAIT 35050/postgres: vc
tcp 0 0 10.10.98.47:44434 10.10.67.16:9543 ESTABLISHED 1439/liagent
tcp 0 0 127.0.0.1:443 127.0.0.1:47584 ESTABLISHED 2390/rhttpproxy
tcp 0 0 127.0.0.1:443 127.0.0.1:47838 TIME_WAIT -
tcp 0 0 127.0.0.1:47578 127.0.0.1:443 TIME_WAIT -
tcp 1 0 127.0.0.1:47032 127.0.0.1:443 CLOSE_WAIT 3844/python
tcp 1 0 127.0.0.1:5432 127.0.0.1:44302 CLOSE_WAIT 35036/postgres: vc
tcp 0 0 127.0.0.1:46702 127.0.0.1:443 TIME_WAIT -
tcp 1 0 127.0.0.1:33692 127.0.0.1:443 CLOSE_WAIT 5400/vmware-content
tcp 1 0 127.0.0.1:33694 127.0.0.1:443 CLOSE_WAIT 5400/vmware-content
tcp 1 0 127.0.0.1:52374 127.0.0.1:443 CLOSE_WAIT 2548/vsphere-ui.lau
tcp 0 0 127.0.0.1:47460 127.0.0.1:443 TIME_WAIT -
tcp 1 0 127.0.0.1:33698 127.0.0.1:443 CLOSE_WAIT 5400/vmware-content
tcp 0 0 10.10.98.47:443 10.10.98.124:50626 TIME_WAIT -
tcp 1 0 127.0.0.1:60624 127.0.0.1:443 CLOSE_WAIT 5400/vmware-content
tcp 0 0 127.0.0.1:47628 127.0.0.1:443 TIME_WAIT -
tcp 1 0 127.0.0.1:46542 127.0.0.1:443 CLOSE_WAIT 2548/vsphere-ui.lau
tcp 1 0 127.0.0.1:5432 127.0.0.1:44308 CLOSE_WAIT 35042/postgres: vc
tcp 0 0 127.0.0.1:47282 127.0.0.1:443 ESTABLISHED 5366/vmware-sps.lau
tcp 0 0 127.0.0.1:47752 127.0.0.1:443 TIME_WAIT -
tcp 1 0 127.0.0.1:5432 127.0.0.1:44306 CLOSE_WAIT 35039/postgres: vc
tcp 1 0 127.0.0.1:55964 127.0.0.1:443 CLOSE_WAIT 3844/python
tcp 1 0 127.0.0.1:60628 127.0.0.1:443 CLOSE_WAIT 5400/vmware-content
tcp 1 0 127.0.0.1:33716 127.0.0.1:443 CLOSE_WAIT 5400/vmware-content
tcp 1 0 127.0.0.1:33650 127.0.0.1:443 CLOSE_WAIT 5400/vmware-content
tcp 1 0 127.0.0.1:57548 127.0.0.1:443 CLOSE_WAIT 5320/python
tcp 0 0 127.0.0.1:443 127.0.0.1:47526 TIME_WAIT -
tcp 0 0 127.0.0.1:47656 127.0.0.1:443 TIME_WAIT -
tcp 0 0 127.0.0.1:47582 127.0.0.1:443 TIME_WAIT -
tcp 1 0 127.0.0.1:5432 127.0.0.1:44314 CLOSE_WAIT 35044/postgres: vc
tcp 0 0 127.0.0.1:443 127.0.0.1:47832 TIME_WAIT -
tcp 0 0 127.0.0.1:47734 127.0.0.1:443 TIME_WAIT -
tcp 0 0 127.0.0.1:443 127.0.0.1:47448 TIME_WAIT -
tcp 1 0 127.0.0.1:5432 127.0.0.1:44340 CLOSE_WAIT 35057/postgres: vc
tcp 1 0 127.0.0.1:33712 127.0.0.1:443 CLOSE_WAIT 5400/vmware-content
tcp 1 0 127.0.0.1:5432 127.0.0.1:44338 CLOSE_WAIT 35056/postgres: vc
tcp 0 0 127.0.0.1:443 127.0.0.1:41990 TIME_WAIT -
tcp 1 0 127.0.0.1:41142 127.0.0.1:443 CLOSE_WAIT 5400/vmware-content
tcp 1 0 127.0.0.1:5432 127.0.0.1:44348 CLOSE_WAIT 35060/postgres: vc
tcp 0 0 127.0.0.1:47648 127.0.0.1:443 TIME_WAIT -
tcp 0 0 10.10.98.47:443 10.10.98.124:50622 TIME_WAIT -
tcp 0 0 127.0.0.1:47746 127.0.0.1:443 TIME_WAIT -
tcp 0 0 127.0.0.1:47830 127.0.0.1:443 ESTABLISHED 5366/vmware-sps.lau
tcp 0 0 127.0.0.1:47622 127.0.0.1:443 TIME_WAIT -
tcp 0 0 127.0.0.1:443 127.0.0.1:47282 ESTABLISHED 2390/rhttpproxy
tcp 0 0 127.0.0.1:47668 127.0.0.1:443 TIME_WAIT -
tcp 0 0 127.0.0.1:47674 127.0.0.1:443 TIME_WAIT -
tcp 1 0 127.0.0.1:5432 127.0.0.1:44350 CLOSE_WAIT 35063/postgres: vc
tcp 1 0 127.0.0.1:5432 127.0.0.1:44310 CLOSE_WAIT 35043/postgres: vc
tcp 1 0 127.0.0.1:33690 127.0.0.1:443 CLOSE_WAIT 5400/vmware-content
tcp 1 0 127.0.0.1:5432 127.0.0.1:44334 CLOSE_WAIT 35053/postgres: vc
tcp 0 0 127.0.0.1:47634 127.0.0.1:443 TIME_WAIT -
tcp 1 0 127.0.0.1:5432 127.0.0.1:44303 CLOSE_WAIT 52434/postgres: vc
tcp 1 0 127.0.0.1:60406 127.0.0.1:443 CLOSE_WAIT 5400/vmware-content
tcp 1 0 127.0.0.1:33710 127.0.0.1:443 CLOSE_WAIT 5400/vmware-content
tcp 0 0 127.0.0.1:443 127.0.0.1:47830 ESTABLISHED 2390/rhttpproxy
tcp 1 0 127.0.0.1:33706 127.0.0.1:443 CLOSE_WAIT 5400/vmware-content
tcp 1 0 127.0.0.1:42612 127.0.0.1:443 CLOSE_WAIT 5400/vmware-content
tcp 32 0 10.10.98.47:55568 184.27.114.65:443 CLOSE_WAIT 5319/updatemgr
tcp 0 0 10.10.98.47:443 10.10.98.124:50631 TIME_WAIT -
tcp 1 0 10.10.98.47:34874 208.91.0.89:443 CLOSE_WAIT 2547/vsphere-client
tcp 1 0 127.0.0.1:33714 127.0.0.1:443 CLOSE_WAIT 5400/vmware-content
tcp 0 0 127.0.0.1:443 127.0.0.1:47722 TIME_WAIT -
tcp 0 0 127.0.0.1:47584 127.0.0.1:443 ESTABLISHED 5320/python
tcp 1 0 127.0.0.1:5432 127.0.0.1:44346 CLOSE_WAIT 35058/postgres: vc
tcp 1 0 127.0.0.1:56164 127.0.0.1:443 CLOSE_WAIT 5348/vmware-vsm.lau
tcp 0 0 127.0.0.1:443 127.0.0.1:47922 TIME_WAIT -
tcp 0 0 127.0.0.1:47740 127.0.0.1:443 TIME_WAIT -
tcp 0 0 127.0.0.1:47610 127.0.0.1:443 TIME_WAIT -
tcp 0 0 127.0.0.1:47662 127.0.0.1:443 TIME_WAIT -
tcp 1 0 127.0.0.1:33696 127.0.0.1:443 CLOSE_WAIT 5400/vmware-content
tcp 1 0 127.0.0.1:5432 127.0.0.1:44324 CLOSE_WAIT 35049/postgres: vc
tcp6 0 0 :::443 :::* LISTEN
I am not familiar with this. Thanks again for all the help.
One way to address this issue is to increase max_connections to 250, restart vCSA and monitor.
If this doesn't help contact VMware support.
Can you educate me on what these connections are for ? I know my team does a lot of automation as this is a lab environment.
I find that hard to understand, you showed that you got 2 MoRefs returned.
So at least 2 Scheduled Tasks should be there.
Downtime outside of business and reporting hours is acceptable, I have a decent window for maintenance and such. I'm assuming the "vmkfstools" command needs ran from the particular hosts console? Upon completion, the space differential between what is fully allocated now as a thick disk vs what is being used will be automatically available to the VMware environment? Since these are Windows partitions, once the steps you listed are completed, is there anything else that is needed to be done to the Windows OS for the partition to show correctly? Thanks!
So I tested the VMware Converter Standalone product and while it worked, it took it's own sweet time, and maybe that is due to how I have it setup. I installed the Converter software on a physical server, and created a new task to do a V2V conversion of a Win2008R2 server with a 60GB hard drive, shrinking that hard drive down to 40GB on a different LUN on the same SAN. While the process worked, it took about an hour and 45 minutes. Would this process be sped up if the Converter application was installed on a guest server that is part of the VMware environment?
Usually this comes from the application-level, one of more services connecting to PostgreSQL are visibly not releasing connections, causing the amount of connections to run out.
Attach vpxd and vpxd-profiler logs, we can track the client IP from these logs.
Very Cool. Finally Something that makes sense. I will give it a go and let you know what happens. Cheers. Making Changes now.
Hi Joe,
Unfortunately, I'm not familiar with the administration of our VMs as I'm just an end user.
What I do know is that before updating to the latest Horizon client, it used to work fine.
Think pre 2.13.2?
VMware App Volumes 2.13.2 Release Notes
@nschilp This is a specific vsphere issue, any persona sync issues are different. You may want to post directly in the horizon sub forum about that.
Hi John,
Thanks for your switch recommendation. We will care them in next investment.
By the way second recommendation of Cisco related to my case is to increase connected ports to backbone switches. Because my servers connected to Nexus, Nexus connected to Catalyst6500 with 2 ports in port-channel. these 2 ports are congested ports, and so it is applying back pressure to end devices.
We will increase the count of ports or replace the switches.