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...
