qemu-devel
[Top][All Lists]
Advanced

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

[Qemu-devel] [RFC 00/22]: QMP: Convert savevm/loadvm/delvm


From: Luiz Capitulino
Subject: [Qemu-devel] [RFC 00/22]: QMP: Convert savevm/loadvm/delvm
Date: Tue, 20 Apr 2010 18:09:30 -0300

 Hi there,

 Libvirt has a new snapshot API which uses savevm, loadvm and delvm, so we
need to convert them to QMP.

 I thought this wouldn't be difficult, but while doing and testing this work
I hit a number of problems and had to made not so easy decisions.

 Most of the time, the problem is that the handler implementation is not
as consistent as it should be. Usually, this doesn't affect users very much
but the headache begins when you have to make this available under QMP.

 Here goes a list of macro issues/decisions. Details (and other small problems)
in the patches.

   1. Multiple failures: do_delvm() and do_savevm() report errors in a
      QTAILQ_FOREACH() loop and they don't return when an error happens.

      Although QMP will end up reporting only the first error, this is
      considered a bug because handlers are not expected to continue
      executing when an error happens.

      There are two solutions:

            1) Return right away in the first error
            2) Identify fatal errors and only report those

      I don't know the implications of doing 1) and don't know how to
      to do 2) (although do_loadvm() works this way).

      Can someone from the block layer help here?

   2. ID vs. TAG: all the three commands accept only one parameter, called
      'name'. This is automagically interpreted as either a TAG name or an
      ID number.

      QMP is machine-like, so it's boring and cold, meaning that this kind
      of automatic stuff is not good. If we want something to be an ID, we
      have to be able to say 'this must be an ID', if it can't, it should
      just fail.

      So, I considered adding new optional parameters 'tag' and 'id', but
      soon I realized that this is not as easy as it seems, as it's also
      needed to change the qcow2 driver plus refactorings..

      Markus, I'm willing to live with 'name', are you ok with that?

   3. Exposing errno macro names: several error functions print errno codes,
      while it's debatable if this is good or not, we just can't create a
      QError for every single possible error.

      So, my solution for this is to expose names instead of codes.

      For example, this error:

        "Error -5 while writing VM"

      Becomes:

        "Failed to save VM state (EIO)"

      Of course this is also available under QMP.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]