Corruption isn't going to be entirely preventable when you're dealing with ~1-hour loss of storage connectivity - certainly not by tuning some SCSI timeout variable in the hypervisor or OS.
Your inability to renew warranty is unfortunate, but normal for 7.2k disk Equallogic systems which are limited to 5 years max warranty (10K/15K/SSD units can go out to 7 years). I would link to the EQL "Release and Support Guidelines" PDF, but access to the support page where it's hosted requires an active warranty.
You stated that only your "old" Debian VMs experience serious problems afterward - perhaps this is related to which file system they're using, and/or how your mounts are configured? (e.g. data=journal/ordered/writeback)
no logs, no nothing to help us discover what happens
This is highly unlikely, though many sets of log data can be difficult to obtain without previous experience/familiarity in gathering and analyzing them.
How do you know that this was a storage problem? What events/errors or behavior did you observe that lead to this conclusion?
@Dom asked a great question in a comment regarding switch logs. Equallogic diagnostics are not built around end-user readability, but switch logs should be fully accessible and readable if logging is actually in place.
If you don't have the budget to replace a SAN after it's end of service life / supportability, you can't afford to have one in the first place. I know that's completely hindsight and doesn't help you, but you should seriously consider moving off the EQL storage and onto something less expensive (like multiple servers, local storage only, and replicate VMs with something like DRBD). A SAN can be great, but it's a serious financial commitment too.
