[libvirt] Writing a new driver for libvirt
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@gdc4s.com
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 :|
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@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@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 |:|
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 :|
participants (2)
-
Daniel P. Berrange -
Orr, David-P64407