[Libguestfs] Use of qemu-kvm command line arguments in libguestfs (was: Re: Fwd: ...)

On Friday 29 November 2013 18:53:38 you wrote: > > > I'm marking options with NONE (not used at all), or M (used in > > > master) and/or RH7 (used in rhel-7.0). > > > > > > > * -nographic > > > > > > M + RH7 > > > I guess that could be changed into (roughly) > > > > > > if (qemu_supports (g, data, "-display")) > > > { ADD_CMDLINE ("-display"); ADD_CMDLINE ("none"); } > > > else > > > > > > ADD_CMDLINE ("-nographic"); > > > > Yup, something like that should work. Did you have a look at the > > qemu code to find out what other side-effects -nographic has? Are > > they important side-effects? It seems most of the effects are related to the default devices (serial, parallel, vrtcon, etc) that are added; OTOH, we always use -nodefaults so those are not added, so at least there should be no difference from this p.o.v. The other changes related to the use of nographics are in few target- related places: - in lm32 hardware (milkymist-tmu2), no display device is created when the display type is "nographics" (but it is when the type is "none"? hmm..) - in nvram support, the FW_CFG_NOGRAPHIC bit is set to 1 if the display is "nographics", while 0 otherwise - in sparc (not sparc64 though, it seems), the ESCC serial device is created disabled if the display type is "nographics", while enabled otherwise I'm not totally sure about these architecture-specific bits, but at least from a quick glance it could be relatively safe to make "-display none" preferred over -nographics, at it seems more like "device graphics is enabled (as if it was SDL, curses, etc), just with no output at all)".

I will ask to the qemu people whether these behaviour differences actually matter or not (at least for libguestfs).

> > > > * -serial > > > > > > M + RH7, "-serial stdio" > > > > We could think about using virtio-console instead of -serial. > > Virtio-console would be faster and have lower overhead than > > continuing to use the 16550 serial port emulation. This would be > > something to do upstream first, get it right, fix the bugs, then > > add it to RHEL 7.x later. > > Yes, I saw the commented code for it, but I did not have the time to > investigate it yet. I see you added it (as commented code) in 866ec00d, but no indication why it was not actually used (other than a comment hinting about not working it yet). Do you have any pointers about it already?

This poses me another question: should we review all the qemu command line options and unconditionally drop the support for qemu < 1.2, or touch them just like in cases like this one (i.e. when some of them is mentioned/superseded/etc)?

> > > > * -nodefconfig > > > > > > M + RH7, if available > > > > qemu has a load of unhelpful built-in devices. This avoids using > > them, so it's a good thing from our p.o.v. Ah, I guess you are confusing this with -nodefaults (which we pass if available): -nodefconfig this just disables the loading of qemu.conf/qemu-$target.conf configuration files.