On 10/8/20 4:54 AM, Steven Newbury wrote:
On Wed, 2020-10-07 at 21:45 -0400, Laine Stump wrote:
It is *definitely* less hacky to use <qemu:commandline> than to carry your own local patch on top of the libvirt source, which would force you to always build your own libvirt binaries, and rebase your patch every time upstream libvirt changed code that touched the same place. Although <qemu:commandline> isn't "Supported" (Capital "S" - in the sense that a vendor providing paid technical support for a system using libvirt won't officially commit themselves to solving any problem you may have associated with use of <qemu:commandline>, and the options you provide there *could* disappear from qemu), it is "supported" (small "s" - in the sense that libvirt has no plans to remove <qemu:commandline>, and it is used by other people so if it becomes broken it will surely get fixed).
Using <qemu:commandline> will take 10 minutes of your time right now, and then you'll never have to think about it ever again (until/unless QEMU removes the x-vga option). Using your own custom build of libvirt that carries a locally written patch will continue to be a burden every time you upgrade libvirt until the end of time.
Thanks for the detailed instructions, I had missed the alias part before, I don't know if that was where I was going wrong?
Nah, that would just lead to an error when you started the guest.
The <qemu::commandline> part would just disappear when I hit apply.
The most likely reason for that would be a) if you left out step (1), or b) if you put <qemu:commandline> after </domain>, or maybe put it inside some other element (e.g. <devices>).
The original patch only took me 10mins at most, yeah it shows, but worked straight away. I've been running Gentoo unstable for the last 20 years, patch rebasing isn't really a problem! :-) I'm very used to creating patches for new features and bug fixes as I need to, it's part of my usual update process. I must have written thousands over the years. I've been trying to make a bit of effort to get some pushed upstream, rather than having them sit in an overlay or "portage/patches".
It is taking some time and effort to get the validation working, but I don't think it's a waste of time. I'm getting better familarised with the code which isn't a bad thing, and might allow me to make more appropriate contributions in the future.
Now *that* is a worthwhile reason! :-)
Maybe I'll try fixing the "isapc" machine type?! ;-)
Hmm. Trying to think of why you would need that (other than just the standard "because it's there"), and coming up empty. I *think* even MSDOS will boot on an i440fx guest...