[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [Libvir] PATCH: Check for /usr/bin/qemu* binaries before starting guest

Daniel P. Berrange wrote:
The attached patch fixes two issues

 - It explicitly checks to see if the requested /usr/bin/qemu* binary
   actually exists before fork()/exec()'ing it. While its technically
   possible to catch the execve() failure of ENOENT, its a real pain to
   feed this error back to the qemu daemon because we're in a sub-process
   at that point. The obvious & easy solution is to thus check to see if
   the binary exists before trying to fork.

This is quite a hard problem to fix properly, as I'm sure you know.

If we were to change to use execvp, so making libvirt less dependent on the precise location of qemu binaries[1] then a complete test would also need to parse $PATH.

With SELinux an exec can fail for a lot more reasons than just lack of the binary or lack of execute bit.

And additionally, just because we manage to execvp the qemu-* binary, that doesn't mean that it initialises fully. In Real Life rpm ensures that we can't install libvirt without having qemu, so qemu initialisation failures are likely to be far more common than cannot-exec-qemu failures.

Olwm (the old OpenLook window manager) solved both problems in this way. From the olwm man page[2]:

     -syncpid process-id
          When olwm has completed  its  initialization,  it  will
          send  a  signal (SIGALRM by default) to process-id. The
          signal will be sent only if  this  option  is  present.
          This  is  useful  for  running  olwm from shell scripts
          (such as .xinitrc) in such a way that the script  waits
          for  olwm  to  finish its initialization, while leaving
          olwm as a child process of the shell script.  This  can
          be done using the following sh(1) construct:

               sleep 15 & pid=$!
               olwm -syncpid $pid &
               wait $pid

     -syncsignal signal
          Specifies the signal to send instead of  SIGALRM.   The
          signal is specified as a number, not symbolically.

(In the shell-script example shown there is no way to catch errors, but you can easily extend this by sending SIGALRM to the parent -- indicating correct exec + initialisation -- or timing out).

OK, so this requires an upstream patch to qemu. Worth getting this in now with the view that a few years down the line it'll be useful?

In the present, qemu has two features which seem to allow us to detect partial or full initialisation.

The -daemonize flag in qemu explicitly allows you to do this. They use a pipe from the child back to the parent which sends a signal back to the parent after full initialisation has happened. Unfortunately this means that qemu is not only not a child of libvirt, but also we no longer have access to stdin/stdout (ie. console). We would need to make another (good) change to allow qemu to write console sockets into a well-known directory using qemu -monitor unix:/var/...

The -pidfile flag is a more immediate, partial solution. The pidfile is written part way through initialisation -- the qemu process has been exec'd and has done some work, and then works its way through the command line arguments until it reaches this one, whereupon it creates the file immediately. After parsing command line arguments, some further initialisation is done, so this is not a full solution.

What do people think?  Worth me working on fixing this problem properly?


[1] It's arguable whether we should do that, or rely on configure-time detection of the binaries. Perhaps configure-time configuration is more secure.

[2] http://www.umanitoba.ca/cgi-bin/man.cgi?section=1&topic=olwm

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]