[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

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

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:


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

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
|> if someone can give me the basics on what is involved in
|> this task, what are the basics of writing a new driver?  I have
|> 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
|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
|If your hypervisor has ability to storage persistent configuration
|make that available to libvirt, then stateless is the best approac
|it provides interoperability with existing tools for that hypervisor.
|As for actually implementing things, you can take an incremental
|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,
|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
|to allow new domains to be created, started, and deleted.
|At this point you'll have a pretty good impl working. Anything else
|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 ?
||: Red Hat, Engineering, London   -o-
||: http://libvirt.org  -o-  http://virt-manager.org  -o-
||: http://autobuild.org       -o-
||: GnuPG: 7D3B9505  -o-  F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]