All right, can you hear me, yeah?
Yeah, everyone.
So, good evening.
Thank you for coming.
I'm Victor Tozo, and we're here to talk about
VDI in Cooperate.
What the goal of this presentation is to tell a little bit about
what's the current state of the affairs?
What works well?
What doesn't?
And plans for the future.
So, first of all, am I?
I work within Spice for a little bit over four years.
Spice, I don't know if you know, it's this remote protocol
that used to...
It's still does work well.
I was in the very team in Red Hat for quite a while.
Nowadays, I'm working in the Cooperate infrastructure team.
And, yeah, I'm working in Cooperate more or less since 2020,
and I'm a reviewer there since 2024.
So, what is VDI?
The current rules, right?
Like, it's over to all this topic for infrastructure.
For the purpose of this talk, like,
trying to narrow down what it is,
is the technology to allow you to remote access
the virtual machine.
Yeah, everything that is needed for that to work well.
It's key to understand that integration with the hypervisor
is important.
So, the hypervisor, for instance, in this context of the stock
in the KMO environment is KMO.
And, yeah, we have integrated this play keyboard
and anything else that KMO provides as interfaces.
And, not guest resources.
So, because there is also the option of accessing a remote machine
inside of the operation system, right?
This is not a case with VDI.
We are talking about the hypervisor level in the host.
Yeah, talking about VDI.
There is also a little bit of confusion
and understanding about remote protocols as well.
So, VDI's VDI uses remote protocols,
but they are remote protocols are not VDI, right?
So, I have two examples here.
Running spice, like from the left,
Linux machine connecting to Windows 7
and on the right, a Windows machine connecting to
each other machines.
And the idea is that for the remote protocol,
it doesn't matter where the VM is running.
If it's actually in the guest,
it doesn't even matter if it's a guest or not.
Running like a VINC server inside of the guest.
Only matters that the protocol is being implemented
properly so you can access.
And, yeah, on the application level,
you see it's like just another application,
but in fact, it's remotely accessing VM.
So, this is the common case when we are talking about VDI
and in the case specifically of KEMU.
So, we have KEMU.
It runs a guest operation system,
the apps inside of the guest,
but KEMU itself also runs VINC server.
It has a VINC server integrated with it.
We can access the guest using that.
So, it exports the VINC server on a port
that you can configure here is like a 5,515,500.
So, which is the usual,
and then a VINC client can connect to it.
No.
So far, so good.
I didn't explain anything about comfort, for instance.
Kind of expecting the protocol.
But, yeah, if you do just raise your hand
otherwise it gets confusing.
But, in short, like comfort is basically
the way of running VMs in Kubernetes,
installing and making it as native as possible for Kubernetes users
to run workloads as VMs in Kubernetes.
Now, about VDI in Kubernetes today,
and for quite some time actually,
since the inception of Kubernetes,
the goal of VDI in Kubernetes is actually for troubleshooting.
It has not been a priority
to make that first class sits in VDI solution,
which is of course it's something that it's becoming
more of a problem, right?
Like we are becoming more and more users,
since let's say a company about another one, recently.
They are interested in having more and more VDI solutions
and in Kubernetes or products that are embedded in Kubernetes.
And this is one of the reasons that I'm here today,
which we start taking a step forward
into how to improve the situation in Kubernetes.
So, yeah, main goal is troubleshooting.
We use KmoVNC server, so it's what Kmo gives us,
basically, and the access is over VDI.
I'll show how it works,
but this is also another problem.
Yeah.
So what you see here,
I didn't provide a full load of components of Kubernetes
or Kubernetes, but I just want to pinpoint the main actors
of VINC over VDI in Kubernetes.
So you have the ingreen is the virtual entrepreneur pod,
and it runs then it has containers inside of it.
One of them is the virtual entrepreneur container,
the computer container that runs KmoVNC.
And let's say that someone wants to access this remote machine over VINC.
So the path forward today, what we have today,
is a super resource for VINC.
So we use the VIRT API, which is providing the super resource for us.
So basically what we need is the name space that the VM is running
and the VMI name.
So with just this two, the process has it follows, right?
The client will ask,
I want the VMC connection of this name space plus VM.
The VIRT API will receive this request and forward it to VIRT tender.
VIRT tender is our demo set and convert,
so it has high privileges.
So basically, this is what I'm saying is that in a cluster,
VIRT API will forward the request to the right note,
to the right host,
and then VIRT tender will receive the request
and we'll connect through this VINC server,
which is exposed as a unix socket in the node.
And VIRT tender will make it in this connection
between the HTTP request, the right request,
and the unix socket, making a web socket.
Main issue here is that the data flow of the web socket
will be the same as we see now.
And this can become a problem overloading,
or the VIRT API pad.
So as I said, the first problem of this approach
is the data pad.
It does not scale well.
And for that reason, since the inception,
we define that it's a for troubleshooting.
And for troubleshooting, this is fine.
We are just accessing the VM for why it's not booting,
and what's the problem there.
And for that reason, yes, one single connection per VM.
That's what we allow.
So we actually deny or remove.
It was too recently, we actually removed the VINC connection
that already exists.
We would drop that one, get the newer request,
we'll take over.
But now it's, we have options for that not you happen.
And another issue of this approach is that we don't have
an easy way to add new protocols.
So basically we are getting what Kim will provide to us.
And let's say that Kim will provide the different one,
actually does spice for instance.
So we have to create a whole pad for that new protocol,
or other protocols to exist.
And that's a problem, right?
It brings a lot of coding to the factory.
You want to reduce the how long it takes for someone
to access this feature, this new feature.
And that comes to the possible solution.
So Kim, all things early, 2022,
provides this display, debos interface.
So what does it mean?
Debus is something, does someone not knows what debos is?
It's a peer IPC protocol, right?
So the team process you can make a communication.
They can talk to each other.
So what this means for in this case is that Kim will export
all the VDI interfaces over this debos interface.
So now it will allow other process outside of Kim,
outside of VDI, in this case,
to connect and expose the graphical, the keyboard, everything.
As it will, as it wants.
So this is a great possible solution
that I implemented a proof of concept that I showed shortly.
But first, how we would work,
or at least how I'm proposing.
I'm proposing now at least what's implemented.
Yes.
So as I said, the idea is that Kim will now
we will expose this VDI interface over debos.
So the green actor here, which is the virtual launcher pod.
No, the virtual launcher container.
So I forgot to drown the pod.
Both VDI, the blue and the green are running on the same pod
in this case.
So the virtual launcher container now does not need
to expose the VINC server.
It just needs to connect to the Unix socket.
And the blue one is a sidecard container that I have launched.
And this sidecard container, because in the virtual launcher
by default, it does not have debos.
So I included a debos demon in the sidecard.
So what I'm doing here is like the blue container runs first,
because this is how the hook API in Kubernetes works.
It creates all the environment for this, for Kim,
which you connect.
And it will also change Kim,
and the virtual, using the virtual,
to change Kim to use the display debos.
So this is actually not too difficult to test on your own
if you want.
So yes.
So I'm proposing to have a sidecard this moment.
But in the future, the idea is to have actually a VDI sidecard.
This VDI sidecard, in this example, for instance, is running VINC.
And it will connect to the debos interface.
So it will get what Kim will provide as a VDI interface,
a VDI data.
And it will expose as it once, right?
In this case, I use the service object for Kubernetes.
So this also provides the possibility to avoid going through the VDI,
and some flexibility.
Again, this is a proof of concept.
So all the details on how this actually have to be implemented
needs to be discussed.
Yes.
Interesting.
The VINC server, in this case,
needs somewhat to be able to connect to debos,
and then feed the VINC server with the data, right?
The keyboard, display, and such.
So what I'm using here is this repo from my colleague
that he implemented our enrast.
This VINC server that connects over debos.
And that's it.
So the VINC server here is different from the one before.
The one before is running is the Kiml1.
That you can get with the dash VINC.
In this case, now I'm running another container.
It's another process.
And it's running this Rust VINC server.
And then it communicates with Kiml over debos.
I have a demo.
It's not long.
It's one minute.
So I will just quickly go.
I hope you can see.
Sorry.
But it's also in the link.
What I did here, yeah, as I said, right?
So because, yeah, in a minute,
you see that KimlVNC and KimlWRDP are the binaries that
connect over debos and expose VINC and RDP in this case.
Oh, I actually did both.
I'm exposed as a, yeah, that's remote view,
connecting over VINC to the VMI.
And I use a server subject and the port forward
for local Econnecting.
Now for RDP, actually needs credentials.
So I had to connect through the port and set the credentials there.
In this case, the user secret and the domain is home lab.
Now I can run genome connections,
which is the RDP client that I had at the time.
And set those and connect over RDP.
Yeah.
And it's the same VMI.
It's the same thing.
So this is the plan.
The proposal that I want forward.
I think there are several benefits that I didn't put in the next slide.
But let's say now we can have, as I said,
like we can go without passing the VINC API.
So not put in the burden of the data pad over the Kubernetes API pad.
We can start having different remote protocols as well.
So as I showed RDP is possible.
This debust thing is already quite for quite some time.
So there are quite a few possibilities.
And one that I care a lot is the being able to provide third part solutions.
Right?
You can provide your own container for VDI.
And run.
It's only needed.
It's only needed for you to be able to speak with the bus.
So as long as you do, you can expose whatever protocol you want with minimum changes to
Kubernetes.
So I think that that's great for the future.
Now, other possibilities as well for it's not necessarily, it's not really VDI.
But it's something that it's well established as well as using in guest solutions.
So for instance, in all nowadays with motor, you can have even the bus APIs there as well.
But you can have an RDP or VINC server.
And yeah, take one step back.
One of the benefits of VDI itself that I mentioned is that the guest operation system does not need network.
Right?
You can connect through it directly to PMO.
But in general, with RDP or VINC server running in the guest, you need internet.
You need networking access access.
So doing something like using VINC.
We can actually connect the running open server in the guest to the host and do some sort of bridging as well.
So it's another possibility that I heard and discussed before.
Benefits.
It's that it mostly uses guest resources for everything.
And yeah, it would work even without the guest network.
Yeah.
As I mentioned, there are some motor APIs and things like that.
Perhaps we can do some bridging as well between them, but it's more like afterthought.
So take away.
Yes.
In VDI, it's for troubleshooting.
That's that's very important.
Discussion for improvements is always welcome, but today that's the case.
Using this play over DBAS, it's very doable in a reasonable time.
I took a week to get this proof of concept in place.
And yeah, of course, you need to do the VAP and discussions upstream.
But you know, the technologies are already there.
Yeah, I didn't show any code because it's mostly container files, creative things and connecting things that already exist.
And yeah, allowing other protocols and third-party integrations.
And of course, in guest solutions is always the possibility too.
Although I don't see anyone pushing forward to that today.
That's it.
Any questions?
Yeah.
Yeah, that's cool question.
So the question was if you can use GPU acceleration.
So that's another point for discussion in the case of how that would work, because the container would need the GPU, right?
So let's say VNC wants to extreme H264 and GPU support for that.
So yeah, it will need how we will fit this this allocation of the GPU for the container in that pod.
In both cases, if you have the GPU for the VM,
then that means that the VM already sees the operation system already sees the GPU.
And it's what is running there, it will use it.
But if you're talking about in host that in the same layer as KMO,
now we have a GPU on OK to do that pod.
Is it a GPU for the VM to use or is it for the site container to use?
So this is the kind of thing that needs, but it's definitely doable.
Yeah.
All right. Thank you for the question.
If the buzz, would you?
Printers.
Ah, OK.
Yeah, cool, cool.
Yeah, no, no, that's actually a great idea, you know, like if you can expose it,
I don't know the use case, perhaps yeah, that's perhaps something interesting to think about.
So the question was, can I use the buzz interface from the guest?
Should do things that you usually, you do with the guest, like exporting printers,
do you printing?
Yeah, it's, I think it's a possibility as to do this kind of expose.
It's not necessarily a related to the video I had this, but I think it's not not difficult.
Yeah.
Sorry, I may say the company.
The conversation?
Yeah.
For example, if I have the environment in the virtual machine of the company,
and I want to be great to to connect this channel,
it's a faster or easier to, in the middle, give the computer probably,
I will go.
About migration then.
So the question was, if I have a VM on premise,
and I want to migrate to Cooperate, or you're already using Cooperate on premise,
and they want to migrate some cluster.
Yeah, so there are several projects.
There's Farclift for instance, and that does this kind of migrations.
They take VM where to, and move to, to each other.
Yeah, so you can, you can try to use those things, but you have to see the use case.
Migrating is, it's not trivial work.
It's not, it has to be careful because otherwise you may lose data or the workload.
Yeah, Cooperate runs on Kubernetes.
So it's a matter of how you do the workload that you have today running on Cooperate,
and there are a few ways of doing that.
If you want to, I can show you.
I don't know if it works, or they can do it for some, but I don't know.
Well, I didn't get the question.
So I'm currently in a social situation.
Okay, so it's basically it's feature parity.
So let's say you are using your passing through something,
some device in your own premise solution.
If you can have it on Cooperate, it really depends.
So it really depends if we are, what you're doing and how you use it.
Yeah, perhaps you have to adapt some stuff.
Yeah.
All right.
Any further questions?
Okay, so thank you.