 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 Bingin, Technical Marketing Engineer at NetApp and Jason Massay, 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's 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. 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 talk to the experts, talk to the vendors, see your comrades. I mean, that's the thing. I'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 have been in tight partnership for a long time. Talk to me about what, get both of your perspectives from a technical perspective about the depths 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. Yeah, give us a quick primer on what is a VVOL? What is a virtual volume? How does it fit into the 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 RDN, those Rod of Ice 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 like to add to that is, you mentioned the word capabilities. Yes. So we look at the actual data protocols, whether they're file-based or block-based, iSCSI, 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 the actual, the nature of the array, what kind of array is it? What's it capable of doing? What is the nature of encryption? Is this going to be a secure encrypted data storage? Are there 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 under the underlying storage, but with VVOLs, the array and vSphere completely understand at a disk level even, how that VM should be treated. So that helps the storage admin. Storage admin can now go in and see a specific disk of a VM and see the performance on the array. They can go in the array and see, oh, this disk on this VM has got performance issues or needs to be encrypted or here's the size of that disk 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's been a lot of movements over the last decade in the realm of software defined storage where essentially all of the things that you're 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 you're doing a snapshot or something like that, but it'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 toe nick, TCP offload, 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 V-Vol perspective with NetApp Filers, for lack of better term. For how long now, when were they originally? Was it 6.0? So it's been, what, 11, 12 years? It's been a while, so yeah, but it's been a decade or so. So what's on the frontier? What's the latest there in terms of cool stuff that's coming out? So actually today, and one of the things that we worked with NetApp, that was part of the design partnership, was the NVMe over fabric protocol has become very popular. To extend that functionality of all flash to an external array, and now we announced today in including with that NVMe over fabrics, you can now do V-Vols with NVMe over fabrics. And again, that was something that we worked with NetApp to be a design partner for that. That's right, we're very excited about it. We've always been, you know, NVMe's been something we've been very proud of for a while, delivering the first end-to-end NVMe stack from inside the hose through the fabric, to the array with the raised front end ports all the way to the disc on the back end. 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 V-Vols are on the leading edge of VMware's storage design. Some tend to think that maybe V-Vols wasn't the primary focus, but actually now it is the primary focus. Now I always like to give the caveat that VMFS and NFFS 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 V-Vols. Yeah, similarly when you talk about, and you're sort of alluding to V-SAN when we start talking about VMFS and things like that. Architecturally, we've been talking to folks about the recent announcements with capabilities within AWS, 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 V-SAN, 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 do V-Vols play in the cloud strategy moving forward? Well, so one of the things that we do, V-Vols currently is mostly on-prem. But when you have the storage architecture that V-Vols 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 V-Vol 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 adopting a cloud service provider model and V-Vols 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 like first-class disk, right? Which is something that came out largely to support Tanzu, I think, there's a fantastic use case for V-Vols 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 disks and V-Vols and you're able to apply things like quality of service with that granular control that allows you to guarantee that customer the disk 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, you know, 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 V-Vols 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 Tanzi, 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-grained 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 oversubscription 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? So 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 VVOL objects are native on the array, they're not sharing a line 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 now at the all-encompassing array. And so the 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 disks, it's just disk number two or disk number three or they can actually see at a single disk level on the array, the performance, the latency, the QoS, all that stuff. Oh, absolutely. And that really is what, it frees up the storage admin's time because the debugging is so much more simple. And it also allows the storage admin a lot more insight. They didn't know those, what's the problem? Because if you were typically looking at a learner of volume, they don't really know what's going on inside that. And neither does the array, but with V-Balls, the array knows what each disk 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 QoS 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 fairly dynamically configurable. I spoke to a customer just the other day. They are a cloud service provider. And what they do, 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. 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 disk, that represents a finite 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? 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, and one of the big benefits is, like Chance was saying, if you want to change a profile, that used to be a storage of emotion to a different data store. Now it's just a policy change. A 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 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. 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. We mentioned that the cloud chaos term that was mentioned this morning during the keynote in VMware saying a lot of customers are still in this cloud chaos phase. They want to get to CloudSmart. 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 CloudSmart? I could go on for this for hours. 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 Vibals, 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 Vibals. 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. Today, like you said, Black Friday. Okay, Black Friday is 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. 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 of days ago, who they were running into an 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 VVol's, you're not bound by file systems anymore. You have the capacity of the array and you can have VM disks up to 62 terabytes, 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, you know, some of our largest customers, the reason they go with VVol's 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, LUN limits, all that stuff typically just disappears with VVol. All those limits go away. Guys, 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. Thank you very much. Thank you 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.