[Libvir] Initial OpenVZ Support Patches

[Daniel P. Berrange]

On Mon, Jul 16, 2007 at 01:58:41PM +0530, Shuveb Hussain wrote:
> Hi,
> Here are the OpenVZ support patches. The .c and .h files go into src/
> This is being released in the spirit of releasing early. Only the basic
> stuff is done and development is continuing.
> 
> What works:
> 
> * Getting number of active/inactive domains
> * Listing active/inactive domains
> * Creating a domain that has been already defined (using OpenVZ tools)
> * Shutdown, start, reboot
> * configure.in has a new switch --with-openvz(on by default), use
> --without-openvz to switch it off.
> 
> After I get feedback, I will work on it and add other features later on.
> There is no need for any OpenVZ tools code. Just the OpenVZ kernel and
> tools need to be installed. This code depends on the OpenVZ tool
> binaries.
> 
> Differences from QEMU/Xen:
> 
> * ID and name are same

So open VZ has no kind of unique identifier aside from its ID numbers ?

> * Not possible to create temporary domains and do away with them.
> Creating a domain will involve untarring a template cache and bringing
> it up.

No problem. 

> * No readonly access. OpenVZ tools need root access.

Since your openvz driver is returning VIR_OPEN_DECLINED when run as
non-root, we can trivially make sure that the general purpose 'remote
driver' handles the non-root case. This would allow read-only acces
to the openvz driver by non-root - the tools would be run indirctly
by the libvirt daemon.



A couple of quick comments about the drivers thus far

 - I'd prefer if we avoided the use of popen(). Since you know the exact
   finite set of arguments needed for each invocation of the OpenVZ tools
   I think it'd be preferrable to just pack them into a char **argv and
   do plain fork/exec. This avoids the extra shell invocation, and any
   unexpected security issues you might see by the shell globbing / or
   interpreting the args in unexpected ways.  The qemu_driver.c has a
   function  'qemudExec'  which takes a char **argv to run, and does the
   fork/exec  pair, returning you 2 file handles - one for stdout, and
   the other for stderr.

   This avoids the shell, and lets you easily separate the regular output
   from the error output - with the shell you get stdout & stderr merged
   into one making parsing potentially unreliable.

   It might in fact be a good idea if we moved 'qemuExec' out into a 
   separate file so it can be shared/used by any/all drivers which need
   to exec things.

 - Take a look at the src/uuid.h file which has functions you can call
   to parse & generate UUIDs - we just separated them out from QEMU to
   allow re-use across drivers.

Overall the structure of the driver looks sane to me. I'll be interested to
here what thoughts you have wrt to XML because as you say  container based
virt will have some interesting differences from hypervisor based virt in
this respect.

Regards,
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  -=|