[libvirt] Adding VirtualBox support to libvirt
Hi, I am in the process of adding support for virtualbox in libvirt. Basically Virtualbox exports its API through XPCOM. Now to simplify things I was thinking of using C++ and already existing xpcom component in virtualbox but since libvirt exports C API i am not sure if i should use C++ or stick to plain C. I would like to request the libvirt community for its comment on this. Regards, Pritesh
On Wed, Dec 03, 2008 at 02:20:44PM +0100, Pritesh Kothari wrote:
Hi,
I am in the process of adding support for virtualbox in libvirt.
Basically Virtualbox exports its API through XPCOM. Now to simplify things I was thinking of using C++ and already existing xpcom component in virtualbox but since libvirt exports C API i am not sure if i should use C++ or stick to plain C.
I would like to request the libvirt community for its comment on this.
please use plain C if you want the support to be incorporated, check existing recent drivers code to see how to handle the XML format parsing and saving, also make sure you don't need too much extra libraries and that their Licence is compatible with the LGPL of libvirt otherwise the code will be unusable in the end. thanks ! Daniel -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ daniel@veillard.com | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/
Hi, As mentioned in the earlier mail, I have started the work on adding Virtualbox support to libvirt. I have completed almost all the basic functionality. Currently I can start, shutdown, reboot, list and suspend/resume the domains. Now I am in the process writing code for creating/defining the domains and thats where i need some help. I am not familiar with the exact XML format required. I have gone through the docs at http://libvirt.org/formatdomain.html as well as the code and have few question regarding the same as below: Is the XML format for defining the Domains common to all the hypervisors? If not then how should I start about defining it for Virtualbox? What exactly does the tag <os_type>xen</os_type> exactly mean? how can xen, hvm, etc be an os type? why virDomainCreate doesn't actually create the domain but it just starts it? (virDomainCreateXML actually creates it) The rest of my question are more general and not related to XML def. In src/qemu_driver.c:qemudGetVersion() why does the qemu driver have to take the lock, i mean what can change while extracting the version info? is there any specific reason? (this is true for other drivers like openvz, uml, etc as well ) I am using dlopen() and friends to open the VirtualBox library at runtime, is it ok? cause I didn't see any driver doing something like this. Regards, -pritesh On Wednesday 03 December 2008 14:26:30 Daniel Veillard wrote:
On Wed, Dec 03, 2008 at 02:20:44PM +0100, Pritesh Kothari wrote:
Hi,
I am in the process of adding support for virtualbox in libvirt.
Basically Virtualbox exports its API through XPCOM. Now to simplify things I was thinking of using C++ and already existing xpcom component in virtualbox but since libvirt exports C API i am not sure if i should use C++ or stick to plain C.
I would like to request the libvirt community for its comment on this.
please use plain C if you want the support to be incorporated, check existing recent drivers code to see how to handle the XML format parsing and saving, also make sure you don't need too much extra libraries and that their Licence is compatible with the LGPL of libvirt otherwise the code will be unusable in the end.
thanks !
Daniel
On Thu, Feb 26, 2009 at 03:26:34PM +0100, Pritesh Kothari wrote:
Hi,
As mentioned in the earlier mail, I have started the work on adding Virtualbox support to libvirt. I have completed almost all the basic functionality. Currently I can start, shutdown, reboot, list and suspend/resume the domains.
Now I am in the process writing code for creating/defining the domains and thats where i need some help. I am not familiar with the exact XML format required. I have gone through the docs at http://libvirt.org/formatdomain.html as well as the code and have few question regarding the same as below:
Is the XML format for defining the Domains common to all the hypervisors? If not then how should I start about defining it for Virtualbox?
The XML format has always been intended to be the same across drivers. A few releases ago, we introduced generic internal API for parsing the domain XML format, to guarentee that all drivers use the same format. You can see the APIs to use in src/domain_conf.h, and the schema in docs/schemas/. That said, we need to do some additions for VirtualBox eventually, depending on just what configs it supports. So if you find things you need that are not yet covered by our domain XML schema, post details to the list and we can figure out the best way to represent them.
What exactly does the tag <os_type>xen</os_type> exactly mean? how can xen, hvm, etc be an os type?
This tag refers to the ABI of the guest kernel - hvm : unmodified bare metal OS - ie FullyVirtualized - xen: xen 3.0 paravirt ABI VirtualBox is a fullyvirt technology, so I expect you'll only want to support 'hvm' as an os type. You declare what architectures, and SO types you support when creating your capabilities data - virCapabilityPtr - see src/capabities.h
why virDomainCreate doesn't actually create the domain but it just starts it? (virDomainCreateXML actually creates it)
virDomainCreateXML() spawns an unmanaged guest, with no config file. For a managed guest, virDomainDefineXML() writes the config file, and virDomainCreate() launches a guest from that config.
The rest of my question are more general and not related to XML def.
In src/qemu_driver.c:qemudGetVersion() why does the qemu driver have to take the lock, i mean what can change while extracting the version info? is there any specific reason? (this is true for other drivers like openvz, uml, etc as well )
As of 0.6.0, the libvirtd daemon is fully multi-threaded. This means that many API calls can be using your driver concurrently. So every driver API call you have (ie those registered in the 'virDriver' struct must use one or more mutexs to ensure safe access to internal state.
I am using dlopen() and friends to open the VirtualBox library at runtime, is it ok? cause I didn't see any driver doing something like this.
I think it depends on exactly how you are doing it - best to just post the patches and we can discuss whether it looks reasonable then. Why did you dlopen() instead of just linking to it directly ? Regards, Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
Hi Daniel,
As of 0.6.0, the libvirtd daemon is fully multi-threaded. This means that many API calls can be using your driver concurrently. So every driver API call you have (ie those registered in the 'virDriver' struct must use one or more mutexs to ensure safe access to internal state.
thanks, i will do the same for virtualbox driver.
I am using dlopen() and friends to open the VirtualBox library at runtime, is it ok? cause I didn't see any driver doing something like this.
I think it depends on exactly how you are doing it - best to just post the patches and we can discuss whether it looks reasonable then. Why did you dlopen() instead of just linking to it directly ?
Basically my code depends on three libraries used in virtualbox namely: VBoxXPCOMC.so, VBoxRT.so, VBoxXPCOM.so and if i link to them then these dependencies would trickle down to other programs as well, for example: virsh would need to be relinked, for that matter any program who depends on libvirt with virtualbox support compiled in it would need to be relinked. so currently i am trying to make as minimal change to any of the libvirt files as possible and restrict my code to the following 6 files: vbox_driver.c/h and vbox_conf.c/h. I am not sure if this approach is valid? Also I am not sure when or how should I call the driver mature enough to post it on the list? (like do you have any specific functions required) I have almost all the basic functionality for listing/suspending/resuming domains up and running. Regards, -pritesh
Regards, Daniel
On Thu, Feb 26, 2009 at 05:00:47PM +0100, Pritesh Kothari wrote:
I think it depends on exactly how you are doing it - best to just post the patches and we can discuss whether it looks reasonable then. Why did you dlopen() instead of just linking to it directly ?
Basically my code depends on three libraries used in virtualbox namely: VBoxXPCOMC.so, VBoxRT.so, VBoxXPCOM.so and if i link to them then these dependencies would trickle down to other programs as well, for example: virsh would need to be relinked, for that matter any program who depends on libvirt with virtualbox support compiled in it would need to be relinked. so currently i am trying to make as minimal change to any of the libvirt files as possible and restrict my code to the following 6 files: vbox_driver.c/h and vbox_conf.c/h. I am not sure if this approach is valid?
Perhaps you want to enable DRIVER_MODULES, which uses dlopen to open individual drivers. That way you don't need to dlopen the vbox modules, but libvirt apps don't need to know about them. regards john
On Thu, Feb 26, 2009 at 11:52:18AM -0500, John Levon wrote:
On Thu, Feb 26, 2009 at 05:00:47PM +0100, Pritesh Kothari wrote:
I think it depends on exactly how you are doing it - best to just post the patches and we can discuss whether it looks reasonable then. Why did you dlopen() instead of just linking to it directly ?
Basically my code depends on three libraries used in virtualbox namely: VBoxXPCOMC.so, VBoxRT.so, VBoxXPCOM.so and if i link to them then these dependencies would trickle down to other programs as well, for example: virsh would need to be relinked, for that matter any program who depends on libvirt with virtualbox support compiled in it would need to be relinked. so currently i am trying to make as minimal change to any of the libvirt files as possible and restrict my code to the following 6 files: vbox_driver.c/h and vbox_conf.c/h. I am not sure if this approach is valid?
Perhaps you want to enable DRIVER_MODULES, which uses dlopen to open individual drivers. That way you don't need to dlopen the vbox modules, but libvirt apps don't need to know about them.
Even without the DRIVER_MODULES setting, you can setup the Makefile.am rules so that it is only linked into the libvirtd daemon and not in the main libvirt.so. Take a look at the qemud/Makefile.am and src/Makefile.am files and what they do with libvirt_driver_qemu.la Regards, Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
On Thu, Feb 26, 2009 at 03:26:34PM +0100, Pritesh Kothari wrote:
Is the XML format for defining the Domains common to all the hypervisors? If not then how should I start about defining it for Virtualbox?
Hi Pritesh. The XML format is not exactly the same between the hypervisors, but large parts of it are shared. For example, we may have: <domain type='xen' id='-1'> You'd define the vbox type here in Relax-NG spec. Most elements you'll find are the same between hypervisors, but some are split across types, e.g.: <define name='os'> <choice> <ref name='osxen'/> <ref name='oshvm'/> <ref name='osexe'/> </choice> </define> Generally, if you can, use the generic parts. If you need to specify something specific to VBox you have three options: 1. work out a hypervisor-agnostic abstraction for what you're trying to define (preferred), then use that 1. define a vbox-specific ref as you above 2. if it's just a small addition or choice, allow it as optional in the spec (say it's a disk property you want to add)
What exactly does the tag <os_type>xen</os_type> exactly mean? how can xen, hvm, etc be an os type?
It's a horrible wart. OS type really means "v12n method", and it means either paravirt or HVM here. Presumably vbox wouldn't use this choice (remember the relax ng spec isn't/can't be completely prescriptive).
why virDomainCreate doesn't actually create the domain but it just starts it? (virDomainCreateXML actually creates it)
Bad names. "Create" means start, "CreateXML" means "create using the definition given here, but don't persist the definition when it's shut down". regards john
Hi John,
Generally, if you can, use the generic parts. If you need to specify something specific to VBox you have three options:
1. work out a hypervisor-agnostic abstraction for what you're trying to define (preferred), then use that 1. define a vbox-specific ref as you above 2. if it's just a small addition or choice, allow it as optional in the spec (say it's a disk property you want to add)
Thanks for the detailed explanation, as you mentioned above I will try to use the generic parts first.
What exactly does the tag <os_type>xen</os_type> exactly mean? how can xen, hvm, etc be an os type?
It's a horrible wart. OS type really means "v12n method", and it means either paravirt or HVM here. Presumably vbox wouldn't use this choice (remember the relax ng spec isn't/can't be completely prescriptive).
so you mean to say, I can just use the parts necessary for me and don't care about the rest?
why virDomainCreate doesn't actually create the domain but it just starts it? (virDomainCreateXML actually creates it)
Bad names. "Create" means start, "CreateXML" means "create using the definition given here, but don't persist the definition when it's shut down".
great.. :) Regards, -pritesh
regards john
-- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
On Thu, Feb 26, 2009 at 05:20:55PM +0100, Pritesh Kothari wrote:
Hi John,
Generally, if you can, use the generic parts. If you need to specify something specific to VBox you have three options:
1. work out a hypervisor-agnostic abstraction for what you're trying to define (preferred), then use that 1. define a vbox-specific ref as you above 2. if it's just a small addition or choice, allow it as optional in the spec (say it's a disk property you want to add)
Thanks for the detailed explanation, as you mentioned above I will try to use the generic parts first.
What exactly does the tag <os_type>xen</os_type> exactly mean? how can xen, hvm, etc be an os type?
It's a horrible wart. OS type really means "v12n method", and it means either paravirt or HVM here. Presumably vbox wouldn't use this choice (remember the relax ng spec isn't/can't be completely prescriptive).
so you mean to say, I can just use the parts necessary for me and don't care about the rest?
Correct, there is no requirement to implement every single feature. For OS type you only need to implement the virt ABIs that matter to you, so 'hvm' in this case, and ignore the other like 'xen'. Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
On Thu, Feb 26, 2009 at 05:20:55PM +0100, Pritesh Kothari wrote:
What exactly does the tag <os_type>xen</os_type> exactly mean? how can xen, hvm, etc be an os type?
It's a horrible wart. OS type really means "v12n method", and it means either paravirt or HVM here. Presumably vbox wouldn't use this choice (remember the relax ng spec isn't/can't be completely prescriptive).
so you mean to say, I can just use the parts necessary for me and don't care about the rest?
Well it depends on the particular circumstances, but certainly, drivers are at liberty not to use bits that aren't relevant (though you might want to complain if you actually see some) regards john
participants (4)
-
Daniel P. Berrange -
Daniel Veillard -
John Levon -
Pritesh Kothari