So I have an application that uses a physical network failover card. It sends a heartbeat to the card to tell the card to stay online and get some info from it.
On a physical box it performs great, on esx, it sucks like a Kirby (vacuum cleaner:p).
The port settings the card wants are only 9600,8,n,1 no flow control.
Any idea why just sending a heartbeat every \*n* seconds would cause "tty input overruns" like crazy on the host?
I have an SR open, but they are being less than helpful at this point...
Most TTY ports have a 16-character input FIFO, and the default setting specifies that an interrupt is posted after 14 characters have been received. This error is reported when the driver interrupt handler cleared the input FIFO and data has been lost.
\- Verify that flow control is configured correctly. If it is, run diagnostics, and replace the hardware as appropriate.
\- If the problem happens on an idle system, move the workload to a different port. If that corrects the problem, upgrade the system firmware.
\- Reduce the line speed on this port (probably not supported in your case though)
BTW, what is the application?
Also, is this heartbeat really needed considering the native NIC failover available with ESX? Or does this VM actually interface with a physical server as well?
There may be some options here, but typically if an application is so dependent on non-standard physical hardware, it may not be a virtualization candidate.
It is an application that runs on an appliance. It interfaces directly with the card. It is so it can be inline of traffic and if there is a power failure/app hang or such the card will go into bypass mode and just emulate a physical card.
Wether or not it is a virtualization candidate is what I am testing :). At this point, I have 1 week to get this working or it will be a no go.
Still no word from VMWare support. 😕
The heartbeat is to tell the failover card that the app is still running.