KVM: default x86 guests to vga video model when none is configured - #13807
KVM: default x86 guests to vga video model when none is configured#13807andrijapanicsb wants to merge 1 commit into
Conversation
Without an explicit video model (vm.video.hardware agent property or video.hardware VM detail), CloudStack emits no <video> element and libvirt defaults x86 guests to cirrus, which is deprecated in QEMU and renders a blank console on Windows Server 2025 Core guests. Default unconfigured x86 guests to vga with 32 MiB of VRAM instead. Explicit VM details and agent properties keep precedence; non-x86 guests (aarch64, s390x) are unchanged. Fixes apache#13806
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #13807 +/- ##
=========================================
Coverage 19.65% 19.65%
- Complexity 19792 19795 +3
=========================================
Files 6368 6368
Lines 574881 574889 +8
Branches 70351 70354 +3
=========================================
+ Hits 112970 112972 +2
- Misses 449639 449647 +8
+ Partials 12272 12270 -2
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
|
My good friend.... @blueorangutan package kvm |
|
@andrijapanicsb a [SL] Jenkins job has been kicked to build packages. It will be bundled with kvm SystemVM template(s). I'll keep you posted as I make progress. |
|
Packaging result [SF]: ✔️ el8 ✔️ el9 ✔️ el10 ✔️ debian ✔️ suse15. SL-JID 18778 |
|
@blueorangutan test rocky9 kvm-rocky9 |
|
@andrijapanicsb a [SL] Trillian-Jenkins test job (rocky9 mgmt + kvm-rocky9) has been kicked to run smoke tests |
2 participants
Fixes #13806
Description
On KVM, CloudStack emits no
<video>element unless the agent propertyvm.video.hardwareor the VM settingvideo.hardwareis set. libvirt then defaultsx86 guests to
cirrus, which has been deprecated in QEMU for years (EL9 qemu-kvmalready prints a deprecation warning) and renders a completely blank console on
Windows Server 2025 Core — input and qemu-guest-agent keep working, but the display
shows nothing. Verified A/B on the same VM:
cirrus= blank LogonUI,vga= renderscorrectly (details and repro in #13806).
With this PR, when no video model is explicitly configured (no agent property, no VM
detail), the KVM agent emits
<model type='vga' vram='32768'/>(32 MiB) for x86guests. Precedence is unchanged: VM detail
video.hardware/video.ram> agentproperty
vm.video.hardware/vm.video.ram> this default. The new default takeseffect on the next VM stop/start; running VMs are not modified.
Why only x86 — why not aarch64/s390x as well?
Both halves of the argument flip on non-x86 architectures:
x86-specific legacy default. On aarch64
virtmachines there is no cirrus at all —libvirt/QEMU pick appropriate devices, so unconfigured aarch64 guests are not
broken today. Same for s390x (virtio-gpu-ccw).
vgais the wrong device there. Std VGA is legacy x86 hardware — VGA I/Oports, VGA BIOS text mode. The aarch64
virtmachine has no legacy I/O, so VGA canonly be exposed as a bare PCIe framebuffer; guest support for that is spotty
(edk2 can drive it, guest kernels vary, and Windows-on-ARM has no std VGA driver at
all). The native display devices on aarch64 are
virtio-gpuandramfb.Unconditionally injecting
<model type='vga'/>on non-x86 would therefore changebehavior where nothing is broken, possibly to a device the guest cannot drive — the
opposite of what this PR does on x86. If aarch64 display defaults ever need
attention, the right fix is a separate
virtio-gpu/ramfbdefault. The arch checkfollows the existing pattern in
LibvirtComputingResource: theguest.cpu.archagent property first, the VM's arch as fallback, null treated as x86 (same assumption
createGuestFromSpecmakes).Is there any x86 guest OS still potentially in use today that fails on vga?
We could not identify a single one. QEMU itself switched its own default video
adapter from cirrus to std VGA back in QEMU 2.2 (December 2014), so every plain QEMU
invocation for the last decade has used it. In particular:
is plain VGA text mode; X falls back to the
vesadriver, which drives std VGA'sVBE modes fine.
after the XP/2003 era, so on cirrus these guests already run the Basic Display
driver in dumb-VGA mode — cirrus offers them nothing over std VGA, and per this
report is now actively worse.
they had accelerated cirrus drivers and drop to unaccelerated 640x480 on std VGA.
They still boot and still display.
So the risk of this default change is next to zero, though functional testing with a
couple of different guest OSes is of course advised. On the flip side, staying on
cirrus is a time bomb: it is deprecated in QEMU, EL9 warns about it, and once EL10/11
builds drop the device, every unconfigured guest would fail outright.
Types of changes
Feature/Enhancement Scale or Bugfix Severity
How Has This Been Tested?
LibvirtComputingResourceTest:vga/32768vga/32768<video>element (unchanged)vm.video.hardwareset): restarting a VM without avideo.hardwaredetail now produces<model type='vga' vram='32768'/>invirsh dumpxml; Windows Server 2025 Core console renders correctly instead ofstaying blank.