Is Trevor Pott-y? Nope – he's bang on about VSAN performance

I don’t always agree with fellow Reg storage man Trevor Pott but this piece on Server SAN, VSAN and storage acceleration is spot on with its questions about VSAN running in the kernel and the advantages that brings to performance. Indeed, I’ve also heard comments about reliability, support and the likes over competing products …

[@hansdeleenheer]

The Hypervisor Commodity is a Fairy Tale

I agree on most of the storage comments here. There is one thing I have to answer on: it won't really help running the same storage layer in different Hypervisors if the Hypervisor is not a commodity to the VM. Today there are at least 3 proprietary parts of the VM that make this impossible:

* the VM config file is proprietary to the hypervisor

* the VM disk format is proprietary to the hypervisor

* the VM guest drivers are proprietary to the hypervisor

So as long as the VM is not a standard, which it probably never will and the way people want to solve this is with even more layers on top, I'd rather use a VSA model for distributed storage over multiple hypervisors than having the storage vendors design their storage controller code for different kernels (Linux, ESX, Windows).

[Jim 59]

vSAN / san

Comparing "vsans" against "server san" or normal SAN, it becomes a question of which model involves less overhead. The referenced article points out the inconsistency in VMware's argument - they say their hypervisor is perfect, but they also say Vsans are much more perfect because they avoid the hypervisor and run "in the kernel".

Wading through the morrass of sales terms, it seems that Vsan is running in "super" kernel mode, ie. at level 0, the same as the hypervisor, the highest privileged level in the whole platform. Normal storage (including "Server san") would run one level down from that, at level 1, in "kernel mode" within a VM.

If VMware claim Vsan is any faster, they are sort of saying it is more direct than the raw storage pass-through model used by their conventional VM SAN storage. Only they really know the answer. But it is hard to see how the vSAN can be much more direct than a simple raw device pass-through, or to visualise the ton of overhead that VMware are now claiming must be hampering one product but not the other. Any benchmarks ?

[P. Lee]

Ah, Overhead

What you really want is for the OS to do its job and develop past the late 1990's.

VMs are a band-aid to solve a problem that the OS should be doing. The OS is supposed to manage access to resources. The OS is supposed to stop apps interfering with each other. Could we not have the OS manage multiple versions of libraries? Could we not have a little manifest file for each application which says, "I need these resources: x,y,z" Could we not have network-based resource publishing and discovery (even if loopback) rather than using a flaky registry database?

Why do we need to emulate entire machines in order to get these functions? How is it that VMware and hyper-V can do it, but straight Windows can't.

Oh right, we'd rather sell you another product than develop the first one.