Grey Beards on Systems - GreyBeards talk VVOLs with “Father of VVOLs”, Satyam Vaghani, CTO PernixData

Episode Date: February 12, 2015

In this podcast we discuss VMware VVOLs with Satyam Vaghani, Co-Founder and CTO PernixData. In Satyam’s previous job, he was VMware’s Principal Engineer and Storage CTO   and worked extensively on VVOLs and other VMware storage enhancements. He also happens to be the GreyBeards second repeat guest. With vSphere 6 coming out by the end  of this … Continue reading "GreyBeards talk VVOLs with “Father of VVOLs”, Satyam Vaghani, CTO PernixData"

Hey everybody, Ray Lucchese here and Howard Marks here. Welcome to the next episode of Greybeards on Storage monthly podcast, the show where we get Greybeards storage and system bloggers to talk with storage and system vendors to discuss upcoming products, technologies, and trends affecting the data center today. Welcome to the 17th episode of Graybridge on Storage, which was recorded February 5, 2015. We have with us here today our first repeat guest, Sachem Bhagani, whose PR group calls the father of VVALS, who also happens to be the CTO of Pernix Data.

Why don't you tell us what VVALS all about and why should we care, Sachin? Hey, guys. Great to be back again. I didn't know I was the first repeat guest. You are. You should feel honored. Oh, I am. Oh, please.

In fact, I'm so honored I feel like Tom Brady doing a repeat. Oh, God. Don't go there. Anyway, but no, thanks for having me again, guys. We're always glad to chat with you, Satya. Yeah. So what's all the hype about this VVOL stuff? Oh, well, you know, I'm so excited. It's a new type of storage abstraction that VMs, virtual machines, can now use out of storage systems.

And so, unlike the old world, where virtual machines would consume storage that wasn't quite invented for virtual machines, you know, things like NAS data stores or LUNs, now in this new world in the v-wall world virtual machines can store virtual disks as first-class entities on the storage system and in return the storage system can provide data services on not lunch not data stores but on virtual disks. And so now you can snapshot a virtual machine, and the storage system would actually take the VM snapshot as opposed to VMware having to do it as an intermediary,

and so on and so forth. So it's very exciting, because for the first time, storage systems will recognize virtual machines as entities. And so in some sense, you can say that this is a great step towards application-centric storage. As you know, the storage system recognizes the exact object that the application wants to transact and then provides data services on top of that object. So the traditional ways of doing this would be a LUN or as part of a NAS datastore or something like that,

you'd be creating VMDK files types of things. Is that how it worked before? That's right. And, you know, the problem with that situation being that most of the storage data services that systems are typically, you know, storage systems are typically used to doing, that they differentiate themselves with, you know, things like snapshots, replication,

you know, compression, encryption, cloning, et cetera. Quality of service. Quality of service. Although, you know, when it comes to storage and quality of service, I don't think the two things belong in the same sentence. Whoa! Okay. So this is going to be an interesting podcast.

Jesus, why would you say such a thing? Well, that's a different story. All right, well, go on. Go on. I'm sorry. We are getting there. We are getting there. But let's be honest, right?

I mean, quality storage, that's an oxymoron right there. You must be talking as a CTO of Pernix Data here. Yeah, you know, we are one of the guys trying to make that happen, right? I guess. We are one of the guys trying to make that happen, right? He hasn't completely given up speaking as the guy who designed all of what VMware does as storage. Because when he talks about VMware snapshots, he says, rather than having vSphere act as an intermediary instead of the rest of us who say, instead of using those crappy VMware snapshots. Yeah, can't call my baby ugly. No, you can't. Yeah, I understand.

It was pretty ugly. I mean, well, it's as beautiful as me. So getting back to this vBalls stuff here. So from a user perspective, what does it mean that I'm going to be using vBalls versus not using vVols? You're saying from a VM user perspective? Actually, more like an admin.

I guess a VM vCenter admin kind of thing. Oh, right. So, well, lots of exciting changes. But I think there's four very interesting things. In fact, I talked about it back at VMworld 2011, I think there's four very interesting things. In fact, I talked about it back at VMworld 2011, I think. It was a session called VSP 3205. It was a long time ago. A long time ago.

But then the four most exciting things were there's this concept of a storage container, right? So instead of carving out LUNs and then our NFS data stores and then having the data store be assignment of capacity to the end user, to the VM administrator, you could just assign capacity in abstract. So you can just say, well, you know, the VM administrator is entitled to three terabytes of storage. However they want to use it. I mean, they could use those three terabytes

as 3,100 gigabyte disks, or they could use the three terabytes as one three terabyte disk. It doesn't matter. And so now the storage administrator doesn't really quite need to figure out how many ways those three terabytes is going to be, you know, chopped up into, right?

They don't have to worry about presenting that assignment as a LUN or an NFS data store. So that's very exciting, because now you can actually do storage capacity policies, capacity assignment, without really having to carve out LUNs to actually make that capacity assignment come true. Yeah, but speaking as a traditionalist here, if it's not a LUN and it's not a file, what is it? Well, if it's an NFS data store, it's still a file. And so you can do vVols on NFS and it's still a file.

That's true. Although, you know, that's an implementation-specific detail. So at least by the vVol spec, an NFS data store can decide to actually serve a vVol object in a way that doesn't directly map to an NFS file, and that's totally fine. In fact, that's the second part I was going to talk about, right, which is, you know, the second very interesting thing about VVols

is the fact that the protocol is now, you know, whether it's NFS, iSCSI, Fiber Channel, it's now only used to get packets from the server to the storage system instead of the protocol being used as a presentation layer. So we're not talking about, not talking about now exporting virtual machine disks as NFS files necessarily or virtual machine disks as VMFS files or virtual machine disks as things on a iSCSI LAN. So all that is abstracted away. The technique of getting the traffic from the server to the storage

system is an infrastructure problem, right? It's not an application problem. So we abstract it away and the application doesn't have to deal with talk in infrastructure terminology like LUNs and files. So as a metaphor, you can think of VVOL as a micro LUN. That if you have a sufficiently small environment and you say, I'm going to put one virtual machine in each LUN on my storage system, then I could do application consistent snapshots and I could do per application replication because I've got one application per LUN.

But you can't manage that. First of all, SCSI breaks... It's just a proliferation, yeah. Well, and you can only have 256 connections. So one server can't talk to more than 256 LUNs using the standard protocols on one array. Even though they might support 65,000 LUNs. But not over one connection.

Not for one initiator talking to one target. Yeah, yeah. And so vVols eliminates those two problems and then gives you all the advantages of having lots of little LUNs, which is you can provide all kinds of differentiated services. Saddam, you mentioned something that's sort of interesting here. You said you no longer use the protocol, almost implying not to do I.O., but to just send packets of information between the VM server and the storage. Is that what you said?

Did I understand that correctly? Yes. And, of course, you know, that's the abstract view of it. In reality, what it means is that, you know, a block storage system would export one LUN, which happens to be this magical LUN. It really doesn't contain any data, but that's a way. The magic LUN.

Yeah, exactly. To get packets across, right? Because, you know, SCSI really wants to address things to a LAN. So we figured we'll just give it this magic LAN that all packets can go to. The packets can belong to, you know, different virtual machine objects, which are then demultiplexed at the storage system layer, right? So it would figure out for all the incoming packets, it would be the post office, right?

It would actually separate it out on a per VM basis. A data post office, I like that. All right, so you're sending these packets across this magic, to this magic one saying that I want to create an object that's this size, it has these characteristics, et cetera, et cetera. So you're doing what I call control activity. I hear a no here. So what are you doing with this magic line?

So, Sachan, let me see if I got it right. So what happens is that the read and write IO requests go across Fiber Channel or iSCSI to the magic LUN. To the magic LUN? Right. What? the server that has 20 vVols that it's working with will only be connected to one LUN, the container. Is it the same magic LUN for all vVols in the whole world of ESX clusters and stuff like that, or is it one per ESX server?

Most arrays will probably publish one of these container LUNs. And you're going to do all the data traffic through that magic LUN? Yeah, so what vVols does is it encodes which sub LUN of the magic LUN, which vVol. And then which block as part of each read

and write request. I can't see Ray right now, but I can totally see that this is blowing his mind. Hey, by the way, guys, maybe we should stop talking about the LUN being a magic LUN, because I think we all sound like that senator who talked about the internet being pipes. The tubes. There's a logical LUN. All right, but even if there's a logical LUN, you're going to use this logical LUN. Even if there's a logical LUN, you're going to use this logical LUN as effectively a pipe for all the data

that's going between an ESX server or multiple ESX servers in some cases to the storage system. Is there going to be some sort of queuing problems there? Normally a storage system can do activities on multiple LUNs pretty easily and parallelize them, but when you're

starting to do activity on a single real LUN, I'll call it a real LUN, you know, it's not very parallelizable. So, Ray? Yes, sir. So each of those requests that's going to, and let's call it, you know, LUN 0, our container LUN. Yes. Has each of those requests, instead of just saying write this to block 7 million, says write this to sub 1-14 block 7 million. So there's a multiplexer process.

But then there's this queuing delay and stuff, so I'm going to try to write to this. Yeah, right. So there's a multiplexer process that runs in the array. It's all these requests by sublun by to by vvol and then all those processes to the multiple vvols can occur in parallel and and let me answer about the queuing delay right i think you have a point at least you know come in the context of traditional scuzzy architectures but out here what's going to happen is really the throughput to the storage system is dictated by the number of paths you have.

And then, as you must have known, in recent years, two good things have happened, right? Which is, you know, the queue depths have gone really, gone up on the initiator side, right? So that'll help. And then, you know, most storage systems have either become active-active or ALUA-type active-passive, right?

So they can actually now productively use all those paths that are leading out from the server to the storage system as opposed to using just one path and treating the other 64 or whatever, 16 paths, just to be standby paths, right? So given that those changes have happened, you know, the throughput from the server to the storage system

or the ability to multiplex traffic across multiple links going from the server to the storage system, in my opinion... To one, container one, right? Go ahead, I'm sorry. Right, so in my opinion, you know, that problem has been addressed, right? Or, you know, mostly solved for now. And so at this point, the LUN being the abstraction at which you do QoS, i.e. queuing, is not necessarily true. In fact, now it's the opposite, which is the LUN being an abstraction to do queuing or any kind of QoS, quality of service, traffic shaping,

all that stuff is not great architecture because the LUN doesn't mean anything, right? It doesn't mean any particular application, nothing like that. So why are we kind of, you know, even making features on top of that abstraction? Only because you've transformed the concept of LUN to be something different. But let's go on.

So you said there were four. But, Ray, you can see we needed – that that had to happen to get around the protocol issues. Yeah, maybe. I don't know. I'd have to think about what it means to have 1,000 microlons and only maybe 16 macrolons or something. Metalons, I don't know. Right. All right. So let's go back. The magic LUN we talked about, or the macro LUN we talked about, in the VWOL spec, it is called the protocol endpoint. Yeah, protocol endpoint, yeah. Just so that our listeners can make the connection.

And so I wanted to mention that. The other thing is those thousands of micro LUNs, or the VWOLs, really, the virtual volumes that are sitting behind the protocol endpoints can now be very dynamically created and deleted and snapshotted and so on without changing the presentation layer, right? Without changing any multipathing policy, et cetera. That, again, is a big, big deal, right? Because in the old world, even if one was to be able to create one LAN per virtual machine, it was a horrifying process to actually present that LAN back to the server

so that the virtual machine can use it. And so now we are solving that problem too, is that we are decoupling the process of creating all these objects, the micro LANs, if you will, or the vVols, from the process of presenting the said object. But the presentation, zoning and all that stuff that was going into that insane process, all that stuff gets… It gets solved, right? Because zoning, multipathing, et cetera, has to be configured only once. And on a protocol endpoint basis, right?

So that's a big deal. You don't need to touch physical infrastructure. But the function that zoning provided, keeping server B from seeing server A's volumes, gets taken care of in the vSphere infrastructure. That's right. And it gets taken care of in the vSphere infrastructure. That's right. And it gets taken care of. You won't believe this, guys. It gets taken care of in a, wait for it, software-defined way. Oh, that hurt.

That hurt. So is that the third nicety thing here, the whole presentation discussion? Is that the third nice thing that vVols creates for people the admin so that was the second nice thing right we talked about a nice thing okay all endpoint and you know solving the presentation problem solving the LUN proliferation problem the third nice thing is that you can create storage profiles on a disk array, right, on a storage system. And that profile can use any number of very interesting features that the storage system is able to provide. And then you just get to name that profile foo. And then automatically,

that profile is piped out of band to the vSphere layer, so that the vSphere layer can now provision virtual machines on top of that profile. Now, the vSphere layer doesn't really need to understand that for profile A, the storage system is going to put all the blocks on really fast storage. It's going to give you five-minute RPO replication, blah, blah, blah, you know, hourly snapshots. It doesn't have to understand that. It just needs to understand that there is a profile called gold,

and I'm able to consume it, and I'm able to provision as many number of virtual machines I want out of the gold profile. And that profile is done at the storage system for the protocol endpoint? So I would create foo, fi, fee, fum, or whatever? The three protocol profiles? And those three profiles would be published

by the one protocol endpoint as options a VM administrator could use to provision a new vBall. And the interesting part of this is that it really is software-defined. That if we talk about software-defined, if we talk about software-defined in terms of software-defined networking, where software-defined means we separate the control plane from the data plane, VVOL does that through VASA. So things like provisioning a new VVOL happen out of band via IP from the vCenter server to the storage array. Huh? It wouldn't come across the container LUN?

No, it won't. No, no. There isn't a Fibre Channel command for create a LUN. Well, there's no Fibre Channel command for sub LUN either, I mean, to some extent. You're creating this protocol endpoint. There's a field we hid that in. But you're creating this protocol endpoint to do

effectively micro-LUN IO, right? But you're not using it to provision storage? Well, we are, but the fiber channel or the iSCSI is just the data path. The control path is separate. That's right. Different IP address, different network, different protocol. This is separation of control from data, right? I mean, you know, the data path only needs to come active when you have IOTO, right? You don't need to run provisioning operations, snapshotting operations, replication operations

on the data path, because why is that even necessary, right? The data path is necessary only to run a virtual machine. So in the old days, it meant to be a vCenter plug-in for somebody to say, okay, you want to provision storage, and it would talk whatever its internal protocol

to the storage system to say okay carve out a lun or carve out a file system directory or something like that that's how it worked in the old days right right and so now through vasa 2.0 there's a standard api for all of those functions that the array follows so the array publishes via VASA 2.0 its capabilities to vCenter in a XML format that everybody's agreed to.

And then the VM administrator says create a new virtual disk on my Exchange server. And vCenter, using this same defined API, tells the array, create that vVol for it. Yeah. All right.

I like it. It's almost like SMIS, only without the pain. Yeah, exactly. Without trying to do everything all at once. Yeah, yeah, yeah, yeah, yeah. That's right. And it's like SMIS, except it works. Ouch.

All right, so you've covered three of the nice things that VVol supplies. What's the fourth nice thing? You know, I lost my train of thought. So we talked about LUN proliferation and provisioning and storage containers and storage profiles. So, I mean, to a large extent, you know, I'm a storage system. I could say I support Snapshot and replication and all this stuff. Does VVols and VASA2 supply a capability to say, okay, I want you to use Snapshot for these guys and replication for those guys?

I mean, or is that part of this profile stuff? In fact, in the VWOL world, what happens is all the traditional VMware control paths, the control path to Snapshot a virtual machine, the control path to replicate a virtual machine through SRM, the control path to clone a virtual machine through vCenter, all those control paths are now rerouted through the VASA control part to clone a virtual machine through vCenter, all those control parts are now rerouted through the VASA infrastructure directly to the storage system.

So now when you ask for a copy of a virtual machine, it goes directly to the storage system saying copy object number one, object number three, object number seven, because those happen to be the three virtual disks that the VM is using. And there you have it. And so similarly when you're trying to snapshot a virtual machine, where the virtual machine is using a particular virtual volume, the snapshotting command

is going to go out of band through the Vasa API to the storage system, and a snapshot will be created. So this is a big improvement on the status quo. Like I was saying at the beginning of the podcast, right, is every virtual machine operation can now be directly handled by the storage system. And it can do it in a way that is much more efficient, right?

Because, you know, the data is right there with the storage system. It can do it in a, you know, it can use, for example, techniques like deduplication or, you know, thin provisioning, thin cloning. I'm sorry, fast cloning, if it wants to make copies and the vSphere layer doesn't have to worry about it. And so in some sense, you know, this is going to open up an arms race

within storage systems, right? As now there is a possibility for infinite innovation at the storage systems layer, which can be directly leveraged by virtual machines. And so in the old world, the problem was that, you know, all the innovation at the storage systems layer couldn't be leveraged by virtual machines because VMs didn't map one-to-one

with the objects that the storage systems presented. I mean, what's the point of creating LAN level snapshots if, you know, you are going to store 50 VMs on a LAN, right? So now you can't really use hardware snapshotting because there is no, if you take a snapshot, it's like, which VM does that snapshot belong to? It wasn't clear, right? Well, you can't get application consistent, and the snapshots are huge because you're grabbing all sorts of data you didn't need from the other VMs.

Exactly, and you couldn't even orchestrate it, right? There was no API to even call into that snapshotting layer. BCOPS and stuff like that, you couldn't automate it through that? I mean, you could, but it was painful. Yes, it was very vendor-specific. And in fact, some vendors made those plugins, right? But even in spite of making those plugins,

they couldn't actually get into the VMware workflows. So they couldn't get into the VMware snapshotting model. And so they could make their own snapshots on the side. But if you press the VM snapshot button inside vCenter, you wouldn't get a storage system snapshot, right? But now you can. And that's exactly it. If I want to do a

Tintree snapshot, I've got to go into the web interface on the Tintree. So, in my mind, you've turned off all the QoS that any of these storage subsystems and all that stuff. It's all gone at this point, right? Well, no, it's been shifted down. The good news is it's been shifted down to the micro one.

So think about a storage system like a SolidFire or a NextGen that does QoS relatively well. The problem is that if you've got five business-critical servers all in the same LUN, that LUN is protected from noisy neighbors from outside the LUN. But it's not protected from noisy neighbors within the LUN. Yeah. And so now we can say, okay, we're going to do quality of service at the VVOLS level. This would seem to be an extreme implementation problem for storage vendors to provide these capabilities. That's the trick.

If you've got a storage system that was designed in the last five years, it does everything with metadata about small blocks yeah and so now putting being able to manage a million volumes which is really what we're talking about here between the the vms and this you know and each snapshot is going to be treated like a volume well that you already have the metadata structures to do that you just have to modify them to support a million instead of the thousand that you supported in your initial release but if you're a storage system like a clarion where uh all of the meta you know where there isn't any metadata where you're just mapping you know there's you go here's the raid set and i'm just going to take this physical block and map it one to one

in an increment all right you don't have you can't support a million volumes you don't have the architecture to do it so some guy some people are going to find it relatively easy. And have made the switch, mental switch, to going to this mode. Right. Well, you remember 10 years ago we used to argue about NetApp iSCSI volumes, how they weren't really blocked because they were a file within the file system and there was all that overhead. Yeah. No. there was all that overhead yeah no but but but today every every modern storage system has

essentially even if it's a block storage system it has what you would call a file system the files are volumes yeah yeah yeah yeah um and so if you've got a file system that that was already pretty good and you just had to tweak it a little to support a million volumes, then this is going to be a good thing for you. And if you didn't have that kind of structure, it showed the vendors who were going to support vVols in the first half of 2015 and the ones that were going to support vVols later. And EMC was in the later half, which I took actually as a positive step, because if Papa EMC really controlled how VMware did storage the way people sometimes talk about it, Yeah, it would be delayed.

This release would be delayed until they were ready. Yeah, yeah. Well, I think the problem with VMC is it got, I don't know, five different storage modules? Six? I mean, Isilon, you got lots of storage systems. I was kind of hoping that Isilon would support vVols via NFS. Yeah. Because, as you can tell, it's going to be easier to support vVols over NFS.

It's not clear in my mind how it changes with NFS versus block. Well, you already have a file system. Yeah, yeah, yeah. No, I understand that. But is there a meta file now that's a container file that all these requests could come over and that maps to this protocol endpoint for NFS? For NFS, the protocol endpoint is much like the NFS protocol endpoint without vVols. It's a file system and each VMDK is a file. What the guys who have file systems have to make sure

they can do is now provide the services on a per file basis where they only used to provide them on a per volume basis right so NetApp can already store VMDKs and can already do that part but they have to be able to do a snapshot as

their big to support it. Or the other way to look at it is maybe there is no inherent advantage to people who have had file systems, right? Because even people who have had file systems have had data services on top of their logical volume manager, not on top of the file system, right? So, you know, something like a NetApp could do snapshots for FlexVolves, but not for individual files, and which is totally fine. But what I'm trying to point out is that, you know, in some sense...

Yeah, there's a heavy lift regardless of which side you're on. Exactly, right? So just being NFS, just having the file system is not in and out. It solves the one problem and it leaves you with the other. That's right, that's right. So in some sense, it's a nice level playing field. But then, like you just pointed out, is storage systems that are slightly more contemporary might have

an advantage in that some of those architectures tend to be... Metadata intensive, yeah. Yeah, yeah, exactly. All right, so I was going to ask the question. I'm not sure whether it's really a problem or not. How do you measure performance when you've got one container to learn which you're doing all the activity on? I mean, I would like to see latency.

I'd like to see overall throughput. I'd like to see at a device level, and in this case it'd be a micro LUN level. Is there some, you know, is there some phenomenon at a micro LUN level that's causing me problems that I want to see? But can I isolate that? And I don't know, is there a vCenter? Absolutely. In fact, that is one of the advantages, right? Now as a VM user, if you have a problem, if you have a storage problem, you can say, well,

my VM has a storage problem and the storage administrator is going to be able to see the exact same VM with its virtual volume objects in the storage system UI with the stats on a you know, on a per object basis. And so now they can, for the first time ever, understand what the application administrator is even talking about. Ah, at the vCenter level. Yeah. Well, of course, it's at the storage system implementation.

And so I'm sure there will be a couple of subpar implementations that just don't give you the analytics at the viva level and yeah and we should all treat those people badly when we see those uh subpar storage uh you know i thought oh no back Satcham's favorite subject. Okay, so here's the other question. Now, we've got some storage systems that – no, we've got some onboard, on ESX level storage SSDs for caching and things like that, not to mention any customers or vendors by name. How is that going to be affected by VVOL? So you see any impact to that? Caching at the host level, the server level? There is some impact in that, you know,

more work needs to be done. Just like how an acceleration render would support, you know, NFS as a data store, you know, accelerating VMs on NFS data storeselerating VMs on NFS data stores or accelerating VMs on SCSI data stores. They would have to now support accelerating VMs on

vVault based storage systems. I can tell you firsthand without naming any vendors. Go ahead. It is doable. The other question I had, where did it go? It was right there.

Is VVols and VASA and VAI, I mean, these are, you've created almost a whole new protocol here, container volumes, protocol endpoints. Is this something that other vendors such as, let's say, Microsoft or Citrix or somebody could adopt and expand upon? I mean, it would seem like Hyper-V would have the same issue, right? They would want to have their control structures at a VHD level, right? Right, right. And Citrix would want the same thing.

So, I mean, is it something that can span beyond just the vmware ecosystem i asked that question at the briefing oh and and the data the data channel has is t10 yeah yeah it's got so so anybody can write a hypervisor that consumes vVols. The VASA 2.0 control channel is not externally standardized. And I didn't get an answer to, well, if Microsoft decided to use these APIs that you've provided, what would the legal status of that be? It's not a question they answered for me. Yeah. You got a briefing?

On VVols? Yeah. I guess I need to sign up for the right briefings. Okay. You just got to ask, right? It's probably my problem. Yeah, yeah, no doubt, no doubt. All right, so vVols is going to change the world,

a storage world as we see it in VMware land from this point on. And when does vVols come out, do you know? I mean, it's obviously been in beta for, gosh, eight months, nine months. It's part of vSphere 6, which they officially announced on Groundhog Day, and I want to thank them for that, because Groundhog Day is my favorite holiday. Okay. And they're saying that GA is this quarter. So I'm saying that it's going to be April 2nd

because nobody ever releases anything on April 1st. It would be foolish. And then the storage... This quarter being the first quarter of 2015? Yeah. Okay, go ahead. And then the storage vendors have to release their support for it. And there's like 12 vendors including

netapp and three par and dell equal logic um who were the development partners yeah um but also hds and nimble you know a bunch of guys um said they're going to have support in the first half of 2015. And there's like 27 total vendors have said we're going to support it at all. But we haven't announced delivery dates. So what happens in the current environment where customers are using, you know, standard LUNs or standard NFS and vSphere's fix comes out and they happen to purchase the storage system or somebody updates their microcode

God forbid, to support vVols as well as their standard stuff. So what happens to these guys? How do they migrate from their current environment to a vVols environment? Storage vMotion. Huh? To a vV yeah yeah oh my god so the container object

is a new class of data store so if if i had an array and i got the firmware upgrade so now it supports v vols then i'm going to create a container and get my VMs over from one of my existing data stores until it's empty, and I'm going to delete that, and I'll cycle the free space around until I get it done. Yeah, but I mean, even though it might be on the same physical storage, there's potentially some real data movement that has to occur. Yeah, yes. There's potentially some real data movement that has to occur. Yeah. Yes. Yeah, because the storage today – because today it's on that storage laid out in VMFS. Yeah, yeah, or VMDK, yes, on top of VMFS.

Right. So there's the LUN, and then the LUN is – but the LUN is all the storage system knows. And then there's VMFS on top. Transition it to the new, and I call it file system even though vendors will object, but into the new file system that's managed by the storage array, even if it's the same array, the metadata has to be updated. It's just way too complicated. And all that replication, snapshotting, deduplication, thin provisioning,

all that stuff is merely a storage profile aspect and can be enabled and disabled without using vCenter plugins now. And provisioning can be all done without vCenter plugins. And it's all through the VASA 2.0 magic kind of stuff. I'm sure there still will be vCenter plugins for the, you know, four things that VASA 2.0 didn't standardize. But basically, yeah. Well, you still need a VASA plugin, a VASA vendor provider.

Yeah, yeah, yeah. But, yeah. Protocol endpoints. Interesting. A whole new world here. Literally. It is. It is.

And I think it's a way better world. And I think that Red Hat and Citrix and Microsoft have to look seriously at how they provide similar functionality. And certainly from Microsoft, a slight twist on the Vasa 2.0 and not use the same protocols, but they get to reuse a lot of their code. But it would be interesting. to 2.0 and not use the same protocols, but they get to reuse a lot of their code. Yeah, yeah, yeah. But it would be interesting. I mean, you'd think the cloud guys would also really want to have something like this. I guess if it's in, you know, if it's in Microsoft or if it's in Linux or something, or Citrix, I think they'd give it covered, I guess.

Just the scale guys, you know, scale computing and stuff like that. I mean, they've spent a lot of time and effort making this all kind of seamless. It would seem like they would want something similar over time. Yeah, well, they actually have something similar because they're running the file system. Yeah, internally. All right, let's not go there. You know, we've gotten to be at about 40 minutes.

Is there any other – I think I'm done with my questioning. I'm still kind of stunned here trying to figure out what this protocol endpoint all means and stuff. It's a big step. It is a big step for me and for the world. But just at the level that you and I conceptualize how storage talks to servers. Yeah, it's a big step. There's a big step. There's a whole new abstraction layer that goes in there

that looks really interesting because it's thin. Yeah, yeah. Sure. This is going to be exciting. In fact, one of the thoughts I have is, well, I'm obviously incredibly proud of being part of the team that created this in the first place. But this is a great set of SCSI commands, one or two NFS commands to do interesting things to virtual machines. And so this is a great example of how engineering needs to happen.

When you're trying to aim to do something really complex. You start off with something simple and get people moving. It was very hard for an ISV to ever influence what a storage system does, leave alone creating new commands, implementing new commands for you. That's also an indication of where VMware is in the industry. Oh, yeah. Yeah. Only an 800-pound gorilla could get the storage industry to go, okay, Mr. Gorilla, we'll do that for you. Please don't rip our heads off.

We're going to change our whole protocol, our whole way of doing stuff. Yeah, yeah, okay. But if you're not in a position to threaten to rip their heads off, then getting this kind of change done would be really difficult. And that is true. Although, you know, I was at VMware when we proposed this, and I can promise you that we asked very nicely. Yes, and I'm sure several people laughed in your face because you were only a 200-pound gorilla. Yeah, early on. Yep. But guess what? You grew up. laughed in your face because you were only a 200-pound gorilla. But guess what? You grew up. Yeah, that's true.

All right, I think I've got my last question answered. Howard, do you have any other questions to ask Satcham? Well, you know, I don't. My main question all along has been what took you so long, which isn't really a Satyam question because he's been gone from VMware for long enough that that wasn't his call. But I must say that I have at least twice in blog posts referred to VVols as Godot because I was unsure they would ever arrive. Oh my god. I now get to say Godot and Fon RRV Godot has

finally arrived. Satam, you have any final comments you'd like to make before we turn it off here? No, I think I'm good. Alright, well this has'm good. All right. Well, this has been great. Thank you, Sadam and Howard, for being on our call.

Next month, we will talk to another startup technology, storage technology person. Any questions you have, please let us know. That's it for now. Bye, Howard. Bye, Ray. Bye, Sachem. Until next time, thanks again, Sachem.

And thank you guys for having me. All right. See you.