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

[Moving this thread over to the public mailing list]

On Mon, Dec 02, 2013 at 01:17:09AM +0100, Pino Toscano
wrote:
> 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)".
It sounds fine, as long as qemu 1.2 had "-display none".
> I will ask to the qemu people whether these behaviour differences 
> actually matter or not (at least for libguestfs).
I'd be surprised if you get an answer ...
> > > > > * -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?
TBH I don't remember.  That commit dates from early 2010, which was
about the same time that virtio-serial/virtio-console was being
written by Amit.  Possibly virtio-console just didn't work then.  If
it works, we should use it because it should be much more efficient.
16550 has a 16 byte (virtual) FIFO so the host is constantly
interrupted when the guest writes log messages.

Note that the src/conn-socket.c code could be affected for reasons
that may not be obvious.  Since libguestfs handles are synchronous,
that code only reads log messages when we're waiting to read a reply
from the daemon.  Since log messages are sent by qemu in small chunks
(because of the small emulated FIFO), log messages generally appear
before the reply message, and usually are not lost if the appliance is
killed/closes/crashes.  That's nice for debugging.  It also explains
why there is an odd 1-millisecond sleep in that code.

That might not happen if we use virtio-console that probably uses
virtio-sized (huge) buffers.
> 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)?
It sounds like a lot of work, but if you want to do it.
> > > > > * -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.
Correct.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-top is 'top' for virtual machines.  Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://people.redhat.com/~rjones/virt-top

On Monday 02 December 2013 09:09:44 Richard W.M. Jones
wrote:
> On Mon, Dec 02, 2013 at 01:17:09AM +0100, Pino Toscano wrote:
> > 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)".
> 
> It sounds fine, as long as qemu 1.2 had "-display none".
It seems like this feature was added in commit
4171d32e6eea47bf2cd160ace0ec3639e10b3aa9, which is available in
qemu >= 0.15.0.

It is not easy to check for it in qemu's --help text, as the help bits 
for -display span over multiple lines, so I guess it could be just 
switched altogether.

I tried switching it locally, and the unit tests still passed. 
(Currently using qemu 1.4.2, as shipped in f19.)
Would it be acceptable to do this change in master, to gather more 
feedback about it?

-- 
Pino Toscano

On Fri, Dec 06, 2013 at 05:26:58PM +0100, Pino Toscano
wrote:
> On Monday 02 December 2013 09:09:44 Richard W.M. Jones wrote:
> > On Mon, Dec 02, 2013 at 01:17:09AM +0100, Pino Toscano wrote:
> > > 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)".
> > 
> > It sounds fine, as long as qemu 1.2 had "-display none".
> 
> It seems like this feature was added in commit
> 4171d32e6eea47bf2cd160ace0ec3639e10b3aa9, which is available in
> qemu >= 0.15.0.
> 
> It is not easy to check for it in qemu's --help text, as the help bits 
> for -display span over multiple lines, so I guess it could be just 
> switched altogether.
> 
> I tried switching it locally, and the unit tests still passed. 
> (Currently using qemu 1.4.2, as shipped in f19.)
> Would it be acceptable to do this change in master, to gather more 
> feedback about it?
Sure.  Note that we assume qemu >= 1.2 (see README) but for some
reason are only checking for qemu >= 1.0 (see configure.ac) .. a bug!

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
libguestfs lets you edit virtual machines.  Supports shell scripting,
bindings from many languages.  http://libguestfs.org