libvirt: Add opt-in --graphical-console flag for SPICE display

[jeckersb]

Add a --graphical-console flag to 'bcvk libvirt run' that enables a
SPICE graphics console for virt-manager access. When enabled, the domain
XML includes a SPICE display with autoport, a virtio GPU, and a spicevmc
channel for clipboard and display resize support.

The flag also adds console=tty1 as a kernel argument so the guest kernel
outputs to the graphical console.

This also removes unused VNC support code.

Assisted-by: OpenCode (claude-opus-4-6)
Signed-off-by: John Eckersberg jeckersb@redhat.com

[jeckersb]

Just throwing this up for discussion. Any reason to not do this? This makes debugging and connecting to the spawned VM a lot more convenient from virt-manager, combined with setting systemd.debug_shell=tty1 in the kargs so it dumps into a root shell.

[gemini-code-assist]

Code Review

This pull request introduces SPICE graphics console support for libvirt domains, enhancing debugging capabilities with "virt-manager". However, it presents critical issues: the SPICE console is enabled by default, creating an unauthenticated port on the local interface that poses a security risk in multi-user environments. Furthermore, the "XmlWriter" utility is vulnerable to XML injection due to a lack of input escaping for user-supplied data. A significant code issue also arises as the current implementation can lead to invalid domain XML if both VNC and SPICE consoles are configured, as libvirt only allows one "

[gemini-code-assist]

This section enables the SPICE graphics console by default, listening on "127.0.0.1" without authentication. This creates a security vulnerability where local users in multi-user environments could gain unauthorized access to the VM console. It is highly recommended to make this feature optional or implement authentication. Furthermore, this unconditional addition of a SPICE "

Suggested change

	// SPICE graphics for virt-manager access
	// Always enable SPICE with auto-port allocation for easy debugging via virt-manager
	writer.start_element("graphics", &[("type", "spice"), ("autoport", "yes")])?;
	writer.write_empty_element("listen", &[("type", "address"), ("address", "127.0.0.1")])?;
	writer.end_element("graphics")?;
	writer.start_element("video", &[])?;
	writer.write_empty_element("model", &[("type", "virtio")])?;
	writer.end_element("video")?;
	if self.vnc_port.is_none() {
	// SPICE graphics for virt-manager access
	// Always enable SPICE with auto-port allocation for easy debugging via virt-manager
	writer.start_element("graphics", &[("type", "spice"), ("autoport", "yes")])?;
	writer.write_empty_element("listen", &[("type", "address"), ("address", "127.0.0.1")])?;
	writer.end_element("graphics")?;
	writer.start_element("video", &[])?;
	writer.write_empty_element("model", &[("type", "virtio")])?;
	writer.end_element("video")?;
	}

[jeckersb]

Changed to draft because (1) missing the Assisted-by annotation, (2) I don't think this matches how spice is typically setup (thanks gemini). But the overall point still stands.

[cgwalters]

Ultimately - and this would be a big lift, but it would make sense to match a lot of what virt-install offers/exposes.

[cgwalters]

combined with setting systemd.debug_shell=tty1 in the kargs so it dumps into a root shell.

In the immediate term what I think would be a big win and I'd been meaning to do is default to console=hvc0 in the base image; it pairs with 84a8153

[jeckersb]

Ok I took one more quick pass at this while trying to clean up old things in my "TODO" pile of tabs, remotivated by @travier in #237. This looks sane to me in local testing.