[Libvir] Initial OpenVZ Support Patches
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 * 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 readonly access. OpenVZ tools need root access. There are other design issues to be discussed. These issues spring from the fact that OpenVZ is very different from Xen/QEMU. I will discuss these issues in further mails. Here is a sample session transcript: shuveb@debian-openvz:~/libvirt$ sudo src/virsh -c openvz:///system Welcome to lt-virsh, the virtualization interactive terminal. Type: 'help' for help with commands 'quit' to quit virsh # list Id Name State ---------------------------------- 101 101 running 102 102 running 103 103 running virsh # shutdown 101 Domain 101 is being shutdown virsh # list Id Name State ---------------------------------- 102 102 running 103 103 running virsh # list --all Id Name State ---------------------------------- 102 102 running 103 103 running - 101 shut off virsh # start 101 Domain 101 started virsh # list Id Name State ---------------------------------- 101 101 running 102 102 running 103 103 running virsh # Thanks and Regards, -- Shuveb Hussain Unix is very user friendly. It is just a little choosy about who its friends are http://www.binarykarma.com
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 -=|
[...]
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
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 * 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 readonly access. OpenVZ tools need root access.
There are other design issues to be discussed. These issues spring from the fact that OpenVZ is very different from Xen/QEMU. I will discuss these issues in further mails.
Here is a sample session transcript:
Okay, that works ! I have installed OpenVZ myself and applied the patches locally. After renaming the readline in the openvz_conf.c to avoid overriding the system one (and then crashing libvirt), it worked for me on x86_64. There are slight differences in behaviour, for example shutdown looks synchronous (but since it's very fast it's not that a big deal). There is a lot of stuff I would like to change, for example make all the module functions private, the readline renaming, etc ... What I would suggest is the following: - commit the new files to CVS - apply the patch but make the openvz configure off by default Then we can work out of CVS, which will make cooperative development easier. If that's good for you tell me, I will arrange the commits etc, thanks a lot ! Daniel -- Red Hat Virtualization group http://redhat.com/virtualization/ Daniel Veillard | virtualization library http://libvirt.org/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
On Tue, 2007-07-17 at 07:00 -0400, Daniel Veillard wrote:
Okay, that works ! I have installed OpenVZ myself and applied the patches locally. After renaming the readline in the openvz_conf.c to avoid overriding the system one (and then crashing libvirt), it worked for me on x86_64. There are slight differences in behaviour, for example shutdown looks synchronous (but since it's very fast it's not that a big deal). There is a lot of stuff I would like to change, for example make all the module functions private, the readline renaming, etc ... What I would suggest is the following: - commit the new files to CVS - apply the patch but make the openvz configure off by default Then we can work out of CVS, which will make cooperative development easier.
If that's good for you tell me, I will arrange the commits etc,
Great! I will work on the feedback provided by you and Daniel. B. A commit will help speedup generating patches a lot. Thanks! Regards, -- Shuveb Hussain Unix is very user friendly. It is just a little choosy about who its friends are http://www.binarykarma.com
On Tue, Jul 17, 2007 at 05:15:19PM +0530, Shuveb Hussain wrote:
On Tue, 2007-07-17 at 07:00 -0400, Daniel Veillard wrote:
Okay, that works ! I have installed OpenVZ myself and applied the patches locally. After renaming the readline in the openvz_conf.c to avoid overriding the system one (and then crashing libvirt), it worked for me on x86_64. There are slight differences in behaviour, for example shutdown looks synchronous (but since it's very fast it's not that a big deal). There is a lot of stuff I would like to change, for example make all the module functions private, the readline renaming, etc ... What I would suggest is the following: - commit the new files to CVS - apply the patch but make the openvz configure off by default Then we can work out of CVS, which will make cooperative development easier.
If that's good for you tell me, I will arrange the commits etc,
Great! I will work on the feedback provided by you and Daniel. B. A commit will help speedup generating patches a lot.
Okay, done, run cvs update you should get those, thanks ! Daniel -- Red Hat Virtualization group http://redhat.com/virtualization/ Daniel Veillard | virtualization library http://libvirt.org/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
participants (3)
-
Daniel P. Berrange -
Daniel Veillard -
Shuveb Hussain