Comment 1 for bug 1799467

I I do not misdetect keywords here then virtio-gpu is based on virgl/virglrenderer which is at least blocked by a low prio (not important to anybody so far) MIR in bug 1657409.

Further on I think this is the wrong approach as the base assumption is wrong.
"Allows to administer s390x KVM guests with the tools typically used for x86 guests"

I think we all agree that s390x is not a Desktop, and the server installer is actually text only on x86 as well [2].

So far on s390 in genera l this does not work due to line mode (there are discussions about that afaik), but here this bug is about qemu guests. They can have a non line mode console, which would allow to use the normal server installer. If anything that should be evaluated to get it working as there might be rough edges.

Further people should start to adopt images, and not even more classic UI click install, but that is opinion/preference I guess.

priority/preference of install paths
1. deploy an image (uvtool, openstack, soon maas, ...)
2. use server installer (subiquity, maybe the bug can be converted to explore what would be needed to get that right on kvm guest)
... the above should be so much preferred that I wanted to separate them
3. cloning images "yourself" (the way z people did it for most of the time)
4. d-i over SSH like [1] (once for initial install where needed)
Never. Graphical UI installer of Ubuntu Desktop

@JFH - I'll let you handle if this was more for "probing of the options" or a real request - IMHO it makes no sense, if it is a real request then the MIR above needs to be prioritized to enable things in qemu on top of the kernel changes mentioned already. IMHO the potential effort on the subiquity for s390x should include that on s390x in case of non line mode it should just work as it does on x86 server install in a VM today. IMHO there really is a discussion needed, loop me in if you need me.