7:20 a.m.
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
7:26 a.m.
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(a)veillard.com | Rpmfind RPM search engine http://rpmfind.net/
http://veillard.com/ | virtualization library http://libvirt.org/
8:26 a.m.
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
9:17 a.m.
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 :|
10 a.m.
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
10:52 a.m.
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
11:33 a.m.
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 :|
9:22 a.m.
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
10:20 a.m.
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(a)redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
10:23 a.m.
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 :|
10:48 a.m.
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
5781
days inactive
5866
days old
10 comments
4 participants
participants (4)
-
Daniel P. Berrange -
Daniel Veillard -
John Levon -
Pritesh Kothari