Welcome to the virtualization room, Simone will talk about OCD virtualization.
So, hi all.
Nice to see you here.
Today we are going to talk about OCD virtualization.
We are going to have just a quick intro for who doesn't really know what OCD virtualization is, just to get a bit of context.
Then we are going to see how you can use CRC to play with OCD virtualization at home in a really small footprint.
Just if you want to try it or if you want to start developing on OCD virtualization.
We are going to see a couple of new features.
I choose this one because they are cloud native.
I think that they are a bit different from what you use it to see in related kind of products.
And then we are going to see next challenges for us.
So, let's start from OCD.
What OCD is?
OCD is a distribution of Kubernetes.
It's a sibling distribution of OpenShift Container Platform, which is the data distribution of Kubernetes.
OCD is the community of the upstream release of the VET.
It's based on physical machines that can be bare metal or virtual machines on a hyperscaler.
In our case, it would be better to use bare metal nodes just because we are talking about a virtualization solution.
Then we are going to have hosts there that nowadays are based on Fedora CoreOS,
but then we are going to see that this is going to change.
Then we have all the Kubernetes stack and you can use it to start your application.
Now, what is KubeVirt?
KubeVirt is a set of virtualization APIs for Kubernetes.
So you can extend Kubernetes in order to be able to run virtual machines that runs in containers on your Kubernetes infrastructure.
At the end, it's still using the KVM hypervisor.
It's able to schedule and manage virtual machines as if they are native Kubernetes objects.
What is its main advantages?
It's that it's cloud-on-active.
It means that you can use all the Kubernetes stack.
So the container networking interface for the network, the container storage interface that you are already using for Kubernetes for the storage.
It's based on customer source definition and customer source that are a way to extend Kubernetes with a new API.
It can schedule virtual machines as native Kubernetes objects and you can manage them to talk with what you already developed as a microservice.
So in an ideal world, you are going to rewrite your application from scratch, completely split into microservices.
In the real world, probably you have a bit of legacy code or something that is already running in a virtual machine.
When are you supposed to schedule it on an external hypervisor or on the same infrastructure that you are using for your microservices
with the capability to have them talking natively to your virtual machines?
CubeVirt is the response for this challenge.
Now, how can you test it at home?
You can easily try it with CRC.
CRC is a really quick way to start playing debugging, hacking on OpenShift in general.
CRC is a micro distribution of OpenShift that runs in a virtual machine that can be executed on your laptop.
It's absolutely not intended for production usage.
It's going to be executed in a virtual machine.
So it's a single-node cluster.
It's not going to scale out.
It's not going to support upgrades.
It's just a test platform.
In order here, just a few instructions if you want to try it at home.
Since we are talking about a virtualization product and you are running it in CRC, which is a virtual machine as well,
you need to enable Nest virtualization on your laptop in order to be able to start virtual machines inside the CRC one.
Then you can tune the configuration.
Normally, CRC comes with a really small configuration.
If I'm not wrong, it's about 9 gigs of RAM, which is not that small,
but it's just enough to run the OKD by itself.
If you want to think about playing with a couple of virtual machines and so on,
it's better to extend the memory up to at least 20 gigs in order to be able to do something realistic.
It's also nice that CRC already comes with a CubeVirtual Path Provisioner,
which is a way to dynamically provision PV persistent volumes for your virtual machines.
As you can imagine, a pod is something ephemeral while your virtual machine needs a persistent volume.
You need a way to provide persistent volumes for your virtual machines.
CRC is just a virtual machine where you can run other virtual machines inside,
but you still need a mechanism to provide persistent volumes for that.
It's already integrated in CRC, but you have to extend its disk in order to have a bit of space to create disks.
At the end, you have a gesture to execute a couple of commands, CRC setup and CRC start.
After a few minutes, you are going to gain the access to your environment.
Of course, you can do everything also from the command line.
Probably much of you are going to prefer using the command line here.
I mean, I attached a screenshot to the presentation just because they are nicer.
So you can connect to the user interface, to the admin user interface where you have the operator app page.
In the operator app page, you are going to find already there because it's distributed via the operator app mechanism.
You are going to find the CubeVirtual type of converted cluster operator.
As I mentioned, you don't need to configure the storage, so you are only supposed to install the operator and create a CR to trigger the operator,
but the storage is already pre-configured.
After a while, you will be asked to create the first CR for the operator in order to configure it.
Here you can fine-tune the configuration of OKD virtualization for your specific cluster.
In particular, we have a stanza called the feature gates where you can enable optional features.
Here we are going to talk about two features.
One of them is already enabled by default, which is enabled common boot image import,
and the other is deployed tecton task resources.
This one is not enabled by default, but if you want to do at home what we are going to see now,
you have to enable it.
You can enable it also at day two.
After a few minutes, the operator is installed.
It's going to also extend the UI with a new tab where you can see what you can do with your virtual machines.
So now let's start talking about one of the... In the last year we introduced a lot of features,
but today I want to talk about two of them.
The first one is golden images.
Why I think that it's interesting.
Nowadays, if you think to any public ground environment on public hyperscalers,
you are going to find... It's really used to use them.
Why? Because you can find their images for your preferred operating systems already available.
You have just to select one of them, click, and in a matter of minutes you are going to get a virtual machine
that it's running, you don't need to upload your disk, you don't need to upload,
eventually an ISO, start defining your virtual machine and so on.
They are really convenient.
We want to have the same experience also in CubeVirt.
So we introduced this feature.
The whole idea is that we are going to have a container registry
which contains some images with the disk image for your virtual machines
that are going to be periodically refreshed to include a new feature of their operating systems
or security fixes.
Then we have this new object called the data import corona,
which is going to say that you want to periodically pull an image from that container registry
with a schedule and import it in your cluster.
It's a mechanism in order to configure the garbage collecting, the retention policy,
but at the end the idea is that you are going to find images for popular operating systems
out of the box already available in your cluster.
They are going to be refreshed over the time, so each time you...
Let's see it. This is the catalog in order to create virtual machines
in the user interface of OKD virtualization.
We have a catalog with objects.
The whole feature is here.
As you can see for popular operating systems,
we already have a nice label saying that the source is already available.
It means that this new feature automatically imported for you
a golden image of that operating system
and it's going to continuously keep it up to date.
The benefit is that when you want to start a virtual machine,
you will be able to do it with a single click.
You can customize the name, you can say in which namespace it's going to be executed,
but everything is already ready.
With one click you are going to start your virtual machine.
What is going to happen on the storage side?
We see that we have some existing persistent volume claims
for the disk that got automatically important.
One of them is going to be cloned to be your virtual machine.
Depending on the CSI implementation,
this can be even completely afforded to the CSI provider
and it can be really fast.
After a few minutes, your virtual machine is there
and as you can see through CloudInnit or CSI, whatever,
it can be also customized to use a custom name and so on.
Our data in particular looks like,
we are saying that we want to have a data source named Fedora
with a schedule with the usual consequences.
We want to periodically consume images that are available on Quay,
which is a Docker register.
Here you can see the status and the image is up to date,
meaning that the most fresh version of Fedora
got automatically imported in your cluster.
The important thing is that if you look here,
you see that Fedora, the target for the Fedora image is the latest.
It means that when the next release of Fedora is going to come out,
it's going to be automatically available in your cluster.
Of course, we are providing images for Fedora for centers,
but you can use the same mechanism and the same infrastructure
to import on your cluster your own images.
You can create custom data source, sorry, custom data import columns.
Now, I want to talk about an additional really nice feature,
which is Cubivius Tecton Task Pipelines.
In the previous section, we see that we are able to import images
for a popular operative system,
but maybe there is some other operative system
that requires to create a virtual machine starting from an ISO
and installing it, so how can we automate it?
We cannot expect that the provider of all the operative systems
in the world are going to use this mechanism
and publish images for us.
We need a way to be able to automate the creation of the images
for other operative systems.
In this case, we are going to use a Tecton pipeline to automate this.
What Tecton is?
Tecton, also known as OpenShift Pipelines,
is a cloud-native continuous integration
and continuous delivery solution.
It's also cloud-native and it's fully based on Kubernetes resources.
It uses what are called Tecton blocks to automate tasks,
extracting the infrastructures.
In the Tecton world, we have tasks.
A task is something that defines a set of build steps,
like compiling a code, running tests,
or building and deploying images.
In our case, we are now interested in deploying images,
but as you can imagine, you can combine it with other tasks.
Then you can define a pipeline.
A pipeline is a set of orchestrated tasks,
and then you can use a pipeline resource,
which is a set of inputs that are going to be injected
into the execution of your pipeline,
which is a pipeline run.
On KubeVirt Tecton Task Operator,
we introduced some specific tasks
to create, update, and manage the specific KubeVirt resources,
so virtual machines, data volumes, data sources,
templates, and so on.
You are able to populate these images,
even with LibGestFS to inject files and so on.
You are able to execute scripts, bash, or PowerShell,
and whatever.
We have a set of tasks I don't want to give you,
but some are already available.
We are extending one.
We have an operator that is going to populate the task
for you and your cluster.
Now we want to see an example pipeline.
We have two pipelines that are going to be injected
by the Tecton Task Operator.
The first one is called the Windows 10 installer.
It's going to populate a golden image for Windows 10,
according to some input that you are going to provide.
The idea is that it's going to copy a template,
it's going to modify a template,
and it's going to start installing Windows from the ISO,
and it's going to create a virtual machine for you.
We can see a small demo.
Here is the pipeline.
We have to provide a few inputs in particular.
We have to provide the ease of Windows that we want to install.
It's the first...
Yes, there, perfect.
Here we see the pipeline.
The pipeline is going to copy the template.
It's going to modify it.
It's going to create a first VM that it's used
in order to install Windows
and then create the Windows image from that VM.
Here is...
Now we are simply going to see what is happening,
but everything is fully automated.
You don't really have to watch it.
But if you like, you can also see it live.
Here it's our virtual machine,
and as you can see, it's starting, it's booting,
and it's going to install Windows.
We have also a second pipeline.
I have a demo for that.
It's called the Windows Customize.
Probably we are a bit over time.
The idea of the second pipeline
is that you can customize this image,
running additional steps,
like installing the software that you need,
modifying the image, that it's going to be
one of the golden images
that you are going to provide in your cluster.
Let's move back.
This is the second one.
I'm going to skip the demo,
but if you have any questions, please please reach me.
The idea is that we can use this pipeline
in this case to install SQL Server and so on.
What's next?
OKD is going to change.
Now, in the beginning,
I told you that now it's OKD.
It's based on Fedora CoreOS.
We are going to have a big change there,
which is called OKD CentOS Streams,
which means that the nodes of OKD
are going to be based on CentOS Stream.
So it's going to be a really upstream
for OpenShift Container Platform,
where the nodes are based on Red Hat CoreOS.
CentOS Stream is the upstream of Red Hat CoreOS.
Everything on CentOS Stream is going to be built
as well using tecton pipelines,
just because we really believe in that project.
On OKD virtualization side,
we are going to introduce many features.
We are going to try more pipelines, more automation.
We are working on ARM support.
We are working on better backup store APIs.
We are working to reduce the privileges of the pods
that really execute the virtual machines.
We are working on the real-time area.
And here are a few links if you want to reach us.
Thank you.
APPLAUSE
Questions?
Sure.
There's already OpenStack and Cata Containers.
And I wonder how does OKD compare or integrates
or overlaps with these two projects?
So the question is, we already have other projects
like OpenStack and Cata Containers.
I want to understand how CubeVirt compares to them.
So the first idea is that in CubeVirt,
we are managing virtual machines
as first class cities on Kubernetes.
You can define a virtual machine
with a customer source
because Kubernetes provides a mechanism
called the customer source definition
to provide customer new APIs.
You can use them to define a virtual machine
as a really native object that is going to be scheduled
by the Kubernetes orchestrator
alongside pods and other resources.
The main benefit is that you can expose...
You can use the same storage that you are using for your pods.
You can have your pods talking at the network level
with virtual machines,
without the need to configure tanners and so on,
because virtual machines are running on the lower stack,
like if you have OpenStack under Kubernetes.
Virtual machine is going to be a first class citizen
of this infrastructure.
So it integrates with OpenStack?
So not really integrated.
If we go here...
Okay.
Here the idea is that we have something here,
which in our case probably is going to be Bermeter nodes,
but it can be also another IPA scaler,
but in that case you need nested virtualization,
which is not always the best idea.
Then you have Linux host nodes,
now with Fedora Core rise,
but in the future with CentroStreams,
and here you have Kubernetes stack.
Kubernetes is going to schedule pods as containers on those nodes,
and the virtual machines bear.
So you don't really care of what you have on the last level.
Yeah, you showed how to install Windows and prepare images from pipelines.
Isn't it easier to use simple Docker file
and give it's possible to use just Docker file
and do that on way just building standard Docker images?
Okay.
So the question is,
you showed how to use a pipeline in order to prepare an image for Windows.
Isn't it simpler to directly use a Docker file to create a container?
So in tier it is,
but you have to start from an already running virtual machine
and take the disk,
because Microsoft is providing an ISO with a tool that you have to execute.
But you can use the same virtual pass and guest page tools
to install Windows inside the Docker Cloud.
But you have to execute it.
You have to execute the banner of installer.
So you have to, at the end,
you are manually running something that it's going to install Windows.
And at the end, you need to take a snapshot,
which is going to be your image.
You want to automate it.
You want to continue to execute it in order to fetch updates.
How we solved this?
We automated it with a pipeline because you have a set of tasks.
And so the pipeline is the most smart way to execute and monitor them.
Sure?
Last one.
Which format are the golden image disks used?
Which format are used for the operative system disks?
Do we support our format?
No?
No.
So just a little.
Thank you.
Time is up.
But if you want, please reach me outside.
Thank you.