design-proposal: VM video device type configuration #371

dasionov · 2024-12-26T16:59:12Z

What this PR does / why we need it:
This PR introduces a design proposal to discuss about the optimal implementation for introducing a dedicated field for a video device to be used.

We want to allow VM-owners to explicitly set the video device type when needed.

Fixes #

Special notes for your reviewer:

Checklist

This checklist is not enforcing, but it's a reminder of items that could be relevant to every PR.
Approvers are expected to review this list.

Design: A design document was considered and is present (link) or not required
PR: The PR description is expressive enough and will help future contributors
Code: Write code that humans can understand and Keep it simple
Refactor: You have left the code cleaner than you found it (Boy Scout Rule)
Upgrade: Impact of this change on upgrade flows was considered and addressed if required
Testing: New code requires new unit tests. New features and bug fixes require at least on e2e test
Documentation: A user-guide update was considered and is present (link) or not required. You want a user-guide update if it's a user facing feature / API change.
Community: Announcement to kubevirt-dev was considered

Release note:

None

dasionov · 2024-12-26T16:59:50Z

/cc @enp0s3

design-proposals/toggle_vga_video_device.md

iholder101

Thanks @dasionov!

design-proposals/toggle_vga_video_device.md

iholder101 · 2024-12-29T14:01:14Z

design-proposals/toggle_vga_video_device.md

+### Option 1: Annotation-Based Toggle
+**Description:** Introduce an annotation on the KubeVirt CR to specify the default video device type. The annotation kubevirt.io/default-video-device: vga can be used to default all VMs to VGA unless overridden in individual VMIs.
+
+**Pros:**
+
+- Minimal changes to the API schema.
+- Easy to implement and maintain.


TBH I don't understand these pros.

Such an annotation would demand backward compatibility anyhow, and it's not much easier to implement AFAICT. To me it's equivalent to adding a non-visible field.

iholder101 · 2024-12-29T14:05:54Z

design-proposals/toggle_vga_video_device.md

+The proposed changes have no anticipated impact on scalability capabilities of the KubeVirt framework
+
+## Update/Rollback Compatibility
+cluster admins and vm-owners that have old vms that supports only vga video device.


Can VMs change video type between reboots / live-migrations? Will it break the guest?

AFAIK as long as the domain capabilities supports virtio as video type, switching between vga to virtio should not break the guest at all, (e.g in upgrade scenario)
unless of course the launcher image doesn't have the qemu-kvm-device-display-virtio-gpu (which provide support for virtio) installed, in that case the guest will break immediately at the first sync.

design-proposals/vm_video_device_type_field.md

iholder101

Thank you @dasionov! Looks good in general

A bit off topic, but I think this PR raises an interesting question around defaults. Do we want to generally default to the most-compatible option, or the most optimized one? In any case, I think that in some point in the future we'd need to consider defaulting to virtio as I think it makes sense to do so when supported on vast majority of guests.

design-proposals/vm_video_device_type_field.md

iholder101 · 2025-01-05T10:00:39Z

design-proposals/vm_video_device_type_field.md

+
+**Cons:**
+- API Complexity: Requires schema changes to the VM template API, introducing additional fields that need maintenance and testing.
+- Administrative Effort: Per-VM configuration may lead to higher administrative overhead if many VMs require toggling.


BTW, perhaps this con can be addressed with instance types & preferences
FYI @lyarwood

iholder101 · 2025-01-05T10:08:48Z

design-proposals/vm_video_device_type_field.md

+          video:
+            type: virtio


Libvirt supports multiple video devices [1]:

<devices> <video> <model type='vga'/> </video> <video> <model type='virtio'/> </video> </devices>

They also have the "primary" field to indicate which is the primary volume.
Since that's the case, I think we want to turn the video field to a slice, and perhaps add the primary field. In libvirt, if the primary field is not supplied, than the first video device is set as the primary, perhaps we can follow this approach.

kubevirt-bot · 2025-01-05T12:51:55Z

New changes are detected. LGTM label has been removed.

kubevirt-bot · 2025-01-05T12:51:58Z

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
Once this PR has been reviewed and has the lgtm label, please ask for approval from jean-edouard. For more information see the Kubernetes Code Review Process.

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

xpivarc

Kubevirt doesn't strive to provide any/every option available (be it by qemu/libvirt...) and rather we have sidecars that allows you to do what we don't make explicitly available. I am not convinced we should support this unless good use cases are provided and available alternative (sidecars) shows major negatives compare to have this in core.

xpivarc · 2025-01-07T08:06:44Z

design-proposals/vm_video_device_type_field.md

+VM-owners who require specific configurations for VMIs in their environments.
+
+## User Stories
+- As a VM owner, I want to be able to set a better video device like `virtio` instead of the standard `vga`.


This is not really an use case imho. There should be why one needs virtio or anything other than vga/bosh(partial compatibility of vga)

design-proposals/vm_video_device_type_field.md

xpivarc · 2025-01-07T08:12:45Z

design-proposals/vm_video_device_type_field.md

+```
+
+## Scalability
+The proposed changes have no anticipated impact on the scalability capabilities of the KubeVirt framework.


Overhead of the virt-launcher(or rather qemu I should say) may be impacted.

FWIW I would guess the using virtio would demand less memory if anything. But this is just an educated guess :)

design-proposals/vm_video_device_type_field.md

iholder101 · 2025-01-07T16:14:19Z

Kubevirt doesn't strive to provide any/every option available (be it by qemu/libvirt...) and rather we have sidecars that allows you to do what we don't make explicitly available. I am not convinced we should support this unless good use cases are provided and available alternative (sidecars) shows major negatives compare to have this in core.

Sidecars are problematic in many ways. They're alpha, not really supported, hard to use and do not fit production use-cases. As most virtio drivers, I'd guess that also in this case the virtio driver would be faster, consume less memory and would fit better to virtualized workloads in most cases.

On the other hand, I agree this proposal lacks the use-cases and research necessary to back up these assumptions.
@dasionov can you please try to find more use-cases or data that shows if and how virtio is better? I vaguely remember you mentioned something about being able to achieve better video resolutions with virtio, this sounds like a good start to me.

xpivarc · 2025-01-10T11:10:14Z

Kubevirt doesn't strive to provide any/every option available (be it by qemu/libvirt...) and rather we have sidecars that allows you to do what we don't make explicitly available. I am not convinced we should support this unless good use cases are provided and available alternative (sidecars) shows major negatives compare to have this in core.

Sidecars are problematic in many ways. They're alpha, not really supported, hard to use and do not fit production use-cases. As most virtio drivers, I'd guess that also in this case the virtio driver would be faster, consume less memory and would fit better to virtualized workloads in most cases.

About the side-cars, I would you say you just point out that we should work towards graduation of it and improving it. For the virtio, well it is The virtualization "hw" so it better be better than emulating whatever ;)

On the other hand, I agree this proposal lacks the use-cases and research necessary to back up these assumptions. @dasionov can you please try to find more use-cases or data that shows if and how virtio is better? I vaguely remember you mentioned something about being able to achieve better video resolutions with virtio, this sounds like a good start to me.

We want to allow VM-owners to explicitly set the video device type when needed. Signed-off-by: Daniel Sionov <[email protected]>

kubevirt-bot requested a review from aburdenthehand December 26, 2024 16:59

kubevirt-bot added the dco-signoff: yes Indicates the PR's author has DCO signed all their commits. label Dec 26, 2024

kubevirt-bot requested a review from dhiller December 26, 2024 16:59

kubevirt-bot added the size/M label Dec 26, 2024

dasionov changed the title ~~design-proposal: toggle_vga_video_device~~ design-proposal: toggle default vga video device Dec 26, 2024

kubevirt-bot requested a review from enp0s3 December 26, 2024 16:59

dankenigsberg reviewed Dec 27, 2024

View reviewed changes

design-proposals/toggle_vga_video_device.md Outdated Show resolved Hide resolved

iholder101 reviewed Dec 29, 2024

View reviewed changes

dasionov force-pushed the toggle_vga_video_device_design_proposal branch from 8e566ba to 0ce94dd Compare December 29, 2024 16:16

kubevirt-bot added size/L and removed size/M labels Dec 29, 2024

dasionov force-pushed the toggle_vga_video_device_design_proposal branch from 0ce94dd to 7928683 Compare December 30, 2024 14:08

kubevirt-bot added size/M and removed size/L labels Dec 30, 2024

dasionov changed the title ~~design-proposal: toggle default vga video device~~ design-proposal: VM video device type configuration Dec 30, 2024

jean-edouard reviewed Jan 2, 2025

View reviewed changes

design-proposals/vm_video_device_type_field.md Outdated Show resolved Hide resolved

design-proposals/vm_video_device_type_field.md Outdated Show resolved Hide resolved

dasionov force-pushed the toggle_vga_video_device_design_proposal branch 3 times, most recently from 0596398 to f51aee9 Compare January 2, 2025 16:37

jean-edouard approved these changes Jan 2, 2025

View reviewed changes

kubevirt-bot assigned jean-edouard Jan 2, 2025

kubevirt-bot added the lgtm Indicates that a PR is ready to be merged. label Jan 2, 2025

iholder101 reviewed Jan 5, 2025

View reviewed changes

dasionov force-pushed the toggle_vga_video_device_design_proposal branch from f51aee9 to 452d86c Compare January 5, 2025 12:51

kubevirt-bot removed the lgtm Indicates that a PR is ready to be merged. label Jan 5, 2025

xpivarc reviewed Jan 7, 2025

View reviewed changes

dasionov force-pushed the toggle_vga_video_device_design_proposal branch from 452d86c to ba747c0 Compare January 8, 2025 11:51

design-proposal: vm_video_device_type_field.md

f5bcbcd

We want to allow VM-owners to explicitly set the video device type when needed. Signed-off-by: Daniel Sionov <[email protected]>

dasionov force-pushed the toggle_vga_video_device_design_proposal branch from ba747c0 to f5bcbcd Compare January 12, 2025 13:20

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

design-proposal: VM video device type configuration #371

design-proposal: VM video device type configuration #371

dasionov commented Dec 26, 2024 •

edited

Loading

dasionov commented Dec 26, 2024

iholder101 left a comment

iholder101 Dec 29, 2024

iholder101 Dec 29, 2024

dasionov Dec 29, 2024

iholder101 left a comment

iholder101 Jan 5, 2025

iholder101 Jan 5, 2025

kubevirt-bot commented Jan 5, 2025

kubevirt-bot commented Jan 5, 2025

xpivarc left a comment

xpivarc Jan 7, 2025

xpivarc Jan 7, 2025

iholder101 Jan 7, 2025

iholder101 commented Jan 7, 2025

xpivarc commented Jan 10, 2025

design-proposal: VM video device type configuration #371

Are you sure you want to change the base?

design-proposal: VM video device type configuration #371

Conversation

dasionov commented Dec 26, 2024 • edited Loading

dasionov commented Dec 26, 2024

iholder101 left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

iholder101 left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

kubevirt-bot commented Jan 5, 2025

kubevirt-bot commented Jan 5, 2025

xpivarc left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

iholder101 commented Jan 7, 2025

xpivarc commented Jan 10, 2025

dasionov commented Dec 26, 2024 •

edited

Loading