[Libvir] [RFC]OpenVZ XML def

Shuveb Hussain shuveb at gmail.com
Thu Jul 5 06:58:40 UTC 2007


Hello,

> >> 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.
>

The OpenVZ utils code, as I previously mentioned is GPL and a bigger
issue is that the code is simple and straight forward. So, even if I
wanted to add OpenVZ support into Libvirt, it ends up looking very
close to the original GPL code. If the other Libvirt maintainers don't
have an issue with what Richard is suggesting, then I can go ahead and
do it. I have the freedom to work on this full time now. I can either
write a Python helper(since I have to deal with a lot of text), or
write C code that will be well integrated into Libvirt. Either way, it
is going to be popen()ing the OpenVZ utilities. Which of this is
better?

Thanks,
-- 
Shuveb Hussain.
When you lose, be patient. When you achieve, be even more patient.
EasyVZ: http://easyvz.sourceforge.net
Blog: http://binarykarma.org




More information about the libvir-list mailing list