Indeed, quite a few of the presentations I've seen have proposed that a good software stack in a hypervisor (especially the rather ascetic, monkishly obsessive container-based subtype) has been written to survive use in a lowest common denominator network infrastructure, with a cheap zero-feature network switch humbly chucking Layer 2 packets around without adding anything to the party.
I have some sympathy with this design decision, because no matter how much one might want the server buying public to "get" the value of smart LAN switches, the reality is that most of them look to Cisco for that stuff, and the look is not one of immediate faith and satisfaction. Most server types view the prospect of a VLAN or of a traffic management process sitting neck-deep in an unlimited reservoir of fear and loathing. Most of this faction imagined that SDN would move all the smarts from the LAN switch, inside a nice comfy backed-up server.
Vanhamme agreed that this is a large part of the problem, but was quick to point out how important it is to be clear about the newer, simpler (ok, that's a nicer word than "cruder") network topologies and options which become possible once you have a switch that slots itself seamlessly into your VM management picture. He used the word 'fabric' to discuss this. I tried to persuade him that while hardened LAN people know what this means, it's so ambiguous once you include hardened virtualisers in your audience that you're better off not using it. The bottom line for me is that he's quite right - sheer cable-count is a major barrier to reliability. This is due to reasons arising from human failings rather than limitations of architecture, and the rate of compression achievable with 21st century operating systems both as hypervisors and guests is making a complete view across both the physical layer and the logical/virtual network-address and VLAN topology progressively more important.
Microsoft has gone for a solution to this problem that involves encapsulating bursts of Cisco IOS script language in Powershell scripts, trying to bridge two utterly different generations of technology since that's what is likely to be found out in the corporate data centre (if not in the public-cloud data centre). I think the Dell approach is less troublesome - not least because both Vanhamme and I have seen the truth of most managed network switch deployments, which is that they are nasty, ad-hoc, typed-in bodges layered on year after year with very little rationalisation or re-engineering.
The second-by-second dependency level and the sheer brain-bending complexity of thinking in the five dimensions required by VLAN, OSPF and LACP and other advanced networking concepts conspires to make downtime something that managed switches never see. That, and the massively increased role played by the previously humble switch now that network and VM portfolio are indistinguishable, really demands that the whole business engages in the kind of smart rethink that evidently, Dell is ready to show everyone right now.
