Shuveb Hussain wrote:
>
> Daemon though? Can't the libvirt code just invoke the OpenVZ commands
> directly?
Yeah, that is very much possible. But if it were a daemon, it could be
a Python daemon, since text processing is much simpler and I don't
have to use the str*( ) funcs in C. What is your comment?
I'm a big advocate of using a sane language instead of C, but libvirt is
written in C for better or worse.
The problem with a separate daemon is management of that daemon.
Something needs to start it and stop it, it needs to have sockets with
the right permissions and so on. What happens if the process runs and
can't find the daemon? What is the path to the socket? etc. etc. At
the moment we have two daemons - the qemu daemon (which has two separate
functions intertwined), and a remote daemon (necessary, because there's
no other way to communicate to a remote machine).
One idea would be to have the Python code fork off from the main program
and communicate over a pipe. With this, there is no daemon management
problem.
+----------------+
| Program |
| - - - - - - - -|
| libvirt |
+----------------+
|
| fork(2) and pipe(2)
|
+-------------+
| Python code |
+-------------+
But I'm not the person who ultimately decides what would be acceptable
in libvirt. You'd need to get general agreement on the best way to do this.
Rich.
--
Emerging Technologies, Red Hat -
http://et.redhat.com/~rjones/
Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod
Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in
England and Wales under Company Registration No. 03798903