On Tue, Dec 11, 2007 at 08:51:32AM -0600, Anthony Liguori wrote: > Dor Laor wrote: > >Laurent Vivier wrote: > >>Le mardi 11 décembre 2007 à 10:10 +0100, Fabrice Bellard a écrit : > >> > >>>Hi, > >>> > >> > >>Hi, > >> > >> > >>>At this point I am not interested in integrating it into QEMU as it is > >>>one more API level to maintain in addition to the command line monitor. > >>>However, I can change my mind if several projects insists to have a > >>>similar interface. > >>> > >> > >>perhaps the DBUS interface can replace the command line monitor ? > >>We have just to move the command line interface to a client speaking to > >>qemu through the DBUS interface. > >> > >> > >This is a valid option but the problem is that local user will have to > >use another tool (client) to > >send commands. Another option is to have a common backend with machine > >& user interfaces. > >For example, if we use dbus as the backend, monitor commands will just > >be translated into dbus. > >The opposite option is also valid. > > > >Anyway, the motivation behind a new interface is that the monitor > >interface is not good enough for automation: > >There are not return status for commands, no option for async > >notifications, no option for parallel actions in case > >a command takes long time to complete (like snapshot). > > All of these are valid, and addressable. Return statuses can just be > added to the beginning of the output of each command (similar to how > POP3 works). Async notification can be made to work by add support to > the monitor for a "select" command. Semantically, select would block > the monitor and then output events. For this to work really well, you > would have to support multiple simultaneous monitor sessions. The > parallel options for long running commands is already address in KVM > with the migration command. We just have to rework the snapshotting to > be properly asynchronous. > > > > >So we either a new interface is added or the existing one will be > >enhanced. > >Since Qemu/KVM will be used in production its highly important to have > >a reliable channel to connects with mgmt daemons. > >Dbus is a common practice for communication and used in Linux, > >libvirt, etc. The question is whether to add a dbus server to Qemu or > >a client is sufficient. > > The main objection I have to dbus is that it's very heavy weight. It > implies a rather fat infrastructure and it not very suitable for > embedding. QEMU has very few dependencies and that is a strength ATM. > People interested in embedding QEMU still want a good management > interface so enhancing the monitor seems more preferable to me than > adding a dbus dependency.
It is also not so easily portable to other OS like Windows & Mac OS, who will still be lacking a decent control API. As I mentioned in my other thread, embedding a DBus in each individual QEMU process is not the right way to write DBus services either. If you want DBus (which is questionable in itself), then you want to have a single service which manages all a QEMU VMs. This mandates that the DBus service be outside the context of the QEMU process itself. Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|