andrijapanicsb opened a new pull request, #13807:
URL: https://github.com/apache/cloudstack/pull/13807
Fixes #13806
### Description
On KVM, CloudStack emits no `<video>` element unless the agent property
`vm.video.hardware` or the VM setting `video.hardware` is set. libvirt then
defaults
x86 guests to `cirrus`, which has been deprecated in QEMU for years (EL9
qemu-kvm
already 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`
= renders
correctly (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
x86
guests. Precedence is unchanged: VM detail `video.hardware`/`video.ram` >
agent
property `vm.video.hardware`/`vm.video.ram` > this default. The new default
takes
effect 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:
1. **The bug cannot happen there.** The cirrus injection this PR fixes is
libvirt's
x86-specific legacy default. On aarch64 `virt` machines 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).
2. **`vga` is the wrong device there.** Std VGA is legacy x86 hardware —
VGA I/O
ports, VGA BIOS text mode. The aarch64 `virt` machine has no legacy I/O,
so VGA can
only 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-gpu` and `ramfb`.
Unconditionally injecting `<model type='vga'/>` on non-x86 would therefore
change
behavior 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`/`ramfb` default. The
arch check
follows the existing pattern in `LibvirtComputingResource`: the
`guest.cpu.arch`
agent property first, the VM's arch as fallback, null treated as x86 (same
assumption
`createGuestFromSpec` makes).
### 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:
- **CentOS 5 / Ubuntu 12.04** (oldest Linux realistically still around):
text console
is plain VGA text mode; X falls back to the `vesa` driver, which drives
std VGA's
VBE modes fine.
- **Windows Server 2003**: ships a standard VGA/VBE-capable driver; works.
- **Windows Server 2008 and newer**: Microsoft removed the cirrus driver
entirely
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.
- **Museum pieces** (Windows 3.x/9x/NT4, OS/2): the only class that loses
anything —
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
- [x] Bugfix
### Feature/Enhancement Scale or Bugfix Severity
- [x] Severity: Major (blank console on Windows Server 2025 Core guests)
### How Has This Been Tested?
- New unit tests in `LibvirtComputingResourceTest`:
- x86 guest (Linux os type), nothing configured → `vga`/32768
- x86 guest (Windows os type), nothing configured → `vga`/32768
- Explicit VM detail → detail wins
- Agent property set → property wins
- aarch64 guest, nothing configured → no `<video>` element (unchanged)
- Lab (EL9 KVM host, no `vm.video.hardware` set): restarting a VM without a
`video.hardware` detail now produces `<model type='vga' vram='32768'/>` in
`virsh dumpxml`; Windows Server 2025 Core console renders correctly
instead of
staying blank.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
