community
community copied to clipboard
kubevirt
[GSoC] Self-sufficient Virt-handler
Title: Self-sufficient Virt-handler
Description:
Kubevirt is a Kubernetes extension to run virtual machines on Kubernetes clusters leveraging Libvirt + Qemu & KVM stack. It does this by exposing a custom resource called VirtualMachine which is then translated into a Pod. This Pod is treated as any other application Pods, and includes a monitoring process, virt-launcher, that manages the Libvirt+Qemu processes. The virt-launcher exposes a command grpc server for managing the virtual machine and has a notify client (see below notify server) through which it sends domain (virtual machine state) events and Kubernetes events.
Each node in the cluster is running a node agent, called virt-handler. The virt-handler is using the command servers of virt-launchers to manage virtual machines. It is also providing a notify server that collects domain and Kubernetes events from launchers in order to obtain internal state of virtual machines.
The hard dependencies on OS, file system, presence of virt-launcher Pod and GRPC servers make it hard to run virt-handler independently inside unprivileged Pod without the presence of virt-launcher. The goal of this project is to run virt-handler inside an unprivileged Pod and simulate a virt-launcher so that no Pod for virt-launcher needs to exist.
Goal:
The main goal of this project is to create a proof of concept to run virt-handler in an unprivileged Pod without virt-launcher Pods to be running on the same host. This will enable scalability testing with significantly less resources required.
Link & resources https://github.com/kubevirt/kubevirt Project size: 350 hours (to be confirmed) Required skills: Golang Desired skills: Kubernetes, containers Mentor: Luboslav Pivarc [email protected], Alice Frosi: [email protected]
How to start
- Install KubeVirt and deploy KubeVirt VMs following the getting started guide
- [Optional] Look for good-first issues and try to solve one to get familiar with the project
- Understand how is virt-handler deployed, try to deploy virt-handler in unprivileged Pod.
- Have a look at the related code and understand what code paths are required to start minimalist VM(can be VM without disks and networks).
- Think about MVP, try to refactor some needed parts
How to submit the proposal
The preferred way is to create a Google doc and share it with the mentors (slack or email work). If for any reason, Google doc doesn't work for you, please share your proposal by email. Early submissions have higher chances as they will be reviewed on multiple iterations and can be further improved.
What should the proposal contain?
The design and your strategy for solving the challenge should be concisely explained in the proposal. Which components do you anticipate touching and an example of an API /CLI are good starting points. The updates or APIs are merely a draft of what the candidate hopes to expand and change rather than being final. The details and possible issues can be discussed during the project with the mentors which can help to refine the proposal.
It is not necessary to provide an introduction to Kubernetes or KubeVirt; instead, candidates should demonstrate their familiarity with KubeVirt by describing in detail how they intend to approach the task.
Mentors may find it helpful to have a schematic drawing of the flows and examples to better grasp the solution. They will select a couple of good proposals at the end of the selection period and this will be followed by an interview with the candidate.
The proposal can have a free form or you can get inspired by the KubeVirt design proposals and template. However, it should contain a draft schedule of the project phases with some planned extra time to overcome eventual difficulties.
as this has been assigned to someone, has this project been taken already?
Hi, I am excited about the opportunity to work on the Self-sufficient Virt-handler project for GSoC 2025. I have strong experience in Go and am familiar with Kubernetes and containerization. I am eager to contribute to refactoring virt-handler to run inside an unprivileged Pod without needing virt-launcher Pods. This will significantly improve resource efficiency, and I’m excited to explore how we can minimize VM deployment for scalability testing.
I have a few questions regarding the initial setup:
1.Could you clarify any specific areas of the codebase that I should focus on first?
2.Are there any constraints or specific configurations needed when deploying virt-handler in an unprivileged Pod?
Looking forward to your feedback and guidance!
Reminder, don't forget to submit a proposal through GSoC by 8th April - 18:00 UTC.
Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close.
/lifecycle stale
