VMware Cloud Foundation 9.0 – A Unified Platform for All Applications
As modern applications continue to evolve, so must the platforms that support them. VMware Cloud Foundation (VCF) is uniquely positioned as a single platform that seamlessly runs both VMs and containers – bridging the gap between traditional workloads and modern, cloud-native applications. In this session, Broadcom’s Katarina Brookfield will explore the latest innovations in vSphere Supervisor, the integrated Kubernetes-based declarative API layer that’s become foundational to the private cloud experience in VCF. Learn how these enhancements accelerate Kubernetes operations while preserving the control and consistency enterprises demand. We’ll dive into the latest capabilities that elevate flexibility, isolation, and operational efficiency – highlighting enhancements like Management and Workload Zone separation, modular enablement of the Supervisor, namespace isolation integrated with VPCs, and significant improvements to the VM Service, including support for importing existing VMs. We’ll also showcase updates to the vSphere Kubernetes Service (VKS), offering a powerful, built-in Kubernetes runtime optimized for VCF environments.
The VCF 9 presentation highlighted its unified platform approach, leveraging the vSphere Supervisor declarative API to manage both VMs and containers, providing a cloud-like experience within a private cloud environment. The core idea is extensibility, allowing users to select capabilities from a catalog and introduce new functionalities, while abstracting away the underlying infrastructure complexities like compute, storage, and networking. Katarina Brookfield demonstrated deploying a virtual machine and a Kubernetes cluster through a single user interface, emphasizing new features in VCF9 such as deploying VMs from ISO images, enhanced network configuration with VPC integration, and guided CloudInit inputs, plus improvements to customization of VMs, all handled through a curated interface by administrators.
A significant portion of the presentation focused on vSphere Kubernetes Service (VKS), showcasing its ease of operation and extensive functionality. Users can customize Kubernetes clusters, mixing operating systems and adding labels. The VCF CLI facilitates managing these clusters, allowing users to register clusters, create contexts, and manage packages, including Istio support. Brookfield demonstrated how cloud admins can update the VKS service version, unlocking new Kubernetes releases for consumer deployment, ensuring governance remains with the cloud admin while empowering consumers with the flexibility to update their clusters.
The presentation concluded with a demonstration of GitOps patterns using ArgoCD service, a new addition that enables continuous delivery of applications. Katarina Brookfield showed how to deploy an Argo CD instance and integrate it with a GitHub repository containing YAML files for both Kubernetes clusters and virtual machines. The talk also touched on how the Supervisor layer is decoupled to expedite release of new features. Broadcom emphasized that the latest functionalities are best experienced by making VCF Automation the single point of entry to the whole ecosystem.
Presented Katarina Brookfield, Staff Technical Marketing Architect, Broadcom, as part of VMware Cloud Foundation 9.0 Showcase – Modern Private Cloud. Watch the entire presentation at https://techfieldday.com/appearance/vcf9showcase/ or https://www.vmware.com/products/cloud-infrastructure/vmware-cloud-foundation for more information.
Transcript
Hi, my name is Kina Brookfield and I'm part of the technical marketing team in the VC of division at Broadcom. And in this session we'll be talking about VMware Cloud Foundation nine, and how we've built a private cloud that is made for all of your applications, whether those are running in virtual machines or in container, and what you need to really support all of your workloads with Beware Cloud Foundation nine. We have promised you that we will deliver a private cloud, but what does that actually mean for your workload?
Well, when you think about it, it's not simply just about deploying virtual machines or maybe deploying some Kubernetes clusters and applications running in containers, but it's really about emulating that cloud experience on your premises in your private cloud. And in order to do that, we needed to build something more robust, something that gives you services that you need to support your workloads. So whether you're talking about cloud services, infrastructure services, or any kind of additional functionality, that's the kind of experience you would expect from a cloud, especially from the perception of a consumer that is coming into the cloud to deploy their applications and have everything self service and on hand.
And that's what we will focus on, uh, in the following slide. So mainly in order to unlock this cloud experience for all of your workloads, whether those are virtual machines or containers, containers running in Kubernetes clusters, we had to come up with a unified way of controlling everything that's running in the ecosystem. And the way we've done that in VCF F nine is by embedding this declarative API, which is called V four supervisor, which exposes a desired state ecosystem with an API and a set of services that you can use to support your workload.
So whether you are deploying virtual machines, ku, these clusters, containers, or any other services that you would need, because for your applications, you may need a load balancer. So we do have a network service that comes in a platform. We also have volume service if you need to be deploying any persistent volumes, but also additional services.
For example, if you want to store your containers in a private image registry, deploy harbor on a platform. But the main idea of this ecosystem is that it is extremely plugable. And what does that mean?
While we know that there are some core services that we need to offer out of the box, we give you the power to choose and select what capabilities you want to bring into your ecosystem by selecting services from our catalog and an easy way of introducing new functionality onto the platform. But the best thing about this extensibility is that having the same target and the same tic API guarantees that you will have the same consumption experience as well. So we're no longer talking about integration points, but the native deployment of functionality into one location.
And also importantly, especially from the consumer experience and again, a cloud experience on your platform, we are extracting away all of the underlying infrastructure. So a consumer really doesn't need to know anything about, uh, about compute or storage or networking in order to be able to fully self sufficiently deploy applications, uh, and any services that they need. And in order to see this, um, I will guide you through a set of demos.
So at first, we will look at some basic workflows like deploying a virtual machine or deploying a Kubernetes cluster. What I really want to highlight here are mainly the new things that we have produced in VCF nine. Then we'll look at how we can update some of these services and how does this lifecycle of, um, VFI Kubernetes service, for example, specifically work.
And then we'll talk about something that brand new, uh, just recently introduced and very exciting. And that is our own GI op service. What we have done is we have introduced Argo CD service into the platform to give you that continuous delivery.
And we'll end with a little demo about updating the supervisor itself because I want to show you how you can unlock this new functionality really easily on your platform. So here we'll start in my lab environment, uh, where I will show you how a setup of VCF nine would look like from a consumer perspective. I'm accessing VCF nine through our automation portal, which is brand new and fully changed.
And all I have to do is define my organization name that I have here, and a username and password that was given to me to access. And as soon as I enter, I can see everything that I need to see as a consumer. I can see, uh, overview of services that are available to me.
I can see utilization of the space, but I can also see all the projects that, um, I'm member of namespace that have been created here, and then users that are part of this. So let's use this single user interface to deploy workloads, and we'll start with a virtual machine. Under services, you will see the main services that are exposed to you, one of them being the virtual machine service.
So here we're going to go ahead and create a virtual machine. And here we can choose whether we're deploying a virtual machine from an OVS template or now also with VVCF nine. We can deploy directly from an iso.
I will give my virtual machine a name, and I can also select this zone where I want this to sit, and an image that will be used as a base. So in this example, I will be deploying BUN two. I will then configure hardware resources of this virtual machine by selecting a VM class.
And I can continue, Uh, I I, since we're showing this from a consumer level, I take it what we're seeing is like a curated view, uh, set up by an admin or something so that the services that this user can provision and administer are, are limited to whatever they has been decided they have access to. Kind of like how we have public cloud governance, now we have it for private cloud Cloud. That's absolutely correct.
Everything I'm showing you now is the consumer experience. So the user who is deploying the workload, what I will show you as well is the other side, what's in the background. And that's the part that the cloud admin would set up because exactly, we need to have the governance and policies to select what can be deployed on the platform, what is available to the users.
So absolutely that is controlled by the admin. Thank you. Uh, so in this flow, if I wanted to, I could also directly access some of those other services I was mentioning.
So for example, if I wanted a persistent volume, I can directly, uh, request it in this flow. And similarly, if I would want the load balancer to maybe open up some ports on this virtual machine and from them by a load balancer, I can do this in this flow. So it really shows the nice integration of the platform, again, completely abstracted for me as a user, but the part that is the most exciting one is always the full customization of the virtual machine I am deploying.
Because I'm not just creating a Shell virtual machine. I have the possibility to pass through cloud in IT and do a full configuration of my vm. If I will be deploying Windows, I will be also using spr.
And one of the new things that we have introduced as well is to give you a little bit more guided inputs into cloud in it, in case you don't have a full configuration at hand. So this is really simple. For example, what I can do here is I can create a new user.
So what I will do, I'll create a new user that's called DevOps. I will enable the user to log in with SSH, and then I can add comments that I want to run during this first boot of the virtual machine. So for example, here I will show how I can deploy A-C-L-I-V-M and install all of the tools that I will be using later on.
So for example, our brand new V-C-F-C-L-I, that I will show you a bit later with all of my command set there, I can continue with the configuration. The avenue thing that we have introduced, and this is really exciting as well, is the ability to do more network configuration during the deployment phase. And especially because with our new integration with VPC, we have much more control over networking.
So as a consumer, again, I may decide to create my own VPCs with a public subnet allowing me to access this virtual machine on an external IP address, because normally everything would be deployed by default into private subnet. So I will show you how to switch this into public. And then again, we have few more options we can do.
So we can pass through configuration, like for example, the host name, domain information, and DNS and the full configuration of this virtual machine. Because keeping in mind, this is all, these are state has been written fully automatically for me on this right hand side, not just for the virtual machine, but for any objects that I will be requesting in this flow. So I don't have to know the structure of this YA file.
Um, I don't need to know how to, uh, um, how to add all of the options. It is done nicely for me. Do we have any place, uh, to keep, uh, centralized secret management or we have the secrets in some files, um, just storing our own solution.
So we have just introduced again and VCF nine, our own secret store where you can create secrets, um, and store them centrally, uh, manage them with policies and governance and then inject them into any workloads we're deploying. So whether that's virtual machines, um, containers running down, uh, vks clusters or in these per pot. So there is a brand new service, um, that is available on the platform, again, can be introduced.
And then within the services there would be a special, um, uh, tab for secret management. So we will now, um, download these files and just continue to deploy this virtual machine. Once it is deployed, uh, we can see it was given, uh, an IP address as well.
And we can see some basic things in the, uh, user interface, like the opening remote console or for example, we could do some data operations. For example, if you want to recharge the virtual machine, you can change the VM class to, uh, maybe give it a bit more CPU or memory. But what I'm going to do now is grab that external IP address and just directly SSH onto this box using the user that I have created during the guest customization phase.
So we can see that that's working fine. Now I can show the versions of the commands that, or of the utilities that I have installed in here. So we can see that the full configuration that I've passed through as worked well, but there was a virtual machine.
And the topic here is we're talking about this unified platform for everything. So now we're going to use the same experience, the same user interface to deploy Kubernetes cluster. And in here when we deploy a new one, we can select default.
I'll get to that in a minute, or a custom configuration, which can show you, um, uh, more options. I'm going to give my cluster name and then I can select a release that I'm going to use to deploy my cluster. So for this demo, we're going to go with version one to 30 team.
Following this, there are more configuration options that we have added to the user interface. So for example, if you want to control your certificate workation, you can do it directly here, um, or some advanced networking options. Uh, during standard configuration, we continue with the configuration of a control plane where we can choose from photon or Ubuntu operating systems.
And then moving on to our workload, uh, to our work, no work note. So in here I'm going to create a note pull. I can select an operating system.
So as I mentioned, for example, in here, I'll switch to TU if I wanted to. I can also follow our processes to deploy, uh, or create my custom image for Windows. If I would have any Windows containers, then I would be able to deploy Windows-based work noes.
The control plane of the cluster would still stay, uh, Linux-based. And some of the new things we've added here, for example, if you want to add any labels to your nodes, you can do it directly, uh, again, in the user interface, which is really need. With VKS, we really try to give you and give the consumers a service that is really easy to operate, but also has a lot of functionality.
And it's really up to you how you want to create your clusters. If you want to create clusters of different versions, what kind of sizing you want to do? Small clusters, big clusters, depending on your need.
So for example, if I wanted to, I could mix and match the operating systems. For example, I could add another note pool with different configuration or maybe different operating system. So that's always, uh, available to me.
And again, the full customer's, uh, full specification has been created for me with all of the fields. But always keep in mind that this is just a subset of what is available in the actual API. So, uh, for example, one of the use cases I do all the time, it's also great if you need to create a structure of your cluster to have the base.
If you then want to go on and add some advanced features that are not exposing the ui, you can do that directly by, um, uh, using, for example, the CLI to apply this, um, and add the configuration that you need. But again, same as we did with virtual machines, I'm going to download this because we'll get to that later. And now I can just wait few minutes until my cluster is ready.
Once it's done, I can download its cube config file if I want to, um, to have access to that directly. I could also do some data operations on this cluster. For example, if I wanted to add any persistent volumes as an addition, I could do it as a data operation.
If I wanted to do any scaling, it's extremely simply to do it with simple to do it with VKS, all I have to do is edit. For example, my note pools change the number of replicas, scale out my cluster. Very, very simple to manage, um, and operate.
And what's also really helpful is that, again, in the same view, I can see all the resources that were deployed for my cluster. So for example, every Kubernetes cluster needs, um, needs a load balancer, uh, that is fronting the fronting the control plane. Um, and we can see that the network service here has automatically created that for us, and we can see the external ip.
Good question about, um, the, uh, east, west, um, traffic between cluster. Is there any service mesh or something similar, um, be implementing or in this ui? So it's, is it difficult to bring those, um, one or more cluster with service mesh, you know, and, uh, is this, uh, uh, UI solving this problem or, uh, just reduce the complexity to manage, for example, uh, uh, me a meshed cluster?
Mm-hmm. Uh, so I have, uh, several answers to that. Um, maybe depending on what exactly, um, is the end goal when it comes to service mash.
What we did introduce in, um, in the latest release is support for Istio, um, which we deliver as a VKS, uh, standard package, um, okay, that you can install on the clusters. As far as the user interface, uh, in this particular place, um, it will allow you to deploy Kubernetes clusters. It does not give you user interface directly into the cluster if that is what you are referring to.
However, we also have our case cluster management, which is bringing a lot more functionality for the kind of multi cluster management policies, um, and things like that. Yeah. Um, yeah.
Thank you. Um, yeah. So, uh, within the, uh, uh, user interface, what I just wanted to show you, because our BK clusters are deployed as virtual machines in the background using VM service.
So the platform is using itself. You can see those listed as well under virtual machines. If you want to, you can filter them out.
So we can see our clusters here. And now we can use our new CLI that we have introduced called V-C-F-C-L-I to work and manage, uh, work with and manage this cluster using this cluster plugin. So the first thing I, I will do is I will register my cluster and I will get its cloud config using the CLI, and then I can create a context, uh, for this cluster.
This will allow me then to switch back and forth between my vSphere known space context, where I'm deploying the cluster and the cluster itself. Um, so in here, uh, we have added a new context, then we can just switch into that. And once we switch into the context of the cluster itself, we can use our standard QCTL commands to, for example, list a note, uh, regarding those packages that I've mentioned previously.
The way we, uh, do package management on our Kubernetes clusters deployed with VKS is again integrated with this V-C-F-C-L-I. So all we have to do is add a package repo or package repository that we, um, continuously update and add new functionality into. So I have added the latest, and then I can list all of the packages that are available for me to install in my B Cs cluster.
So as you can see, there's, um, there's packages we've had for a while, but some of the new things I'd like to mention, for example, with autoscaler, we now have support for, um, uh, scale down to zero on worker. No. Um, and one of the new, uh, packages, as I've just mentioned, is Istio coming, um, into this.
So you can go and, um, deploy that. But what I wanted to show you now is, uh, as, as we have seen, uh, in this demo, we have deployed a cluster. We've deployed the latest version that was available to me as a consumer, but the version that we have deployed was Kubernetes version, um, one point 32.
4, which supports Kubernetes release one point 33. So what I can do as a consumer is I've switched my context back to my namespace, and I can list all of the Kubernetes releases that are available in this space. And what I will see here is that I do see 1 33 listed, however, it is marked as false, which means that it is not compatible.
And this is because the version of the service needs to match, uh, and unlock this functionality. So from a consumer perspective, I can see it's available. I can ask my cloud admin to update this for me if they haven't already done it.
Uh, but I do have a full visibility of all of the releases that are available. This is because we distribute all of our v Kubernetes releases, VK using a subscribed content library that we create by default. So the images are already there and ready to use.
We just need to make sure that the version of the service is updated. So in order, I'm sure I heard you're right, uh, you said that if I, as the consumer want to get to that latest version, I have to ask the admin to, to upgrade, and I cannot do it myself. That is correct.
And that is by design, because as, as we've mentioned, uh, the cloud admins are the ones who have the actual access to the infrastructure. As a consumer, it's completely abstracted for me. So I do not see it.
And also, I may not know what the policies are. Maybe there's a reason why certain, uh, versions would not be allowed or maybe, uh, this, there may be multiple organizations using, um, using the service and, uh, need to align on the version. So it's the governance of it stays with the cloud admin.
Would the same be true for deploying a new application on a new Kubernetes cluster? Like, Hey, I wanna deploy a new one. I want to, uh, cluster with the latest version.
I, I need to request that through the admin as well, Uh, application onto the Kubernetes cluster. Specifically, I, if I am deploying a new an application and I want a new Kubernetes cluster at the latest version, is that also a request to the admin for me as the consumer? Um, as as far, um, as soon as the, uh, cloud admin, uh, uh, updates the service version, which I will show you now, how simple that is, we will see that you will immediately see, uh, 1 33 listed, and you can then go ahead and deploy clusters, uh, as you, as you want to.
So from the cloud admin perspective, now I switched over to the kind of vSphere view. Um, we will see our namespace with the resources, and then we can go into our supervisor services, which is, which is our, uh, which are services which have their own lifecycle management. This is what gives us that ability to release new versions of VKS so fast and so rapidly to be able to give you access to new versions of Kubernetes really quickly.
4. So all admin has to do is go and grab a definition file, uh, that defines the version of the service. This is now located on our support portal.
So all they have to do is go in and download this simple file, save that, and now within the service, they can just grab that file, upload it, they don't have to do any changes to it. We finish. And this will add additional version that will be available for installation.
So we'll see the active versions, zone two, three, and now if we go to manage, we can select the version we want to install. 4. So they just select the version, select the supervisor, and then, uh, uh, continue the operation without having to do any changes.
That's all they have to do. So it's really simple for the admins to, uh, manage this. And as soon as the services configured, we can go back to the command line, and now we can see that the status has changed to true.
And if we go back to our user interface, so again, you can see we've already have that version 1 32 there. But now when I go to deploy a new cluster, I can immediately see that version 1 33 is available. I have selected the default configuration because that automatically selects the latest version that is available in here.
So we can see it in here. We can also see it in the spec. So this is happening at the same time.
The admin has updated the service as soon as the service is updated, because I already have the images available anyway, they are now unlocked, I can straight away go ahead and deploy this latest version. So I'm just going to like, finish and deploy this. So again, the service does not affect all of the clusters that are in the infrastructure.
It just gives you the ability to use those versions and also brings new capabilities. Uh, for VKS itself, Uh, when I'm, uh, from the user perspective, uh, can I update this cluster? When you add this version, uh, to this, to the pool, let's say I can update the o older cluster to the newer version by myself, or still I need to ask the, uh, let's say administrator, provider administrator.
No, no, no. Uh, as soon as the version is available for you to use mm-hmm. As a consumer, you can use it.
So yes, you can update all your clusters straight away. Use it. Nice.
So, so it's, it's really just that governance of the service, because as a consumer, I don't have access to that infrastructure and that by design, that's why the cloud admins do that, do the tasks. But as a consumer, as soon as that's done and that's done once, as soon as that's done, I can go deploy new clusters, update my existing clusters. Um, that's fine.
One thing I would mention though, which is, uh, also important is that we have changed the way we do our cluster class, which is, uh, defining the cluster, uh, setup. Uh, and it's now version. So we will not trigger and update automatically to give you more, you know, more, um, control over this because you may not want to update everything, uh, by default.
So your existing clusters will not be, uh, updated unless you specifically select to do that. So in here we have an overview of everything we have deployed so far, but the really interesting thing, and this is completely brand new, is the possibility of doing some more advanced GI UPS patterns. So what I want to do, uh, in this section is show you how we can work with Argo City Service that we have just introduced.
The first thing that I'm going to do is I'm just going to create an additional, uh, namespace or test, um, in this project just to have a separate space where we will deploy the same workloads that we have done, uh, previously. That's the reason why I was downloading all of those yamo files. You'll see that will completely reuse them.
So what I do here, again, from a consumer perspective, there's, there's things that have been configured for me. So the namespace are defined by a namespace class, which dictates which VM classes are available to me if there are any CPU memory limits, for example, reservations, access to storage and, and, um, everything like that. So back in our CLI, we can now sure what is available in terms of I cd because again, this full ecosystem is, um, KU brand is based at clarity of API, which means that all I can do is just list all of the CRDs that are available to me and really specific, uh, information about, um, all the APIs, uh, as a consumer directly.
And then I can see what's in there. For example, here, I can see that Argo CD service has been added and the version that has been deployed. So all I have to do now is to deploy an instance for me because the service itself is operator, uh, model.
So the, for example, the cloud admin would deploy Argo cd, uh, service, which is an operator allowing consumers to deploy their own instances of Argo cd. So I have a very, very basic, um, definition of an instance just to show you how simple it is. You don't really need, um, any major configuration files.
It's pretty much just name and, uh, version, which we've seen. And I'll apply that and just wait a little while for these bots to get deployed. Once everything is running, I will check the service to get the IP to access, um, the server or the instance that I have deployed.
'cause again, that's a load balancer that's providing the external IP address for access. And then by default, when you deploy something like Argo cd, it has a default admin user and its password is stored in a secret. Well, I'm just getting that out of there.
And with that, I can just test that. I can now access this. So using that ip, and as I said, the default user here is admin, so I'll just take that, the account and, um, directly in, but that's not all because we are also providing, um, uh, during our, your download, you can also get the igo C-D-C-L-I to be able to manipulate it, um, using CLI, if you prefer that over the, the web user interface.
So I'm just going to install that on this box and I have it fully available to me. I'm just going to grab the secret and the service again, because what I'm going to do now is use that Argo C-D-C-L-I to log in to that instance. So I'm just going to give that the name and again, the password, so that's successfully logged in.
And just because, because I don't want to be remembering the password, I can update it. So I'm just going to very quickly do that. So again, you can see I'm doing all of this as a consumer completely, uh, by myself.
So now what I'm doing in this, uh, section is just adding, uh, the two namespace, uh, into, uh, into Argo City as a destination cluster. Uh, I'm adding the namespace where I've deployed Argo City, but also the test namespace that we have just created, because I will be deploying my workload into that. So you will see that it creates some service account and role bindings to have necessary permissions to work with that.
And back in our, uh, browser, I have a very, very simple GitHub repo that I have created for this purpose. And I'm going to grab those YAML files that I have downloaded during the initial deployment demos. And I'm just going to place them here.
And what we will see here is that I'm combining both my Kubernetes cluster and a virtual machine, because again, I'm targeting a single API on a unified platform. So when I create an Argo CD application, not going into too many details, very simple, just gave it a name, giving it a source, which is the GitHub repository, uh, path, which is root, and then the destination, which is supervisor that we have added, and the name space that we have created. And all I do here is make sure it goes into any sub folders, if there would be any, and create that.
And this will then start doing continuous delivery. So it will match the state that is requested, the desired state in my YAMA files in the GitHub repo, and match it with the actual current state on my platform. So you will see, we'll start deploying all of the resources that are required.
So that's not just the actual vm, for example, we see, but all of the things that are in the background as well, uh, that are required. And after a while, as we will see it has deployed everything in our platform. So we have repeated what we have deployed, uh, manual through the user interface in the, in the first part of the demo.
Now we have reused those same files to deploy them, uh, again, in a different location. But again, this is just the tip of the iceberg because ops is about much more, but it's really showing the idea of defining everything as code. So whether that's your infrastructure, whether that's your, you know, your, the, the, the workloads, the policies, networking, storage, everything defined in code allows us to store that and get, and then use tools like Argo City, for example, to do that continuous delivery for us.
So if I would then decide to make changes to these workloads, may maybe, um, deploy more resources, add a load balancer, I could do that, uh, by just introducing the new files, um, into that repository and having Argo cd, um, take care of that, um, and make sure that, that this new desired state is matched for me. So this is, as I mentioned, completely brand new, um, wasn't even there during the GA or VCF nine. So how do we get there?
And that's the last section that I really want to cover because I did talk about the way we deploy, uh, or update VKS. And the reason why we do that and have this independent lifecycle is that we can do it independently, which means we can give you new versions, new functionality really, really quickly, and you don't have to upgrade everything to get there. And what we have introduced in VC of nine, it's the same kind of decoupling for the actual supervisor layer as well.
So that's the last part of this quick demo that I want to show you. Um, and again, it's very simple, would be done by the cloud admin. So we need to differentiate between the kind of personas.
The easiest way, uh, to think about it is the cloud admin is the person that actually has access to vCenter and the v uh, the v VCF layer, and does all of that configuration of infrastructure. The consumer is really just having that cloud experience, so requesting services, deploying workloads, deploying apps, not uh, caring about what's underneath all of that. So in order to update a supervisor, what we have to do is we have to assign a content library.
Uh, we again, created a, um, um, library, which you can subscribe to, or we will be releasing all of the new images for supervisor. So if you would check it now, there's already one that we have just released. So I've added that content library.
And now under my management, I can see that I have a new version available. 5. You can see that we have a new version 1 30 10.
And with these updates, I'll just continue with this, just apply this. And what this again allows me to do, updating supervisor not having to update vCenter, not having to, uh, update anything in VCF. It's completely separate.
So we can just proceed with these tasks and it will go ahead and, and do a rolling update. If you, um, if we will go into the configuration, we will see that it's actually deploying a, a second control plane VM with, uh, the latest version. So we'll just let it do its thing, match the desired state, and after a while this will finish and we will see that the version has been updated in here.
So the current version is here. And also if we go into the supervisor itself, we will see that it has been updated. So this was the first async release of supervisor.
There will be more coming. And one of the most exciting things that this, uh, particular update has unlocked is that access to Argo CD service. Mm-hmm.
I have a question here. Um, do we have a rollback function? Rollback function of the supervisor?
Yeah. Or we can call back to the older version even in case something happened. You know, Uh, to be completely honest, I will have to check whether there's a rollback function in the user interface directly.
However, uh, what, uh, you can definitely do is, um, and would be advised as well, is to take a backup of the configuration before you proceed with any updates. Um, and you can always do a restore of the supervisor itself, just of the supervisor itself to re uh, recover or, or restore the functionality. However, uh, that's a very interesting question.
Uh, I'm not quite sure I have the answer, but let me, let me have a look, maybe ask, um, just to double check and, um, I can come back to you on that, whether it's directly in the user interface to go back. Thanks, And we're coming to the end anyway. Uh, but what I really wanted to show you with this is that we have created this unified platform for all of your workloads.
It doesn't matter what you are deploying, it's all there for you. But most importantly, it's all managed with a single API on a single platform. And with all of these services that you can pick and choose and introduce into a platform, so if your container images will be stored in Harbor, you can deploy that.
As we discussed, if you want to do secrets management, you can deploy a secret service, which is one of the new ones. But there are plenty of services for you to choose from our catalog and implement on or introduce into the platform, but still guaranteeing that your consumers will still have the same experience, whatever they are deploying. And, uh, these features are available when you implement automation, right?
It's, uh, not just coming with, uh, when you set up the pure VCF nine plus automation or just come out of the box, how it, how it looks like when you get those. So, um, let me answer it maybe from the perspective of why you would want to introduce VC of automation. First of all, in VC of nine, VCM automation is not just a new version of Aria Automation.
It has really been completely restructured to act as a single point of entry for the consumers to get this full experience and to really utilize the, the capabilities of the cloud with, um, a single entry point. Having said that, the functionality of supervisor is a functionality that can be deployed, managed, and added, um, within the supervisor itself. So within the, the vSphere client, however, not all of the, uh, integration, maybe not access to all of the services would be available.
So we would definitely strongly recommend that in this new world and this new way of VCF nine VCF automation should be the primary entry point into this ecosystem to get the best cloud experience. Good to hear that, especially that it's just there, right? So it's not like you need something additional and you just tap a button and they're gonna be VCF automation.
Yes. What you will, what you will see, the two main portals, let's call it, that you will see, depending on your role, will be VCF automation, VCF operations, but it's really all about a unified platform, which is VCF.