RE: [libvirt] Writing a new driver for libvirt

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 |:|