11:47 a.m.
Hey all,
I am new to libvirt and have been asked to look at the possibility of
writing a libvirt driver for a hypervisor we are using. I am wondering
if someone can give me the basics on what is involved in accomplishing
this task, what are the basics of writing a new driver? I have looked
at the documentation posted and been poking around the code and just
wanted to ask someone to point me in the right direction.
Thanks in advance.
David Orr
General Dynamics
Software Engineer
David.Orr(a)gdc4s.com
12:03 p.m.
On Wed, Aug 27, 2008 at 09:47:40AM -0700, Orr, David-P64407 wrote:
Hey all,
I am new to libvirt and have been asked to look at the possibility of
writing a libvirt driver for a hypervisor we are using. I am wondering
if someone can give me the basics on what is involved in accomplishing
this task, what are the basics of writing a new driver? I have looked
at the documentation posted and been poking around the code and just
wanted to ask someone to point me in the right direction.
There are essentially two types of libvirt driver styles. First one I
call 'stateless', where libvirt doesn't maintain any persistent info
itself, and just talks to the hypervisor / external tools to implement
every API. The second style is 'stateful', where libvirt directly manages
everything, including persistence of the domain configuration info.
Examples of stateless drivers are Xen, and OpenVZ.
Examples of stateful drivers are QEMU, LXC
As for choosing which style to use, it depends on the hypervisor in question.
If your hypervisor has ability to storage persistent configuration data, and
make that available to libvirt, then stateless is the best approac because
it provides interoperability with existing tools for that hypervisor.
As for actually implementing things, you can take an incremental approach,
adding impls for individual methods as you go. The 'struct _virDriver'
in src/driver.h file lists all the APIs you need for a complete impl
of libvirt on a hypervisor, but you certainly don't need to have all of
them to get something useful working.
I'd recommend starting with Probe, Open, Close, NumOfDomains, ListDomains
and DomainGetInfo. That should be enough to get 'virsh list' working.
Then, add NumOfDefinedDomains and ListDefinedDomain. That will get the
virsh list --inactive command working
Then add NodeGetInfo and GetCapabilities, which lets 'virsh nodeinfo'
and 'virsh capabilities' to work.
Then add DomainDumpXML to allow a domain config to be queried via
virsh dumpxml
And then add DomainCreateLinux/DomainCreate/DomainDefine/DomainUndefine
to allow new domains to be created, started, and deleted.
At this point you'll have a pretty good impl working. Anything else beyond
this point is just a nice bonus.
For parsing XML file, the 'src/domain_conf.h' file APIs should be used.
There are other useful APIs for internal use in util.h, capabilities.h,
buf.h, and memory.h.
Also look at the HACKING file for general guidelines.
Finally, ask questions on this list for anything you don't understand.
The task of writing new hypervisor drivers is not at all documented
but there are lots of people who can advise you....
Out of interest..... what hypervisor are you using ?
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 :|
12:38 p.m.
Thanks for the response. I will look that the functions that you have
pointed out for the other drivers here and see how they would be
implemented for ours. Based on your description I think we would use a
stateless driver, since there are external tools and configurations
available.
To answer your question, it is actually a version of VMware Workstation
with a Hypervisor added to it. This is for our TVE product here at
General Dynamics; here is a link to the product description:
http://www.gdc4s.com/content/detail.cfm?item=35a995b0-b3b7-4097-9324-2c5
0008b3a75
Another question, how mature is the CIM interface of libvirt. I have
not had much time to look at it yet, but we would be using it for remote
management.
David Orr
General Dynamics
Software Engineer
David.Orr(a)gdc4s.com
|-----Original Message-----
|From: Daniel P. Berrange [mailto:berrange@redhat.com]
|Sent: Wednesday, August 27, 2008 10:03 AM
|To: Orr, David-P64407
|Cc: libvir-list(a)redhat.com
|Subject: Re: [libvirt] Writing a new driver for libvirt
|
|On Wed, Aug 27, 2008 at 09:47:40AM -0700, Orr, David-P64407 wrote:
|> Hey all,
|>
|> I am new to libvirt and have been asked to look at the possibility of
|> writing a libvirt driver for a hypervisor we are using. I am
wondering
|> if someone can give me the basics on what is involved in
accomplishing
|> this task, what are the basics of writing a new driver? I have
looked
|> at the documentation posted and been poking around the code and just
|> wanted to ask someone to point me in the right direction.
|
|There are essentially two types of libvirt driver styles. First one I
|call 'stateless', where libvirt doesn't maintain any persistent info
|itself, and just talks to the hypervisor / external tools to implement
|every API. The second style is 'stateful', where libvirt directly
manages
|everything, including persistence of the domain configuration info.
|
|Examples of stateless drivers are Xen, and OpenVZ.
|
|Examples of stateful drivers are QEMU, LXC
|
|As for choosing which style to use, it depends on the hypervisor in
|question.
|If your hypervisor has ability to storage persistent configuration
data,
|and
|make that available to libvirt, then stateless is the best approac
because
|it provides interoperability with existing tools for that hypervisor.
|
|As for actually implementing things, you can take an incremental
approach,
|adding impls for individual methods as you go. The 'struct _virDriver'
|in src/driver.h file lists all the APIs you need for a complete impl
|of libvirt on a hypervisor, but you certainly don't need to have all of
|them to get something useful working.
|
|I'd recommend starting with Probe, Open, Close, NumOfDomains,
ListDomains
|and DomainGetInfo. That should be enough to get 'virsh list' working.
|
|Then, add NumOfDefinedDomains and ListDefinedDomain. That will get the
|virsh list --inactive command working
|
|Then add NodeGetInfo and GetCapabilities, which lets 'virsh nodeinfo'
|and 'virsh capabilities' to work.
|
|Then add DomainDumpXML to allow a domain config to be queried via
|virsh dumpxml
|
|And then add
DomainCreateLinux/DomainCreate/DomainDefine/DomainUndefine
|to allow new domains to be created, started, and deleted.
|
|At this point you'll have a pretty good impl working. Anything else
beyond
|this point is just a nice bonus.
|
|For parsing XML file, the 'src/domain_conf.h' file APIs should be used.
|There are other useful APIs for internal use in util.h, capabilities.h,
|buf.h, and memory.h.
|
|Also look at the HACKING file for general guidelines.
|
|Finally, ask questions on this list for anything you don't understand.
|The task of writing new hypervisor drivers is not at all documented
|but there are lots of people who can advise you....
|
|
|Out of interest..... what hypervisor are you using ?
|
|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
|:|
4:15 p.m.
On Wed, Aug 27, 2008 at 10:38:23AM -0700, Orr, David-P64407 wrote:
Thanks for the response. I will look that the functions that you
have
pointed out for the other drivers here and see how they would be
implemented for ours. Based on your description I think we would use a
stateless driver, since there are external tools and configurations
available.
To answer your question, it is actually a version of VMware Workstation
with a Hypervisor added to it. This is for our TVE product here at
General Dynamics; here is a link to the product description:
In that case, I definitely agree that you should aim for a stateless
driver. VMWare has pre-existing config files / tools / APIs that can
be used for the libvirt driver.
Another question, how mature is the CIM interface of libvirt. I
have
not had much time to look at it yet, but we would be using it for remote
management.
The libvirt-CIM work is very active - there's another mailing
list you could ask on, if they don't notice your questions here
http://libvirt.org/CIM/
https://www.redhat.com/mailman/listinfo/libvirt-cim/
I know the people working on CIM have a good test suite that is
validating their work on a frequent basis against Xen and QEMU
libvirt drivers. This is described in their wiki pages
http://wiki.libvirt.org/page/Cimtest
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 :|
5931
days inactive
5931
days old
3 comments
2 participants
participants (2)
-
Daniel P. Berrange -
Orr, David-P64407