[...] > > > > Differences from QEMU/Xen: > > > > * ID and name are same > > So open VZ has no kind of unique identifier aside from its ID numbers ? Yeah, true. > > > * 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. > Sure. > > > 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. I will work on this. > > - 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. I'll try to use these and remove any code with duplicate functionality. > > 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. Daniel, we had this discussion going a couple of months earlier on the list. Sure, there are fundamental differences between Xen/QEMU VMs and containers like OpenVZ and the current XML format may not be sufficient for containers. I'll consolidate my concerns and mail the list back. Thanks for the comments, Regards, -- Shuveb Hussain Unix is very user friendly. It is just a little choosy about who its friends are http://www.binarykarma.com -- Libvir-list mailing list Libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list