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
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature