WIP: KubeVirt Graduation Application

[aburdenthehand]

KubeVirt Graduation Application

Template v1.6 (with manual updates applied to v1.5 list)

Project Repo(s): https://github.com/kubevirt/
Project Site: https://kubevirt.io
Sub-Projects: https://github.com/orgs/kubevirt/repositories?type=all
Communication: https://kubernetes.slack.com/messages/kubevirt-dev & https://kubernetes.slack.com/messages/virtualization

Project points of contacts:
Andrew Burden, aburden@redhat.com
Fabian Deutsch, fdeutsch@redhat.com
Ryan Hallisey, rhallisey@nvidia.com

Graduation Criteria Summary for KubeVirt

Application Level Assertion

• This project is currently Incubating, accepted on 2022-04-19, and applying to Graduate.

Adoption Assertion

The project has been adopted by the following organizations in a testing and integration or production capacity:

The following is a list of our end users. Please see our adopters file for a complete list.

• arm
• Aussie Broadband
• Bytedance
• Child Rescue Coalition
• Civo
• Cloudflare
• CloudRaft
• CoreWeave
• Genesis Cloud
• Intel Gaudi
• Killercoda
• The Linux Foundation - Training and Certification
• NVIDIA
• S3NS

Application Process Principles

Suggested

N/A

Required

• Engage with the domain specific TAG(s) to increase awareness through a presentation or completing a General Technical Review. #310

Completed as part of our General Technical Review, merged on 28-01-2025 in our community repo.

• TAG provides insight/recommendation of the project in the context of the landscape

• All project metadata and resources are vendor-neutral. #378

KubeVirt is dedicated to operating in the open and vendor-neutral. We follow and use CNCF policy and suggested resources in all avenues.

Project Resources:

• Homepage: https://kubevirt.io/
• Mailing list: https://groups.google.com/g/kubevirt-dev
• Calendar: https://calendar.google.com/calendar/u/0/embed?src=kubevirt@cncf.io
• Slack:
  • Developer-focussed: https://kubernetes.slack.com/messages/kubevirt-dev
  • End-user-focussed: https://kubernetes.slack.com/messages/virtualization
• Social Media:
  • Mastodon: https://fosstodon.org/@kubevirt
  • BlueSky: https://bsky.app/profile/kubevirt.bsky.social
  • Twitter: https://x.com/kubevirt
• YouTube: https://www.youtube.com/channel/UC2FH36TbZizw25pVT1P3C3g
• Meetings: All of our weekly/fortnightly meetings are via Zoom with agendas through GoogleDocs; edit rights are granted through googlegroup membership but the docs are otherwise publicly visible. All meetings are on our public calendar and everyone is welcome to join.
• Unconference: We run a pre-development cycle unconference via Zoom, using Hedgedoc pads as a collaborative notepad for topics, voting, schedule, and notes. These sessions are open to anyone; edit rights for the notepads are granted for all members of the KubeVirt GitHub org.

• Review and acknowledgement of expectations for graduated projects and requirements for moving forward through the CNCF Maturity levels.
  • Met during Project's application on DD-MMM-YYYY.

Completion of this due diligence document, resolution of concerns raised, and presented for public comment satisifies the Due Diligence Review criteria.

• Additional documentation as appropriate for project type, e.g.: installation documentation, end user documentation, reference implementation and/or code samples.

• Comprehensive documentation in our user guide that includes architecture, administrator, user, debugging, and contributing docs
• API reference documentation
• Getting started guide for developers

Governance and Maintainers

Note: this section may be augmented by the completion of a Governance Review from TAG Contributor Strategy.

Suggested

• Governance has continuously been iterated upon by the project as a result of their experience applying it, with the governance history demonstrating evolution of maturity alongside the project's maturity evolution.

In the past 15 months we have formalised our usage of SIGs and introduced KubeVirt working groups and subprojects with responsibilities and lifecycle. We have also added documentation around inactive members and expanded on our membership policy and maintainer responsibilities:

• community, wg, arch: add wg, sig subprojects and charter for S390x and ARM #298
• community, wg, template: create wg templates #301
• membership, policy: add SIG, WG and subproject roles #306
• Updating membership_policy to inc removal of reviewer/approvers/chairs #365
• Adding maintainer responsibilities, off-boarding, and emeritus governance docs #366
• sigs.yaml: Add sig-compute-virtctl subproject #374
• Improvements to community membership policy #412

Required

• Clear and discoverable project governance documentation.

Our governance doc and our membership policy are in the root of our community repo. These are also linked to from the README, and in the user guide contributing page.

• Governance is up to date with actual project activities, including any meetings, elections, leadership, or approval processes.

Our governance doc and membership policy explain the domains of the maintainers, SIGs, WGs, and Subprojects, as well as our contributor ladder to grow into a reviewer, approver, SIG/WG/Subproject Chair/Lead, and maintainer role.
SIG meetings are captured in the charters for each SIG and in our sigs.yaml file in our community repo, linked to from the governance doc.

• Governance clearly documents vendor-neutrality of project direction. #381

Ensuring the vendor neutrality of the project is one of the project maintainer responsibilities.

Neutrality and openness are also called out in our membership policy.

The enhancements process, which all SIGs are a part of, is fundamental to driving the direction of the project for current and future releases. We also run an unconference between releases during which new features and prioritization discussion can take place. The unconference is open for everyone to join.

• Document how the project makes decisions on leadership roles, contribution acceptance, requests to the CNCF, and changes to governance or project goals.

Leadership roles
Our membership policy defines the leadership roles, responsibilities, and criteria with links where applicable.

Contribution acceptance
The contribution acceptance is at the discretion of the repo approvers or SIG/WG/subproject chair/lead as described in our membership policy

CNCF requests
Any maintainer may suggest a request for CNCF resources, in the developer mailing list, the maintainer mailing list, on Github, or during a community meeting. A simple majority of maintainers approves the request. The maintainers may also choose to delegate working with the CNCF to non-maintainer community members.

Changes to governance
Most votes require a simple majority of all maintainers to succeed. Changes to Governance requires a 2/3 maintainer vote.

• Document how role, function-based members, or sub-teams are assigned, onboarded, and removed for specific teams (example: Security Response Committee).

Our membership policy defines the member and leadership roles, responsibilities, and criteria with links where applicable.

This document also covers removal through inactivity.

• Document complete list of current maintainers, including names, contact information, domain of responsibility, and affiliation. #315

Our maintainer file.
We use github handles rather than email or other contact information.

• A number of active maintainers which is appropriate to the size and scope of the project.

Our maintainer file shows 7 maintainers, all of whom have contributed to the project in the last month (according to devstats as of time of writing).

• Document a complete maintainer lifecycle process (including roles, onboarding, offboarding, and emeritus status). #311

Our governance doc documents the maintainer lifecycle, and links to our membership policy which documents other roles of responsibility in the project.

• Demonstrate usage of the maintainer lifecycle with outcomes, either through the addition or replacement of maintainers as project events have required.

In the past 12 months we have had a couple of maintainers grow into the maintainer role as well as leave the project:

Vasiliy steps down: #396
Adding Alice and Lubo: #398
Alice steps down: #406
David left project: #413

• Project maintainers from at least 2 organizations that demonstrates survivability.

Our maintainer file shows maintainers from Google, NVIDIA, and Red Hat.

• Code and Doc ownership in Github and elsewhere matches documented governance roles.

KubeVirt uses Prow to manage all organisational ownership across the repos.
Every repo then has an OWNERS_ALIASES file that determines privileges in the repos. Some of these delineate responsibility to SIGs. These files are the single source of truth for our roles across the org.

Some examples of SIG ownership:

• kubevirt/kubevirt
• kubevirt/user-guide

• Document agreement that project will adopt CNCF Code of Conduct.

The KubeVirt project abides by the CNCF code of conduct, linked to from our own Code of Conduct.

• CNCF Code of Conduct is cross-linked from other governance documents.

• Our Code of Conduct
• Membership guidelines
• Governance doc links to our Code of Conduct

• All subprojects, if any, are listed.

Our SIGs and Working Groups are listed in our community repo, which is linked to from our project governance.

• If the project has subprojects: subproject leadership, contribution, maturity status documented, including add/remove process.

Our membership policy describes responsibilities, requirements, and removal critieria for SIG, WG, and Subproject leads.

Our sig-list defines the chairs, contact, and meeting information.

Contributors and Community

Note: this section may be augmented by the completion of a Governance Review from TAG Contributor Strategy.

Suggested

• Contributor ladder with multiple roles for contributors.

Our membership policy demonstrates the different roles and requirements and expectations of these roles.

Required

• Clearly defined and discoverable process to submit issues or changes.

Our kubevirt/kubevirt repo has a contributing page that is linked to from the README and details our workflow or raising issues and PRs (including finding good-first-issues) and questions on our mailing list. It also covers testing, DCO, the PR merge/review process, and our membership policy.

We also have a contributing guide as part of our user guide which links out to these resources, including the CNCF 'Start Contributing to Open Source' page, and helps guide new contributors through the project.

• Project must have, and document, at least one public communications channel for users and/or contributors.

We have a mailing list, and two slack channels: kubevirt-dev and virtualization.
These are listed in out user guide contributing guide, our kubevirt/kubevirt contributing guide, and the kubevirt/kubevirt and kubevirt/community README.

• List and document all project communication channels, including subprojects (mail list/slack/etc.). List any non-public communications channels and what their special purpose is.

Mailing list: kubevirt-dev@googlegroups.com
Developer-oriented slack channel: https://kubernetes.slack.com/messages/kubevirt-dev
User-oriented slack channel: https://kubernetes.slack.com/messages/virtualization
Twitter: https://twitter.com/kubevirt
Mastodon: https://fosstodon.org/@kubevirt
BlueSky: https://bsky.app/profile/kubevirt.bsky.social
Youtube: https://www.youtube.com/channel/UC2FH36TbZizw25pVT1P3C3g/videos

Non-public
Maintainer list: cncf-kubevirt-maintainers@lists.cncf.io; reporting CoC violations, communication between the maintainers and the CNCF
Security list: cncf-kubevirt-security@lists.cncf.io; reporting security vulnerabilities privately

• Up-to-date public meeting schedulers and/or integration with CNCF calendar.

Our calendar is up to date and linked to from our website, user-guide, community repo and relevant SIG charters.

We are in the process of migrating to the new CNCF calendar.

• Documentation of how to contribute, with increasing detail as the project matures.

Our kubevirt/kubevirt repo has a contributing page and a getting started page, the latter of which is focussed specifically for contributing developers.

We also have a contributing guide as part of our user guide.

• Demonstrate contributor activity and recruitment.

KubeVirt is one of the Top 20 CNCF projects from July 2024-25

KubeVirt contributor devstats.

We regular attend and actively try to recruit at our stands and contribfest/hackathons at events such as KubeCon + CloudNativeCon, DevConf, FOSDEM, Flock, ContainerDays, etc. We have also mentored four projects through Google Summer of Code (2023-2025).
We foster a welcoming environment to new contributors on the mailing list, in our community and SIG meetings, and on our slack channels.

Engineering Principles

• Document project goals and objectives that illustrate the project’s differentiation in the Cloud Native landscape as well as outlines how this project fulfills an outstanding need and/or solves a problem differently. This requirement may also be satisfied by completing a General Technical Review. #340

Completed as part of our General Technical Review, merged on 28-01-2025 in our community repo.

• Document what the project does, and why it does it - including viable cloud native use cases. This requirement may also be satisfied by completing a General Technical Review.

Completed as part of our General Technical Review, merged on 28-01-2025 in our community repo.

• [Grad] Document and maintain a public roadmap or other forward looking planning document or tracking mechanism. #339

The Kubevirt roadmap documents and links to our Enhancements Tracking Board, which is used for tracking VEPs (Virtualization Enhancement Proposals) for our next release.

We also have an upcoming changes document that shows our 'pre-release notes': the release notes for our next release. It is updated daily as development progresses.

• Roadmap change process is documented.

The KubeVirt roadmap links to our enhancements repo which documents the VEP process.

• Document overview of project architecture and software design that demonstrates viable cloud native use cases, as part of the project's documentation. This requirement may also be satisfied by completing a General Technical Review and capturing the output in the project's documentation.

Completed as part of our General Technical Review, merged on 28-01-2025 in our community repo.

• Document the project's release process and guidelines publicly in a RELEASES.md or equivalent file that defines: #382

  • Release expectations (scheduled or based on feature implementation)
  • Tagging as stable, unstable, and security related releases
  • Information on branch and tag strategies
  • Branch and platform support and length of support
  • Artifacts included in the release.
  • Additional information on topics such as LTS and edge releases are optional. Release expectations are a social contract between the project and its end users and hence changes to these should be well thought out, discussed, socialized and as necessary agreed upon by project leadership before getting rolled out.

1. Release expectations: we have a public schedule in our sig-release repo. We check in with the current release schedule every week during our community meeting.
2. Tagging: Documented under our release schema and included in our release schedule.
3. Information on branch and tag strategies: These strategies are details in our release document.
4. Branch and platform support: We have a release document that details our versioning and support. We also maintain a support matrix which is linked to in our release tag notes, as well as our kubevirt and community readmes and our release notes.
5. Artifacts included in release: Listed as 'assets' for each release.

• History of regular, quality releases.

From 2017 to 2022, KubeVirt would release on a monthly cadence, with an RC approximately 10 days prior to release to ensure a tested, quality release. Since October 2022, the project moved to a tri-annual release, following in lock-step with the Kubernetes release; with this change we now have a three-week period of testing, with alpha, beta, and at least one RC prior to the release.

This history can be found on our releases page of kubevirt/kubevirt: https://github.com/kubevirt/kubevirt/releases
Our release schedules can be found on our sig-release repo: https://github.com/kubevirt/sig-release/tree/main/releases
Our release notes can be found in our user guide (and in the release tag): https://kubevirt.io/user-guide/release_notes/

Security

Note: this section may be augmented by a joint-assessment performed by TAG Security.

Suggested

• Achieving OpenSSF Best Practices silver or gold badge.

Required

• Clearly defined and discoverable process to report security issues.

Our security policy is included in our kubevirt, containerized-data-importer, user-guide, and sig-release repos. It details how to privately report a vulnerability and the required information, an alternate method for privately reporting (for when the email address cannot be used, which we experienced in 2023), how the security notices are delivered, and the involved vendor security teams

• Enforcing Access Control Rules to secure the code base against attacks (Example: two factor authentication enforcement, and/or use of ACL tools.) #337

Our membership policy requires contributors to have enabled 2FA for their account.

All commits require DCO signoff, and every PR requires at least approval from at least two people from the repo's reviewer/approver list. This is true for all repos in the project.

• Document assignment of security response roles and how reports are handled. #336

As per our security policy the team is our project maintainers.

Security notices are sent to the kubevirt-dev@googlegroups.com mailing list and published to the Security Advisories page.

The community is also investigating starting a KubeVirt security SIG but as of time of writing this has not been created.

• Document Security Self-Assessment. #335

The KubeVirt Security Self-assessment has been completed and published in the CNCF TAG-security repo.

• Third Party Security Review.

  • Moderate and low findings from the Third Party Security Review are planned/tracked for resolution as well as overall thematic findings, such as: improving project contribution guide providing a PR review guide to look for memory leaks and other vulnerabilities the project may be susceptible to by design or language choice ensuring adequate test coverage on all PRs.

The Third Part Security Review was completed in June 2025. The moderate and low issues are being tracked in a private slack channel, along with one of the security researchers. Any issue above moderate has been patched.

We will link to the audit report once it is publicly available.

• Achieve the Open Source Security Foundation (OpenSSF) Best Practices passing badge.

The project has a passing badge since 2021. It was comprehensively updated on 2024-04-12 15:48:53 UTC. The passing badge is visible on our kubevirt/kubevirt README.

Ecosystem

Suggested

N/A

Required

• Publicly documented list of adopters, which may indicate their adoption level (dev/trialing, prod, etc.)

Our adopter list is visible in our kubevirt/kubevirt repo and contains 41 adopters: https://github.com/kubevirt/kubevirt/blob/main/ADOPTERS.md

• Used in appropriate capacity by at least 3 independent + indirect/direct adopters, (these are not required to be in the publicly documented list of adopters)

Please see our adopter list

The project provided the TOC with a list of adopters for verification of use of the project at the level expected, i.e. production use for graduation, dev/test for incubation.

• TOC verification of adopters.

Refer to the Adoption portion of this document.

• Clearly documented integrations and/or compatibility with other CNCF projects as well as non-CNCF projects. #338

As per our General Technical Review, KubeVirt is compatible/integrated with the following projects:

• Kubernetes - KubeVirt extends Kubernetes by introducing custom resource definitions (CRDs) like VirtualMachine and VirtualMachineInstance. These resources integrate directly into Kubernetes workflows. Users can manage VMs using Kubernetes-native APIs.
• Prometheus - KubeVirt components expose Prometheus-compatible endpoints, Alerts, and runbooks in order to integrate well with this monitoring solution.
• Medik8s - KubeVirt community members contributed to Medik8s in order to add high-availability support for bare-metal Kubernetes clusters, supporting KubeVirt’s use case.
• ovn-kubernetes and * kube-ovn - KubeVirt contributors contributed to both projects to allow them to seamlessly integrate with KubeVirt virtual machines. Additional work is done for CNI plugins to be used with multus for better secondary network support.
• Istio - KubeVirt contributors provided patches to Istio in order to integrate KubeVirt VMs out of the box with Istio.
• ArgoCD - KubeVirt contributors provided patches to Argo in order to align with common Argo practices.
• Tekton - KubeVirt maintains a set of Tekton tasks in order to easily build Tekton Pipelines around VMs.
• Velero - KubeVirt contributors integrate Velero into KubeVirt in order to support third-party backup vendors.
• cluster-api-provider-kubevirt - Cluster API KubeVirt is built on KubeVirt.
• Kubernetes descheduler - KubeVirt community members contributed several changes to the Kubernetes descheduler in order to let the descheduler work seamlessly with VMs as well.
• kubernetes-nmstate - KubeVirt community members contributed to kubernetes-nmstate to provide a declarative approach for host network configuration—a common problem in bare-metal clusters.
• multus - KubeVirt leverages Multus APIs in order to implement secondary networks for VMs.

Adoption

Adopter 1 - $COMPANY/$INDUSTRY

If the Adopting organization needs to remain anonymous, stating the industry vertical is sufficient.
MONTH YEAR

Adopter 2 - $COMPANY/$INDUSTRY

If the Adopting organization needs to remain anonymous, stating the industry vertical is sufficient.
MONTH YEAR

Adopter 3 - $COMPANY/$INDUSTRY

If the Adopting organization needs to remain anonymous, stating the industry vertical is sufficient.
MONTH YEAR

[iholder101]

/cc

@aburdenthehand let mw know if I can help push this forward

[lbocinco]

@aburdenthehand Few minor notes while proofreading this:

• Adoption Assertion - missing link to the adopters file (I don't know why this is required as there is a whole section on Adoption, but better to add it there).
• Demonstrate contributor activity and recruitment - Add there a link to kubevirt devstats, so they don't need to search for it :)

Other than that, it looks like it'll be soon ready to go.

[kubevirt-bot]

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

[fabiand]

/remove-lifecycle stale

…

On Mon, Nov 10, 2025 at 11:52 AM kubevirt-bot ***@***.***> wrote: *kubevirt-bot* left a comment (kubevirt/community#307) <#307 (comment)> 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 — Reply to this email directly, view it on GitHub <#307 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAUMADXD5HP74IYPFAS3OT34BU7JAVCNFSM6AAAAACDT76XB6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTKMJQHAZTANBVGI> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[kubevirt-bot]

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

[vladikr]

/remove-lifecycle stale