• Some users have recently had their accounts hijacked. It seems that the now defunct EVGA forums might have compromised your password there and seems many are using the same PW here. We would suggest you UPDATE YOUR PASSWORD and TURN ON 2FA for your account here to further secure it. None of the compromised accounts had 2FA turned on.
    Once you have enabled 2FA, your account will be updated soon to show a badge, letting other members know that you use 2FA to protect your account. This should be beneficial for everyone that uses FSFT.

ESXI 5.1 CRASH

D

digfut

n00b
Joined
Apr 1, 2015
Messages
4
Hello,

This is my first post in this forum, sorry if my english is not very good.

I have a ESXI 5.1 server (HP SE316M1/DL 160 G6) with 3 virtual machines, it has been working perfectly for more than a month. Server has 16GB RAM, 14GB for the machines and 2 GB left for the host.

Since last Friday I got 3 issues where virtual machines where unresponsive (although they appear as running on host), host was working and I was able to manage it through SSH and client.

After a reboot all is running correctly.

This has happened 3 times in last 4 days.

No hardware issues are found in ESXi report.

No RAID controller or drives issues found in hpacucli report (my controller is HP Smart Array P410).

I checked vmkwarning.log and found these lines at the time of last incident:

2015-03-31T01:20:34.165Z cpu0:4588)WARNING: LinuxSignal: 761: ignored unexpected signal flags 0x2 (sig 17)
2015-03-31T01:20:39.428Z cpu14:4534)WARNING: Team.etherswitch: TeamES_Activate:309:Failed to initialize beaconing on portset 'pps': Not implemented.
2015-03-31T01:20:47.329Z cpu12:4534)WARNING: Uplink: 3075: releasing cap 0x0!
2015-03-31T01:20:47.329Z cpu12:4534)WARNING: Uplink: 3075: releasing cap 0x0!
2015-03-31T01:20:47.329Z cpu12:4534)WARNING: Uplink: 3075: releasing cap 0x0!
2015-03-31T01:20:47.329Z cpu12:4534)WARNING: Uplink: 3075: releasing cap 0x0!
2015-03-31T01:20:47.473Z cpu12:4723)WARNING: LinuxSignal: 761: ignored unexpected signal flags 0x2 (sig 17)
2015-03-31T01:21:28.226Z cpu9:5860)WARNING: UserTeletype: 1639: Unknown cmd 0x5409 (data 0x1) for slave
2015-03-31T01:21:29.948Z cpu13:5876)WARNING: MemSched: 6105: Psharing is disabled but balooning is not.

What would explain that host works perfectly and all 3 machines stopped responding at same time? they appear as running on host panel. If it was a hardware issue (memory, processor, disk...) then host would hangs too, right?.

Can you shed any light on this?, this is a production server so I´m very worried.

Regards.
 
Would need more information on "unresponsive" - I assume you mean that whatever network resource they provide becomes unavailable?
Did you open a console on the VM to check the VM itself?
What troubleshooting have you done? Have you tried something like just restarting services on the host? Look in vxpa.log as well as hostd.log as well.
 
Hi,

Thanks for your replies.

Unresponsive means that I can´t ping virtual machines, they are isolated from network. Can´t even open VM consoles on the host.

OS of virtual machines are 2 Linux CentOS 7 and 1 Windows Server 2012 R2.
 
What happens when you open the console? Likely an error pops up which will be very relevant. My guess right now off the limited information is an issue with the services... vxpa and hostd logs are where you want to look through to start. The true gurus may chime in and school me on why I'm wrong though :)
 
Update, I removed bonding in vswitch and server it´s working fine for more than 27 hours. Will watch it, maybe guys on datacenter changed physical switch so there isn´t bonding there anymore.
 
Can you try using a vmxnet3 NIC on the Windows VM? This is a workaround.:)

I had something like this before while running ESXi 5.1 and 2012R2, you should upgrade to ESXi 5.5 for a permanent fix
 
I was looking at this thread and it looks like something puked in your vswitch.

I'd engage VMware support on this one.
 
digfut said:
Update, I removed bonding in vswitch and server it´s working fine for more than 27 hours. Will watch it, maybe guys on datacenter changed physical switch so there isn´t bonding there anymore.
Click to expand...

I had this exact same behavior on lab gear with a failed bond, (LCAP on vmware end, but not on the switch), I'd definitely ask the question before getting vmware involved on a support case.
 
sorry for not posting before, the issue was one of the integrated NIC cards. Installing a PCI NIC card and disabling the faulty solved the problem.
 
You must log in or register to reply here.
Back
Top