(upbeat music) >> Hey everyone. Welcome back to San Francisco, VMware Explorer 2022, Lisa Martin and Dave Nicholson here. We've been having some great conversations today. Lots of news coming out about VMware and its partner ecosystem. We're going to have another conversation about that next. Please welcome two guests to the program, Chance Bingen, technical marketing engineer at NetApp and Jason Massae, staff technical marketing architect, storage and vVols at VMware. Guys, welcome to the program. >> Thanks. >> Glad to be here. >> It's nice to be back in person. >> It is. It's very nice. Oh my gosh. >> And we're hearing there about 7,000 to 10,000 people here, when I was in the Keynote, this morning it was definitely standing room only. >> Yeah, yeah. You've definitely seen the numbers ticked up at the last minute. It was good to see that. It's good, I think a lot of people have really wanted to get back, get that one on one that face to face. There's nothing like being able to, you know, talk to, the experts, talk to the vendors, you know, see your comrades. I mean, that's the thing. I mean, we've seen people that I haven't seen for years, even on my own team, so really good to be back into it. >> It is and it was lots of news coming out this morning during the Keynote. My goodness. But Jason, talk to me, the NetApp and VMware folks had been in tight partnership for a long time. Talk to me about, get both of your perspective from a technical perspective about the depth of the partnership. >> Yeah, so actually NetApp was one of the original design partners for vVols. And with that, now with some of the stuff we're doing with more current stuff with virtual volumes is, NetApp is back and we've got some pretty neat stuff that we've been working on with vVols. And NetApp's got some pretty neat stuff that they've been working on to enable the customers with more features, more functionality with the virtual volume functionality. >> Yeah, absolutely. >> Give us a quick primer on what is a vVol? What is a virtual volume? How does it fit into the, into this stack of stuff that we do in IT? >> Yeah. So the easiest way to kind of think of what a vVol is or a virtual volume is you can think of it kind of like an RDM, those row device map, which is kind of a four letter word. We don't really like those, but the idea is that object, that virtual volume is native on the array and presented directly to the VM. But now what we do is we're presenting all of the storage array features up to vSphere and we're managing those storage features via policy based management. But instead of applying storage capabilities at a data store level, we're now applying them at a VM or an application level. So you can have one data store and multiple VMs, and every VM can have a different storage capability managed by a policy that the VI admin gets to manage now. So he doesn't have to go to the storage admin to say, I need a new line, or I need a new volume. He can just go in and create a policy or change a policy. And now that storage capability is applied to the VM or the application. >> Yeah. One thing I'd like to add to that is you can mentioned the word capabilities. >> So we look at the actual data protocols, whether they're file based or block based, you know, I-scuzzy, fiber channel, whatever the case might be. Those protocols have defined sets of capabilities and attributes and things they can expose. What vVols along with the VASA protocol brings to the table is the ability to expose things that are just impossible to expose via the data protocols themselves. So that the, actual nature of the array, what kind of array is it? What's it capable of doing? What is the nature of, you know, encryption? You know, is this going to be a secure, encrypted data store? Is it going to be something else? It just allows you to do so much more with the advanced capabilities that modern storage arrays have than you could ever do if you were just using the data protocols by themselves. >> Right? Yeah. Kind of under that same context. If you think about before with traditional storage, the vSphere or the array really doesn't understand what's going on underlying storage, but with vVols the array and vSphere completely understand at a disc level even, how that VM should be treated. So that helps the storage admin. Storage admin can now go in and see a specific disc of a VM and see the performance on the array. They can go in the array and see, oh, this disc on this VM has got performance issues or needs to be encrypted, or here's the size of that disc. And you couldn't easily see that with your traditional storage. So there's really a lot of benefits and it frees up a lot of time for the storage administrator and enables the VI admin to be able to do a lot of the storage management. >> So there have been, there been a lot of movements over the last decade in the realm of software defined storage. Where essentially all of the things that you are talking about are completely abstracted from the underlying hardware. In this case, you're leveraging the horsepower, if you will and the intelligence of a storage array that has a lot of horsepower and intelligence, and you're accessing those features. You mentioned encryption, whether if you're doing a snapshot or something like that, what's interesting here is it kind of maps to what we're looking at now, which is the trend in the direction of things like DPUs. >> If you go back in history long enough, we had the, you know, the TOE, NIC, TCP offload, you know, the idea of, hey, you know what, what if we had a smart device with its own brain power and we leveraged it. Well, you guys have been doing that from a vVols all perspective with NetApp filers, for lack of better term. For how long now, when did, when were they originally? >> 6.0 it was so it's been what? 11, 12 years. Something like that. >> It's been a while. So yeah, but it's been a decade or so. >> Mm-hmm >> So what's on the frontier. What's the latest there in terms of, in terms of cool stuff that's coming out. >> So actually today, in one of the things that we worked with NetApp that was part of the design partnership was, you know, the NVMe over Fabric protocol has become very popular to extend that functionality of all flash to the, an external array. And now we announce today, in including with that NVMe over Fabrics, you can now do vVols with NVMe over Fabrics. And again, that was something that we worked with NetApp to be a design partner for them. >> That's right. We're very excited about it. We've always been, you know, NVMe been something we've been very proud of for a while. Delivering the first end to end NVMe stack from inside the host, through the fabric, to the array, with the arrays front ports, all the way to the disc on the backend. So we're very excited about that. >> So target market joint NetApp, VMware customers, I presume. >> Really it's, the key here that I like to make sure customers understand is to see that vVols are on the leading edge of VMware's storage design. Some tend to think that maybe vVols wasn't the primary focus, but actually now it is the primary focus. Now I always like to give the caveat that VMFS and NFS are not going away. Those are still very much stuff that we work on. It's just that most of the engineering focus is on virtual volumes or vVols. >> Yeah. Similarly, when you talk about and you're sort of alluding to vSAN when we start talking about VMFS and things like that. >> Yeah. >> Architecturally, we've been talking to folks about the recent announcements with capabilities within AWS. You know, NetApp in AWS for VMware environments. Breaking out of the stranglehold that the, oh, you want more storage, you must buy more CPU and memory, building block process entails. The reality is no matter what you do with vSAN, you're going to have certain constraints that go away when now you have the option to leverage storage from the NetApp filers. >> Yeah, absolutely. >> So how does, how do vVols play in the cloud strategy moving forward? >> Well, so one of the things that we do with, vVols currently is mostly On-prem. But when you have the storage architecture, that vVols gives you as far as individual objects, it makes it much easier to migrate up into the cloud because you're not trying to migrate individual VMs that are on another type of system, whatever it might be, those objects are already their own entity. Right, so cloud, Tanzu, those type of things, those vVol objects are already their own entity. So it makes it very easy to migrate them on and off prem. >> So Chance talk to us a little bit about this from NetApp's perspective. You're in customer conversations, who are you talking to? Is this primarily an engineering conversation? Has this gone up the stack in terms of customers are finding themselves in this default multi-cloud environment? >> Yeah, so interestingly, when I talk to customers these days they are almost all either on a journey to a hybrid multi-cloud or they're in some kind of phase of transforming themselves into their own hyperscaler, right? They're be adopting a cloud service provider model and vVols is a perfect fit for that kind of model, because you have the ability to offer different tiers of service, different qualities of service with VM granular controls or VMDK granular controls, even. And even if you look at First Class Disc, right? Which is something that came out largely to support Tanzu, I think which fantastic use case for vVols as well there, but that gives you the ability to offer something like Amazon EBS, right? You can offer Amazon EBS in a native VMware stack using First Class Discs and vVols. And you're able to apply things like quality of service with that granular control that allows you to guarantee that customer the disc that they bought and paid for. They're going to get the IOPS that they're paying for because you're applying those QoS policies directly to that object on the array. And instead of having to worry about is the array going to be able to handle it? Are you going to have one VM that consumes all your IO, you know? You don't have to worry about that with vVols because you've got that integration with the array's native quality controls. >> And Chance what's in this for me as a customer? I'm hearing productivity, I'm hearing cost savings, control efficiency. Talk to me about the benefits in it for the folks that you're talking to. >> Yeah, absolutely. A lot of times it comes down to, you know I mentioned like the cloud service provider model, right? When you're looking to build a robust service catalog and you're able, you want to be able to meet all these like, we mentioned Tanzu, right? Containers as a service, you're able to provide the persistent volumes for your Kubernetes containers that are again, these native objects on the array and you have these fine grain controls, but it's handled at massive scale because it's all handled by storage policies, Kubernetes storage classes, which are natively mapped to VM storage policies through Tanzu. So it just, it gives you the ability to offer all of these services in a, again a rich and robust contents catalog. >> So what are you doing? So you mentioned a couple of things in terms of using array based quality of service. So give me an example of how you're avoiding issues of contention and over subscription in an environment where I'm an administrator and I've got this virtual volume that's servicing this VM or this app on this VM. What kind of visibility do I have down into the actual resources because look at the end of that chain there's a physical resource. And that physical resource represents, what? IOPS and bandwidth and latency and throughput and all of this bundle of things. So how do you avoid colliding with others who are trying to carve vVols out of this world? >> You mean like a noisy neighbor type of thing? >> Yeah. Yeah. >> So that's actually one of the big benefits that you get with vVols is that because those vial objects are native on the array, they're not sharing a loan or a volume. They're not sharing a resource. The only resource they're actually sharing is the array itself. So you don't get that typical noisy neighbor where this one's using all the resources of that volume because really you're looking out at the all encompassing array. And so a storage administrator and the VI admin have a lot more insight. The VI admin can now go to the storage admin if there's say a debugging issue, they want to find a problem. The storage admin now can see those individual objects and say, oh, well this VM, it's not really this, it's not all the discs. It's just disc number two or disc number three or they can actually see at a single disc level on the array, the performance, the latency, you know, the QS, all that stuff. >> Oh, absolutely. >> And that really is what, it frees up at the storage admin's time because the debugging is so much more simple. And it also allows the storage admin a lot more insight. Right? They know those, what's the problem. If you were typically looking at a loaner volume, they don't really know what's going on inside that and neither does the array. But with vVols, the array knows what each disc and how it's supposed to be treated based on the policies that the customer defines. So if one VM is supposed to have a certain QS and another VM isn't. The array knows that that VM, if it goes above it, it's going to be like, nope, you can't have those resources. You weren't granted those resources, but this one was. So you have much more control. And again, it's at an application or a VM level. >> And it's still, it's fairly dynamically configurable. I spoke to a customer just the other day. They are a cloud service provider. And what they do is their customers are able to go in and change their quality of service. So they go into that service portal and they say, okay, I'm paying for gold and I want platinum and they'll go in. They know that they've got a certain time where they need more IO capacity. So they'll go in, they'll pay the fee, increase that capability. And then when they don't need it anymore, they'll downgrade again. >> Okay, so that assumes some ability at the array level to do some sort of resource sharing and balancing to be able to go out and get, say more IO. Because again, fundamentally, if you have a virtual volume, that's drawing its resources from five storage devices, whether those are SSD based or NVMe or spinning disc that represents a finite it amount of resource. The assumption is if you're saying that the array is the pool that you need to worry about, that assumes the array has the ability to go beyond here, based on a policy. >> So that's how it works. It does... >> Well, essentially. I mean, you can't outrun physics. So if the array can't go faster, but the idea is that you understand the performance profile of your array and then you create your service tiers appropriately. >> Okay. >> Yeah. And one of the big benefits is like Chance was saying, if you want to change a profile that used to be a Storage vMotion to a different data store. Now it's just a policy change. The storage admin doesn't have to do anything. The VI admin just changes the policy. And then the array understands, oh, I now need to treat that different. And that's exactly what Chance was talking about in that cloud provider situation, where today I'm using a 100,000 IOPS. I need to use 200,000 tomorrow for special, whatever it is, but I only need to use it for tomorrow. So they don't have to move anything. They just change the policy for that time. And then they change it back. They don't have to do anything on the array itself. They don't have to change anything physically on the VM. It's just a policy change. And that's really where you get that dynamic control of the storage capability. >> So as business dynamics are changing and I'm thinking of like black Friday or Prime day, being able to dial things up and dial it down, they have the ability to do that with a policy. >> Yes. >> Exactly. >> So huge time savings there. >> Oh, it's huge. Yeah. >> Yeah. >> And it simplifies because now, I don't have to have multiple data stores. You can have one data store, all your VMs in there. You can limit test and dev and you can maximize business critical applications. Again, all via policy. So you've simplified your infrastructure. You've gone to more of a programmatic approach of managing your storage capabilities. But you're now managing at the VM level. >> So we mentioned that the cloud chaos (indistinct) that was mentioned this morning during the Keynote and we're saying a lot of customers are still in this cloud chaos phase. They want to get to Cloud Smart. How is this going to be one of those tools that helps customers pull the levers, dial the knobs, to be able to get to eventually, Cloud Smart. >> I could go on for this for hours. (Lisa Laughs) (Chance chuckles) This is really what simplifies storage. Because typically when you use traditional storage, you're going to have to figure out that this data store has this capability or another example, as you mentioned was Tanzu. If you're managing persistent volumes and you're not using something like vVols, if you want to get a certain storage capability, you have to either tag it or you have to create that data store with that capability. All of that goes away when you use vVols. So now that chaos of multiple data stores, multiple lines or multiple volumes, all that stuff goes away. So now you're simplifying your infrastructure, you have a programmatic approach to managing your storage and you can use it for all of your different types of workloads. So cloud, Kubernetes, persistent volumes, all that type of stuff. And again, all being managed via a simple and again, programmatic approach. So you could automate this. You know today, like you said, black Friday. Okay, Black, Friday's coming up. I want to change the policy. You could automate that. So you don't even have to go in and physically make the change of the policy now. You just say on Fridays, change it to this policy on Sunday night, change it back. >> Yep. >> Again, that's not something you can do with traditional storage. >> Okay. >> And I think from a simplification standpoint as well, you know, I was telling you about that other customer a couple days ago, they were running into the inability to grow beyond the bounds of VMFS file systems for very, very large VMs. And so what I talked to them about was look, if you go to vVols, you're not bound by file systems anymore. You have the capacity of the array and you can have VM discs up to 62 terabytes, you know, as many as you want. And it doesn't matter what they fit in because we can fit them all. So it's, to be able to, and that's some of our largest customers, the reason they go with vVols is to be able to grow beyond the bounds of traditional storage, anything like path limits, you know. That's something you have to contend with. >> Path limits, line limits, all that stuff. Typically just disappears with vVols. >> All those limits go away. Guys- >> They go away. >> Amazing. Congratulations on the work that you guys have done. Thank you so much for joining us on theCUBE talking about the value in it for customers and obviously the technical depths of the NetApp, VMware relationship. Guys, we appreciate your time. >> Yeah, thanks for having us on. >> Our pleasure. For my guests and Dave Nicholson. I'm Lisa Martin. You're watching theCUBE live from VMware Explorer 2022, Dave and I will be right back with our next guest. So stick around. (upbeat music)