Best Practices for Adopting & Deploying VMware Cloud Foundation 9.0

Welcome, everybody. My name is Jared Burns. 0.

0 depending on where you're coming from. All right, to go over a couple of things. So most people are aware of how VMware Cloud Foundation was in the older versions, which is you had what was called a VMware Cloud Foundation instance, and that instance was SDC manager, your Storage vs.

Center, NSX. And you ran on the, the, as an instance, and each instance was separated. It was all by itself, and you could have multiple instances and they could all be independent of each other.

What we've done on VCF nine is we've introduced a new concept called the VCF Cloud Foundation Fleet. A fleet now consists of one instance, but it also consists of operations and automation as a whole. And what I mean by that is you get one single operations, one single automation that runs across a fleet, and then you can have multiple VCF instance talking to that fleet.

And then we also came back, introduced the VMware Cloud Foundation and Private cloud. But what that means is that is just pretty much a group of VCF Cloud Foundation fleets, and that's really the only big difference. Now with the way that, um, private cloud works for us.

Couple considerations that we always take into account when we do a VMware Cloud Foundation deployment. We always wanna look at centralized management. What we mean by that is, is where is my operations gonna live?

Where is it gonna be placed and where is it gonna be best for performance across my fleet? Second one is my initial deployment. I'll always follow what we call a VMware Cloud Foundation Fleet Deployment basic.

Um, and I'll talk more about that as we go along, but it's pretty much the first design you start off with. It is what you deploy out of the box. So it will be SDC manager operation in vCenter with SDC manager over the top.

And this does support multiple, um, foundation agencies, depending on how you wanna deploy. And then flexibility, we're allowing for multiple clusters, single domain, um, inside of a VCF fleet. Now we've cut down the need to, you know, have so many restrictions around how you deploy the VCF instance.

We're supporting more storage, we're supporting more options when it comes to the architecture of A VCF. Here are the four designs that we're gonna talk about today. Um, the first one is VMware Cloud, uh, is VMware Cloud Foundation, fleet Deployment Basic Design.

This is the one that we just talked about early on. Then there's one that's called the site high availability, which is across multiple availability zones. The third is disaster recovery across regions.

And the fourth one is a in, it's a mix between the site high availability and disaster recovery, where you get both the best worlds. Hey, Jared, quick question. I don't wanna get too deep in the weeds, but you have to choose one of these four deployment types, you know, in design prior to deployment and, and stick with it until you redeploy.

Or is there opportunity to go from one design to another as you mature as an organization? And maybe you wanted basic to start out, but you need one of the more complex designs, uh, with more capabilities later on. Yes, that's correct.

Yeah, so basic you start out with, right. So basic is where we get everything. The rest of these you can go about.

So majority of our customers, you know, most customers out of the gate aren't going to be able to, um, know exactly that they want, say high availability day one, or they want disaster recovery. So what we do is we base it off the first basic design, and then you can just grow into the rest of the designs. The only difference is, is that you'll have a second availability zone, or you'll go into DR and you'll just need to come up with a way of how you wanna do dr.

Now as in, you know, prior releases, we've really recommended SRM or VLR, we still do recommend VLR, um, but we also allow for more different solutions when it comes to dr. Um, you know, your other software that's out there that can do the same kind of replication between two sites. Gotcha.

Thank you. That's a great question. Thank you for bringing that up.

All right, so let's go into the first design. So this is the first basic deployment design. And as you can see here, you have VMware Cloud Foundation Automation, VMware Cloud Manage operations, your STC manager, storage, vCenter, NSX.

0 we are allowing for, um, a difference. So we allow for vsan still, but we also support fiber channel NFS out of the box. So when you go to a green refill deployment, you don't have to just do VS a for a management domain.

You can now do fiber channel or NFS for your management domain. The key to this basic design is that this is where you start, it's your foundation for everything, but it doesn't establish high availability of fault tolerance between, um, racks or between sites. Now, what you won't see here is we don't talk about rack design, we don't talk about your network design.

We're, we're kind of hoping the customer has an idea of what they're, they do today and we don't wanna change it. So we're just saying, okay, customer, you know, if you wanna set, go across multiple racks where your hardware, if you have redundant UPSs, redundant networking, as long as you're good there, we're good to put our software on top of that. Good quick que quick question here.

Uh, do you still, uh, support consolidated, um, uh, like consolidated the management domain and workload domain together? Yes, we do. Um, mm-hmm.

Okay. We just don't use the term consolidated and standard anymore. Mm-hmm.

Because everything is, everything is pretty much a consolidated out of the box. You, you choose if you wanna build workload domains, so you could have multiple VCF instances where you just have a management domain with multiple clusters across a fleet. We don't me, we don't recommend, we don't have to recommend a workload domain.

We can, you can choose that workload band depends on your needs. But yes, we do still support, um, the old consolidated model. We just don't call it consolidating anymore.

We just call it domain. Alright, thank you. Thank you very much.

No Problem. And, and you mentioned you don't dictate to customers like what their design is gonna be for high availability or anything, those like that, but there were capabilities in the product in particular with vsan if they choose to use it, like stretch clusters and fault domains. Are all those features still available?

Well, there customer designs that Okay. Yeah, they're still available. Um, the difference is, is we are now allowing for metro clustering.

So let's say you are a customer that has Metro clustering set up between your two, your two availability zones. Our manager domain now supports that solution. Now will SDC manager, it's still not in the workflow for SDC manager.

So it would be still where the customer would build, you know, four hosts in one site, four hosts to another, connect it to the storage and then create all the, the workflow to do that. But yeah, we do support vsan stretch cluster still, it's just we're not forcing a customer to have vsan in their management domain. We're trying to give a lot more options around that.

The second one is high availability, as you can see here. Um, the key to this one is having portability between your IPS addresses, between the availability zones. You can deal with NSX or you can do it with your underlying nor um, networking structure.

Um, there's no requirement to have NSX two stretching between the two avail zones. If you have layer two stretching with your, you know, underlay, then that's supported. Um, we also allow for, the difference is now that the VMware cloud automation operations are not deployed by default anymore on AVMs, we, um, have gotten rid of that terminology.

It's now, it's up to the customer to deploy. If they wanna deploy on V AAG networks or NSX segments, it's up to them during deploy. Okay.

And then the next one is disaster recovery between zones, which you'll see here is you'll see operations being replicated over automation is a little different. Um, it's using, um, we call VMSP, but it's a Kubernetes backend. So we are still working through like how that recovery would happen for automation, but it doesn't do the same replication as it does today.

So it's a little different when it comes to that. Then the last one is pretty much, you know, stretch clustering and replication. And what you'll see here is that you have two availability zones of region one and region two, um, and you're, you're actually replicating operations to region two.

Now, one of the new features that I did not have a picture of, and I should have had a picture of was when you deploy this, you can have one region, one region two, and you can have a fleet sitting in region one that's will maintain and be able to, um, support a VCF instance of region two. So you don't req, there is no requirement to have, you know, operations of both regions. You can have operations in one region that will support multiple instances across the globe.

The only key difference there is that you always wanna keep in mind that it's 500 milliseconds round trip time between the ops collector and the operations cluster and a hundred milliseconds between workload domain and the v the vCenter or, um, host that it's supporting. So you always wanna keep in mind that based on your VCF instance, you don't wanna go more than a hundred milliseconds between your host and your vCenter and you don't wanna ever go over 500 milliseconds between your operations and your operations collector. Jared, just, just to be clear, that's, that's like an operational requirement, like the delay can be no more between those components for the hun a hundred millisecond 500 millisecond Requirement?

That's correct, yes. It's round, round trip now. A hundred millisecond has been tested internally to us.

That's the highest we could get with a workload domain. 500 milliseconds has been out there for a while operation, so that shouldn't be a change to most customers. But it is a change because what you have to take into account now is that ops collector does more, it used to just do, you know, metrics and, um, object collection and send to the operations.

Now it has the ability to do lock forwarding, so where you can actually grab the logs from that local site and send it through the log collector or the operations collector back to operations and logs to get the information. It also supports, um, data be held locally for a temporary amount of time for the operations collector. So if the operations note is down, it will keep those metrics local to that collector for a certain amount of time.

Uh, and Jared, I have another question, uh, kind of about the architecture. Uh, and I think you covered this and I'm just con not familiar with the new terminology. Like I see when I see multiple management domains and VCF that used to be, um, federation back when you had multiple SDDC major instances, but now VCF operations is the single point of management for multiple VCF deployments with multiple management domains managed in a single console.

So that's kinda like the new federation, is that correct? Yeah, that's correct. Yeah.

So operations is now the new, the new federation. So the way operations works now is that we deploy out a appliance called VVCF Operations Fleet Manager is a replacement for the Aria Lifecycle Manager. You've seen in the past with the ARIA products and what it is, it connects directly into operations and it does its fleet lifecycle management, password rotation, certificates all in one place.

So that operations itself is able to ly single manage every VCF instance that's connected to that operations instance. Um, so single pane of glass multiple places, you know, one place to go in now it's not like where you can click on one button and upgrade everything in one VCF instance or inside of a, a full fleet. But what it does do is give you a single pane of glass where you can click on different VCF instances and do upgrades and pass rotation certificate management at any given time.

But it is the, it is like the old federation of SDC manager I see different just moving into operations and there's some futuristic stuff coming down road roadmap wise where we're gonna do more with operations and that type of stuff. So stay tuned for that. Gotcha.

All right. So we're gonna go through some greenfield deci decision factors. Um, one of the first one is what we call local fault, fault domain or fault protection, protection costs.

Well, availability zones or protection disaster. This is one of the key things that we want customers to think about when they go about doing the planning of their fleet. They want to, we wanna be able to say, okay, do you only need, you know, vSphere high availability to protect your workloads or do you really want to have protection across multiple availability zones?

Or are you not really wanting to have two sites for high availability, but you do want disaster recovery? So these are kind of the things you wanna think of out of the box, but you don't, it's not like you have to do this right away. Like I said before, you can use the basic deployment, deploy the VCF fleet with the incense and then it can, and then you can just add on over a period of time.

It's not something you have to think right away. There's only a couple gotchas that you would want to keep in mind is you wanna make sure if you are gonna do high availability, you do stretch your network and your storage. If you do dr, you wanna make sure you know your IP portability story upfront so that you know when you lay out those tools, operations automation logs, you know how you would be able to move those if required.

And then a couple of things around operations placement scale, what we're, what we're bringing up here is that you wanna make sure you have enough scale for, you know, compute memory storage resources for the operation appliances. Um, in the, there's 2D deployment models you can look at. The first one's called sim and what that is is that deploys one operations primary node, one fleet manager and one collector.

When you do high availability, you're deploying the normal, which is, you know, primary replica data and then you have the option to deploy in, um, multiple collectors, but you can do it after the fact, but you do do a fleet and collector. And then the last option and when you can't deploy it right out of the box, but it's something to think about would be operations, continuous availability. But that one has some um, re like restriction around you gotta be within 10 milliseconds of each of the nos talking to each other.

So you have to always keep that in mind when you do the design. And how easy is it to scale out or back in from those various deployment types. Um, for ca it's a flip.

You have to flip it from CA to HA and then you would delete the NOS you didn't need anymore. And ha from simple is pretty simple. Um, you just use the new VCF operations fleet manager to do that scale out.

So you would just go into the fleet manager say, I wanna deploy replica in the data node. Um, and then you would scale it out. Now it will ask you where you wanna place those.

It usually places them in the original management domain they created. Um, I'm still testing if its ability to do it across multiple, um, data centers. But then you're talking about CA and you got start talking about latency.

So it's best just to keep all the HA nodes together. Um, so yeah, there, there it is. Pre it's, it's about the same as it was with Aria, a lifecycle manager, suite lifecycle manager, um, just a little different when it comes to the interface you use, you don't log into a separate interface anymore.

You log into operations, you go into Fleet and then you do the scale off In the organization separation. Where this one becomes key is, um, if you have customers that are running PCI environments or something where you can't have it, see operation, see all the environments it's running, I have a couple customers that they have separated environments where they cannot deploy operations as a whole. So then you would wanna look at, okay, can I deploy it with, how do I wanna deploy my fleet for these type of solutions?

Do I want operations to run certain types or do I want to type, type of workflows or do I want to be able to be across the board? So you wanna look at your organizational separation because we don't have the, the tendency in operations, we do an automation, but we don't have that as of yet in operations. And it could come down in the future, but we just don't know when that would be.

Uh, and can I have a question here? This organizational separation thing, it's uh, some kind of, uh, transferring the vCloud director of functionality to VCF or this is completely new approach and it's not gonna be connected to that, uh, let's say name as this product or many customers. So That, that is something that's coming in our, with the automat VCF automation future releases.

I don't have a lot of details on how that's gonna look, but that is something we are looking at with VCD into the automation platform and how they do tenancy within VCD. Yeah, so that is something that mm-hmm here we're just talking about like if you want to deploy multiple fleets with different operations and automations to manage those fleets, but that, So it's basically completely dedicated infrastructure Yes. For some organizational part or customers of, of uh, of the IT department.

Yeah, definitely. But the infrastructure needs to be different though. They are not share the same infrastructure.

You're not sharing your operations, your automations instance across multiple VCF instances or clusters. That's Correct. Alright, thanks.

Alright. In the mi we talked a little bit about earlier, but another big design decision that you would wanna think about upfront when you do a greenfield deployment is, where do I wanna place my operations and automation notes out of the box? Um, there are two ways.

We, there's one we call the preferred way, which is you would deploy it with the VCF installer, which is the new terminology for the cloud builder. So it's a replacement of the cloud builder in the older VCF deployments. And what it does is it allows you to put all the components on one network, which would either be ESXI or VM Management Network.

And based on that, then you'd make the choices to say, okay, now that's where it's gonna live. It, it goes to the installer. The installer does the full bullet buildout in one step.

Now there are options, and this is something maybe you would consider around DR or high avail, high availability when you decide availability is deploying as a second day operations. And what that means is that you would skip operations and automations day zero and you would run a different API call into the solution to deploy on a separate VLAN or an NSX segment for operations automation. Um, and why we that's offering is there is that there's some recommendations around if you use NSX segment, if you want to do federation for dr, you'd want to be able to put that on segment.

And there are, you know, concerns around if you wanted to stretch a VAN between two sites, it might not be best to stretch the VM management network between those two sites because that has the vCenter NSX living on it. So that is kind of something to think about and it's something I would consider day one because you're not gonna be able to switch those networks or ips after the deployment. So it's something up front I would be, I would consider out of the box.

All right, so couple more design decisions. I know there's a lot of design decisions, I do apologize, but I want to give you guys as much information front. So we still have the 25 vCenter per VMware Cloud Foundation instance limitation.

Um, as part of that limitation, just keep in mind that once you hit the, the 25, you just build another VCF instance. The second one is, and this is a big change from the five x days, is we went from 1200 hosts per VCF instance to 2,500 host per VCF instance. So about 1300 and we still support a maximum of 25 in section managers per VCF Cloud Foundation instance.

And, uh, what is the minimum, for example, host amount for set up the VCF cluster For management, the VVC F Foundation, it's three or four. So three is for simple, four for, for high availability. So we, you can deploy in three to do a simple deployment, which would be one node.

When I say simple and I, I don't talk about it in the slide deck, but what a simple deployment means is I deploy one operations primary node, one automation one in sx, one vCenter, and SDC. That's a simple deployment, right? And I do have a collector, but those will be simple.

One appliance for everything, for each component. When I go to HA is when I would have, you know, three of NSXs, three operations in the analytic cluster and three automation, um, notes based on that. You need four, but you can start with three hosts if you wanna come, um, out of the box.

Is it still a requirement that if you want a stretched workload domain, you also need a stretch management domain? It's not required if you're using, if you're not using vsan, if you're using vsan, SDC manager does still require it, but if you were using non vsan like a metro cluster, you could stretch workload without stretching management. And, and is there any maximum number of VCF instances that clouded Foundation Fleet can manage?

Not at the moment. It's based on the operations objects and metrics limits. And I think if We hit those limits, that could be A potential model.

Yeah, we hit that. 6 million for a large or extra large operations node to hit that number for, I think metrics and objects, I'd have to get the numbers for you, but if you hit those is when you would need to deploy another fleet. Six.

And it, you guys know what, like what an object is and what a, um, metric dig. So like, as long as you're not hitting those numbers, yeah, you won't need multiple fleets. But again, you, you would wanna look at, you know, what is, where do I place my fleet and is it best for me to have a fleet in, you know, New York City supporting, you know, something maybe in, you know, London or you know, Singapore or to Tokyo.

You'd have to think about what's, what's best for you. Um, and running a fleet two fleets set by, you know, next to each other is not that big. It just means more hardware for management, but outside that it's, it's not as bad as it used to be.

Um, but it is still, uh, operations undertaking to do. And then one of the other requirements is ACL check. 0.

Um, when it comes to IP requirements, so this is what we're talking about, simple and the high available. So you need at least four nodes, um, ips, I, I, I think I messed that slide up. It should be 3, 9 4, sorry about that.

And four, four high available. And then you'll see the ips across the board of what's required. We need to deploy it.

Um, VMware identity broker I haven't talked about yet, but that is used for the replacement of VMware Identity Manager. Um, it's the new V-C-F-S-S-O and then it shows the rest of the ips. Any questions so far?

Okay. And then we'll go to the DNS Ries, same thing. DNS entries.

It would be three for simple, four for high availability. I, I, I for some reason did a copy and paste there on that one. But these are all the DNS Ries and what you'll notice here is OP automation shares 1D NS entry pretty much.

So you would have two entries altogether, but it, it, it shares DNS entry and the IPS on automation. I'll slip back to this real quick. It says two and the reason why there's two there is one is always for upgrades.

So like for simple, you would get two because the first no would be used the ip and the second node would be the second IP would be free. And when you do the upgrade, it would build the second node with the new I, the second IP and then release the first ip. And it, same thing for, um, ha you need four IP addresses, but only three are in use and it's an embedded low balancer, so they blow balancers that external.

Um, and then four operations, the same thing. 0. We give you the option, but we, but you're not required to put anything in there.

Alright, and here's all the steps that go along with Greenfield deployment. You prepare, prepare your, you download your or cloud foundation installer. Now the, the big difference there is that cloud builder used to have all the bits.

So when you download a cloud builder, it was about a 30 gig file, um, ISO or OVA that had all the bids. So it had NSX vCenter, um, all built into it with the new vvc, the VMware Cloud Foundation installer, you just deploy the installer and then you reach out to either a online depot or offline depot to download the binaries for the installer itself. So we no longer store 'em inside of the OVA for the installer.

And then you complete the UI wizard either by going through the steps or uploading A-J-S-O-N, it does a validation of deployment specs, then it'll do a deployment, it'll deploy automation operations, SDC vCenter and then SX out of the box. And then, um, you will go in and configure your licensing. Um, there's new licensing as you guys probably are aware, where we are no longer using keys for our licensing.

And we go to a keyless solution, which is a file that you download from our webpage, and then you import that into operations and operations then has the licenses required. And then you deploy, you know, the cloud foundation identity broker. The, the broker is the V-C-F-S-S-O.

So we went to a one single place to do all of our authentication and that does integrate with third party like, um, ping and um, Microsoft Auth authentication. And then you deploy operations logs and networks. So, uh, all this nine steps can be done in dark site, uh, setup.

So without internal active internal connection, right? That's correct, yes. So what you would do there is on the third step, you'd either import those binaries into the VCF installer or just set up an offline depot if you can, that has internet access and then transfer 'em in.

If not, then yes, you can still do the bring in the bits offline for a dark site. And where Does that Cloud foundation installer deploy to or run from? Is it one of those ZSXI hosts you prepared?

Is it somebody's laptop? Do you have options? What?

You have options. So you have options. So the, the key to the, the, the installer is that if you can deploy it on the host, you're getting ready to bring up to BVCF.

Now if you do do that, what it does, it turns that installer into the SDC manager where if you deploy on a separate E ES six, I host it then will leave the installer alone and build a brand new SDDC instance or appliance. And why that's critical is you're probably asking is that if it turns in the SDC manager, then you can't reuse it. So let's say you wanted to deploy more VCF instances, you can't reuse that appliance to deploy more instances because it turns off that functionality where if you deploy it on a separate host that's not a part of VCF today, it allows for that functionality to stay because that installer is pretty much the SDC manager is what it is.

It's the appliance for SDC manager just with the functionality of the installer. Yep. 0.

What we're gonna do is we're gonna go through some customer environment. So what we call this is a self-managed V center. What we mean by that is, is that the V center itself is actually living in one of the clusters within that V center.

There is no separate management V center over the top. And so what you'll see is, is as we progress through this, if you're using a self-management vCenter and you're moving to VMware Cloud Foundation nine, you're doing an upgrade, it would then install that vCenter. That is a management vCenter in, it turns in one of those vCenters into a management vCenter by installing operations automation.

If it's not there, if it's there, you would just upgraded place. But what we're trying to show here is that we're not, we can do this either with self-managed V centers or Management V centers themselves. So here you'll see self-managed V center with ELM.

0 when you do a upgraded place, you cannot have enhanced leak mode in t. We do request you to break that connection. Um, and you would break it on the BS center is going to management first, and then you would break any workload domain V center you wanna bring in separately.

Now, there are two ways to do it. 0, which is you run the utility and it breaks out the FIR only V center by itself and then you just recreate all the permissions. The second one way is you would upgrade all your vCenters to nine that you're planning on putting a nine and then you would break 'em after the fact.

0. So you don't lose any of the permissions that are on the vCenter. So that's something that consider also as part of when you design decisions as part of the vCenter ELM.

So then the next one is that, um, we're gonna talk about here is is again, ELM. This just kinda shows what happens to the management domain. Okay?

And then this would be the manage vCenter with multiple vCenters. So this is a vCenter that manages multiple vCenters and all we wanna do is here is just kind of show what happens. So your vCenter stayed there, but it's now a management domain.

All right, so then this shows up as your vSphere deployment with VMware Cloud Foundation. Um, what you're seeing here is these are all the steps for just a vSphere customer. This does not account for operations.

Um, so what I mean by that is, is that this would deploy a brand new operations automation solution. So this would be a customer that just has vSphere and nothing else. Um, so this will show you, okay, what does a customer have to do to get to VCF nine with just vSphere generic by itself.

This is with vsan or external storage, whichever way you want to go. But as you can see, there's, there's one through nine steps. It's kinda like the greenfield.

The only difference here is there's some more prerequisite follow. Um, one of those is lifecycle. 0.

So you would migrate your workload domains to VLCM and then you would up, you would do the rest of the status. You create vCenter, you upgrade ESXI or ESX, and then you deploy the cloud built installer wherever you can just deploy on that clusters you're importing or upgrading or you can deploy it on a separate cluster. If, again, if you deploy on the cluster you're bringing into VCF, it will turn that into the SDC manager automatically.

If not, then you would get a new SDCA manager appliance And then you configure the depot and binaries again for the installer. And then you would do the actual upgrade to VMware Cloud Foundation and you deploy op operations automation as part of that. And then you configure your licensing and then you would have the option to import any workload domain B centers.

Any question on this one? Okay, are customers supposed to be able to do this by themselves or Yes, customers should be able to do this by themselves. Um, we have some, um, upgrade guides that walk a customer through all the steps and all the pre-reqs require to do this work.

Um, it does take a lot of steps. I'm, I'm not gonna lie, it's, it is a lot of steps. Um, but the key is it's not as hard as it used to be where you, when you did the actual conversion to vCenter or VCF where you used a script inside of SDC manager to do the actual conversion, it all does it through the installer now.

So what you do in the installer is you select what your existing components are. So if you had vCenter and operations, you click those two boxes, it then pulls in the names of those two boxes based on you entering 'em and then it does the conversion so you don't run a script any longer. So it, we have made it easier to do it, but it is still a lot of steps to follow.

Yeah, all All experience from upgrading from five to 5 0 1 or to 5 0 2 says that a lot of issues will normally show up that you need some help for. So Yeah, and so we'll talk through the vSphere VCF to VCF upgrades. But yeah, the um, yeah, we've tried to shore up a lot of those issues we've faced in the past, um, around how to do upgrades and how to get a customer there and be successful.

And one of the keys is the design planning and then the perform all pre-reqs. Those two steps were very key for successful of being doing an upgrade. Um, and the reason for that is because, you know, we talk about ELM in there and how ELM will affect you, how VM affects you, uh, how like vCenter ha so vCenter high availability would affect you.

So if you're using the appliance based vCenter high availability, how that affects you, how you can turn that off and then turn it back on. We talk about NSX Federation if you did run NSX Federation during the upgrade for some reason in your environment, we talk about all those kind of things. So the real key to these upgrades is getting into the design planning and seeing the differences and then what the prereqs you you need to perform to get to where you need to be.

Um, can you onboard as well through this procedure infrastructure that you have at some hyper scholar, uh, based on your license that you can bring VCF license, license to the, I know Google or, or I assume Azure, I think, uh, Azure VMware platform. We have, I think it's called like that, Sorry, VMware Azure. Yeah, they call it the, it's the service engines now.

I can't think of all of 'em off the top of my head, but yeah, there are mm-hmm. Engines around it. I have not got into how you would do those, how you would upgrade those into VC and we haven't, I haven't done a lot of detail on how to get nine on those engines at this point.

Okay, thanks. Alright. Did that, and here's some of this is where I show you the changes between, you know, what you're going from.

So you're going from individual product license key based in Thomas to keyless subscriptions. You know, your V three HA stays the same. If you're running V center high availability, you disable VCHA, you perform the upgrade to reconfigure it, you know, your V three cluster stay.

The same enhanced link mode we're replacing with VMware Cloud Foundation operations and VMware Identity Broker. Um, we do support, you know, standard switches and VDS switches. The only caveat to that is, is that every host has to have at least one connection to one VDS.

So the VDS has to be connected to one. Um, we do import workload domains with NSX existing today. 1 or higher NSX and then you can import as is.

There is no requirement to upgrade 'em outside of VCF. You can have eight in N SX four, bring 'em into VCF and then use the VCF fleet components to do the upgrades. And then we go through vsan and vendor non VMware.

So we still support that. Um, if you deploy, if you don't have operations deployed, we'll deploy it. If you have don't have automation deployed, we'll deploy it.

Um, we now support Kubernetes containers through automation itself. We do not support VxRail today on upgrades and we do not support high heterogeneous clusters on support today. And we do enable FIPs by default on the vCenter itself.

Okay. It's your FIPs your certification, is that now at one 40 dash three or is that referring to something else? I think it is, but I would have to get back to you on that.

I'm not really sure of that one. Okay. That's just the, the latest, the latest iteration, you know, beyond one 40 dash two?

Yeah, I think it is 1 43. I think I saw a paper on it, but don't quote me on that. I'm not really sure if they've, what they've done on that.

Actually, I just know that when you replace the vCenter now from eight to nine, it deploys the brand new of vCenter. It does automatically turn FIPs on through the API and then it's automatically set up. Okay.

Um, then we're gonna go through some the design considerations in whole. So you can see all the design considerations here we just talked about. And then we talk about ip.

So in a vSphere environment where you only just have vSphere, if this is everything you're gonna get deployed on top of it. So you're gonna vest S-D-C-N-S-X, VMware Cloud Foundation operations, the fleet manager collectors automation, and then how many ips based on which model you slu. Um, you choose on that selection of what would be required.

0 update one or greater to perform an upgrade to nine. Um, that's also for import or management upgrade. The license has changed.

0 scale. You wanna make sure your existing environment can support. 0 resources.

We do increase our CPM memory on at least automation side of the house, but we in some of the other stuff is increased a little bit. But you'd wanna take into account NSX and some of these other new appliances getting deployed vsan. Um, we do support vsan stretch during the upgrade process.

So you would upgrade the witness or replace the witness, then you would do the upgrade, um, and then actually perform the VCF convert to um, VCF nine. 0 or later you do need a temporary IP address for vCenter. And then you would also want IP addresses for the DNS records.

For additional components. Um, um, all clusters that need to be upgraded are part of the new Management V center need to be on vSphere Lifecycle Manager. So if you're on vm, we ask you to convert that to VLCM.

And then if you do have VLM, we do ask you to remove that VLM from that V center we're getting ready to convert to management. Do you still support vsan N also? Yes.

Yes. Okay, thank you. Yes, we support vsan NOSA and vsan ESA.

0. And then we kind of repeat some of this stuff about like what you're gonna do. You wanna make sure you can configure the mapping offline depot, that type of stuff.

Um, you wanna make sure the VM is, you know, the installer, you wanna make sure you put it somewhere where either you wanna, if you wanna reuse it, you put it outside the management cluster. If you want to just turn to SDC manager, just put it inside the cluster, you're getting ready to to move to VCF. And then this is kind of pops you through all the steps.

And this is for the import of workload domains. We don't support management right now with NSX attached to it, but we do support workload domains, vCenters that are gonna have, uh, that do have an NSX. 0 that has no NSX and and you wanna bring it in.

If you put it on nine before bringing it in, it actually gives you the ability to only deploy one NSX manager if you require it instead of three. But if you're on eight, it'll ask you to do the standard three appliances. And we do not support NSX Federation as part of vSphere.

Now VCF, we do support NSX Federation to be in place, but we don't sp um, support NSX Federation. If you are a non vSphere CUS V CF customer today and you're just taking a vSphere and importing it into VCF and then here's all the imports orders that are N-F-S-V-D-S cross cluster imports, icas, the VOH HCM mesh import two host VSAN cluster import vsan stress clusters import one no cluster or standalone cluster. Um, what we did there is all standalone standalone hosts are importable now within a vCenter.

So if you do import a vCenter that has a standalone host, all we would ask you to do is connect it into a cluster. So moving into a single cluster and kind of to A VDS and then we can import it and then we can support single p nick host. And then we talk about configuring the offline.

0. You would, um, configure SDC managers Depot and then you configure the VCF operations Fleet Manager Depot, both can be offline, both can be online and both can be manually where you upload the packages, the pack, um, bundles separately independent, but there are two different managers. You can use the same offline depot for both if you choose to.

And then the next steps are configuring automation after deployment. 0 and you get the same experience you have today. And then the other option is to deploy identity broker for single U-C-F-S-S-L.

So this just GA back in June? Correct. June 17th I think was the date.

And so what are you hearing from the community? Like you've, obviously you've gone through and you've tested all sorts of migration options. Um, what are, what are the gotchas, what are some lessons learned from field, um, installations and upgrades that that supplement what you've, uh, talked through here so far?

So we have been talking with all of our customers and we're not getting customers just doing upgrades. They're doing either greenfield or they're doing up, they're doing greenfield and upgrades. They're, we're doing all greenfield or I haven't ran to many customers say I'm gonna upgrade everything.

Um, some of the gotchas that we've, we've kind of gotten in is that a lot of our customers have thought, well I have to have VCA for management, so I gotta go buy buy brand new hardware. And so that's been a big challenge because when you go in have that conversation with the customer base, they're like, okay, I need V SAN for management. Uh, and we're like, well no, you don't anymore.

And that seems to have opened the doors a little bit more to VCF in the sense that customers now have that opportunity just to go with whatever hardware they have as long as it's on the HCL in whatever storage outside of, they still need to do fiber channel NFS for management, but then it's a little bit more open for the workload domain side of the house. So really that's the big gotchas. Um, the other gotchas are ELMA lot of conversations about ELM and what we can do and how we, you know, make sure the services are the same and there's no changes.

Um, but those are really the big ones we've learned so far off of. 0 are looking at, they're gonna do a greenfield and then they're gonna do some upgrades or imports of workload domains at a later date. Um, I I have one follow up question.

When it comes to like, this is probably more relevant for Greenfield but could be for upgrades as well, is how are people sizing whatever hardware the management domain is gonna run on to, to make way for all the appliances? Is there good guidance out there for after they decided what kind of design they're gonna use, you need this much CPU, this much RAM and this much, much storage for those appliances to, to ensure that they're future-proofed? I guess you could say?

Yeah, we're working on a sizing calculator guide to be a little bit more, um, clear on what you're required. Um, used to, you know, to get out of the gate you would want at least 32 CPUs in a box because the automation appliances now do 24 versus CPUs and they won't power on if you don't have more than 24. So we're seeing a lot of customers having to look at their CPU accounts and say, okay, do, can I run the new automation appliances at, you know, 24 virtual CPUs?

Um, so that's a big one. Storage wise, we're about the same around the storage per se. The RL lifecycle suite lifecycle manager is the same size as the fleet operations, um, manager.

So they're the same size, so it's just a replacement. Now the key that you have to keep in mind there is, is that we're not deleting the old. So like if you're running a lifecycle manager from Aria still, it'll stay around until you're ready to delete it and you might not be ready for a while to delete it because it still might have logins logs in it, it still might have the IDM in it.

It can still have automation IT that you choose not to go to nine with. So you have to keep that in mind and count for another appliance for that. And then you just need to account for the S-S-O-V-C-F SSOs.

But auto operation sizes, we stayed the same when it comes to sizing of operations. Those did not change size wise or CPU memory wise. Um, we just increased the numbers of objects and metrics and then the collectors themselves, they're a little bigger than they used to be.

I think I looked at it as four, about 16 now for standard, um, size. And that is the other one I count for. You only get one of those out of the box when you install from Greenfield.

So if you wanna have more than one, then you would wanna count for that as part of your hardware adjustments. And I know you said you're working on a calculator in the meantime, I assume all those figures are in the docs somewhere on, on the Broadcom site. Yeah.

And we're you would've to pull them out individually from multiple articles like, operations need this and the sex managers need that and, and, and do the math myself? Well we're, we're working on it. So I think you guys have probably seen the old planning and prep doc that was originally for five.

Hopefully you guys have seen that, that has some of the numbers in it. Um, and it counts for some of the numbers. What we're trying to do for future releases roadmap is build that into the product itself so you don't have to go somewhere else.

But right now I think it's in a couple places, but it is something I've taken offline with my leadership that says we need to come up with one place to put all these sizes so people can have one place to look when they want to go find out what they're gonna have to deploy. Yeah, so it is on my list to do. Yeah, so, so it's still like this, you need to spend a lot the time in, uh, an Excel sheet before you start doing anything.

We we're trying to also take that spreadsheet in future releases and getting it back into the product. So the goal is that as we get further down the road, you won't have to have external resources to do any of this. We'll have our sizing in the, in in the installer or in a location.

We'll have our IP requirements somewhere. We'll have it all within the product. So you just log into the product, the product tells you everything that is the goal, but we're just not there yet.

So we still have the PMP if you want to use the PMP, but it's a lot less. It used to be like, I think 26 tabs. I think now it's down to like five tabs.

So it, they, they've changed it a lot. So hopefully this was helpful and useful.