After installing VEEAM Monitor- I've noticed that many of my ESXi servers start getting "(Connection problems) (not responding)". When I go into each ESXi via ILO or DRAC card I see that the console indicates that no more processes can be forked.
Is it possible that VEEAM is forking processes on the ESXi side and not terminating all of them all the time - hence eventually rendering the ESXi server exhausted of any resources to fork new processes?
I just want to understand what may be taking place - perhaps is not VEEAM - but if not, then what is causing this? Anybody knows or have seen this problem too? Currently running ESXi 3.5 u3
Thank you
-
- Influencer
- Posts: 14
- Liked: never
- Joined: Aug 02, 2009 5:17 pm
- Full Name: shija03 shija
- Contact:
-
- Chief Product Officer
- Posts: 31815
- Liked: 7302 times
- Joined: Jan 01, 2006 1:01 am
- Location: Baar, Switzerland
- Contact:
Re: Connection Problems (not responding)
Shija, no Veeam Monitor does not start nor require any additional processes started on ESX(i) host - except some processes running by default (the one which allows you to connect to the host with VMware Infrastructure Client).
What error message do you get when right-clicking unresponding host and selecting "Get error message"?
Do you add individual ESXi hosts to Veeam Monitor, or vCenter server instead?
What error message do you get when right-clicking unresponding host and selecting "Get error message"?
Do you add individual ESXi hosts to Veeam Monitor, or vCenter server instead?
I am not even sure what it all meansshija03 wrote:When I go into each ESXi via ILO or DRAC card I see that the console indicates that no more processes can be forked.
-
- Influencer
- Posts: 14
- Liked: never
- Joined: Aug 02, 2009 5:17 pm
- Full Name: shija03 shija
- Contact:
Re: Connection Problems (not responding)
Hi Gostev,
Thanks for your prompt reply. ILO or DRAC cards are remote control cards to the servers, so one can manage, reboot, and event access the server's console from a remote location - even when the machines are shut off, the systems can be controlled via ILO or DRAC (ILO corresponds to HP remote card and DRAC corresponds to DELL's).
All my systems are added to VEEAM monitor individually. We don't use Virtual Data Center under this particular environment.
When one tries to login using VMWares Infrastructure client, one gets a login incorrect (false error, indicating that the password may not be right - because one using the DRAC or ILO to access the console login successfully) - once on the console of the server - we type:
Alt+F1 (to gain access to the ESXi shell)
And we see messages saying: "could not fork process"
Some of our system are already logged on, so if we try to do something like a: "ps" or any other command, we obtain: could not fork process as well. This means that the server has no more resources to fork a new process, which also implies that it can not do any ESX extra activity that requires the forking of a process - even shutting down will not work - one needs to do a hard power cycle.
Considering that your company deals with so many customers, I would have assumed that many customers may have seen this problem.
Thank you,
James.
Thanks for your prompt reply. ILO or DRAC cards are remote control cards to the servers, so one can manage, reboot, and event access the server's console from a remote location - even when the machines are shut off, the systems can be controlled via ILO or DRAC (ILO corresponds to HP remote card and DRAC corresponds to DELL's).
All my systems are added to VEEAM monitor individually. We don't use Virtual Data Center under this particular environment.
When one tries to login using VMWares Infrastructure client, one gets a login incorrect (false error, indicating that the password may not be right - because one using the DRAC or ILO to access the console login successfully) - once on the console of the server - we type:
Alt+F1 (to gain access to the ESXi shell)
And we see messages saying: "could not fork process"
Some of our system are already logged on, so if we try to do something like a: "ps" or any other command, we obtain: could not fork process as well. This means that the server has no more resources to fork a new process, which also implies that it can not do any ESX extra activity that requires the forking of a process - even shutting down will not work - one needs to do a hard power cycle.
Considering that your company deals with so many customers, I would have assumed that many customers may have seen this problem.
Thank you,
James.
-
- Influencer
- Posts: 14
- Liked: never
- Joined: Aug 02, 2009 5:17 pm
- Full Name: shija03 shija
- Contact:
Re: Connection Problems (not responding)
Here is an update to what we are experiencing:
http://kb.vmware.com/selfservice/micros ... Id=1007887
It appears that there is an issue with ESXi 3.5 - so considering that VEEAM logs into the servers in order to collect information, it is possible that VEEAM makes the issue surface much sooner or simple makes the issue happen when the login requests come in to consecutively.
Just a thought for your engineers to consider - or perhaps even place a README warning - this is all speculation at this point - Could your engineers verify?
Thank you,
James.
http://kb.vmware.com/selfservice/micros ... Id=1007887
It appears that there is an issue with ESXi 3.5 - so considering that VEEAM logs into the servers in order to collect information, it is possible that VEEAM makes the issue surface much sooner or simple makes the issue happen when the login requests come in to consecutively.
Just a thought for your engineers to consider - or perhaps even place a README warning - this is all speculation at this point - Could your engineers verify?
Thank you,
James.
-
- Chief Product Officer
- Posts: 31815
- Liked: 7302 times
- Joined: Jan 01, 2006 1:01 am
- Location: Baar, Switzerland
- Contact:
Re: Connection Problems (not responding)
James, this is very unlikely. We would hear about this by now - based on number of downloads, we estimate that free monitor is used by over 25K users, and most of them are using direct connection to ESX, because typical environments of manyfree edition users are quite small.
Also please note that the KB you have referenced talks about full ESX (not ESXi), and refers to the patch that fixes this issue.
Also please note that the KB you have referenced talks about full ESX (not ESXi), and refers to the patch that fixes this issue.
Who is online
Users browsing this forum: No registered users and 2 guests