Derek Leslie

So with the data store, we had a few more challenges.

And we solve that by partnering with VMware with storage IO control.

So it assigns shares on a per VM basis.

And we take those shares, those get interpreted as min IOPS.

So no matter where that VM goes, what data store it goes to, it always has the minimal amount of IOPS it has.

And we do a multiplier for max.

And then the storage IO control, it assumes that the underlying storage is consistent always there and has the IOPS that it expects.

And then it can enforce the fairness.

So without that, it can't really enforce the fairness.

So we're able to do this per tenant guaranteed QoS or per application QoS either way.

And it's good to have options and even try both if you're a new customer looking at which option is best for you.

I can't say that with confidence because I'm not seeing the market evidence.

I see the anecdotal evidence of, wow, this sounds great.

It really meets our architecture needs, and I wish people would do it.

We do have some very large customers that are using vBalls, but I'm consistently surprised when I do hear,

some of our largest partners and customers saying, you know what, it's just not for us, we're not going to do it.

And that could be two reasons.

One, this is the way I'm always used to doing it, and I don't see the advantages of changing.

And it's a new way, like how many years have we been provisioning our applications on data stores?

And I don't think people are just going to switch to vVols immediately.