Hi, I'm not sure whether I'm in the right forum. But I'm desperately seeking for a straw to grasp to solve an issue we have with our provider (hoster, using VMWARE). I'm not sure what Vmware product he is using but it is a larger hoster in southern Germany who is selling guest hosts (as servers) in various configurations.
The server (guest) in question is a 512 MB server with about 18GB disk and is running a Debian 6. (Intel e1000 networkcard driver)
The effect is that the server looses network connectivity regularly. As long as one is doing a ping from the server to somewhere
outside, the network connectivity stays availabe. But as soon as it is idle what network activity is concerned, network connectivity disrupts.
We reclaimed that already to the provider but the only advice he could give us, was to run a cron job which keeps the server
connected this way. We think this cannot be the solution. The host OS is linux as well. I cannot say what Linux platform.
I'm just fishing for any advice or idea what the cause can be and whether this has been observed in the VMWARE virtualization environment
by others before.
Thanks.
--
Christoph
Krischu wrote:
The effect is that the server looses network connectivity regularly. As long as one is doing a ping from the server to somewhere
outside, the network connectivity stays availabe. But as soon as it is idle what network activity is concerned, network connectivity disrupts.
There might be some firewall / NAT issue somewhere which might time-out when the server goes silent?
When you lose the network connectivity, in which way is this noticed and how do you get the server going again? Can you see something in the guest servers log if it is loosing the direct connection with the (virtual) switch or can it no longer connect to remote systems?
I'm going to the hosters' website, log into the Java screen console applet and initiate a ping to the outside.
From then on a possible ping from the outside that hung gets awoken.
--
Christoph
Krischu wrote:
I'm going to the hosters' website, log into the Java screen console applet and initiate a ping to the outside.
From then on a possible ping from the outside that hung gets awoken.
So you get no notice inside the guest that there is something wrong with the direct connection, i.e. it is not losing the network connection?
Are there any other guest/device on the same LAN as this server that you have access too? Could you try to ping/access the server while the problem as occured and see if it is reachable?
The specific service being hosted on this guest VM, is it TCP or UDP based?
Rickard Nobel schrieb:
Krischu wrote:
I'm going to the hosters' website, log into the Java screen console applet and initiate a ping to the outside.
From then on a possible ping from the outside that hung gets awoken.
So you get no notice inside the guest that there is something wrong with the direct connection, i.e. it is not losing the network connection?
Are there any other guest/device on the same LAN as this server that you have access too? Could you try to ping/access the server while the problem as occured and see if it is reachable?
The specific service being hosted on this guest VM, is it TCP or UDP based?
Yes, there is no event notifying me of a loss of connectivity. And as soon as I wish to initiate a network connection to
the outside, it works. There is no reason to complain that the system cannot connect to the outside.
It just seems that as long as the system itself doesn't do any network activity (as a ping to the outside), it goes into a state
that one cannot connect any longer from to outside to the system, be it ssh or ping.
At the moment I'm not running any service other than sshd (tcp) on that machine. I'm just testing the connectivity. Whether it responds to pings or ssh connects. I don't know of any other IP addresses that are connected to that VMhost that I could try to reach and I have no idea or information on the hosters' LAN structure.
--
Christoph
Today, after my provider did intensive tests, he came back on me and told me that the problem has been found. It was complicated and a coincidence of several factors. I asked for a more precise description.
So my insisting has payed off.
Thanks for your efforts in trying to help me.
--
Christoph
Krischu wrote:
he came back on me and told me that the problem has been found. It was complicated and a coincidence of several factors.
Thanks for reporting back so the thread can be closed. It did not really look as a ESXi networking issue.