[Libvir] State of driver backend infrastructure

[Daniel Veillard]

On Mon, Jun 12, 2006 at 11:19:00PM +0100, Daniel P. Berrange wrote:
> I'm looking to get more of the test driver backend working, and so decided
> it was time to audit the state of the driver backend infrastructure. There
> are a couple of areas which could do with some work:
> 
>  * Driver specific data. The virConnect & virDomain structs have explicit
>    fields for Xen related data:
> 
>    virConnect:
> 
>     int handle;   /* internal handle used for hypercall */
>     struct xs_handle *xshandle;   /* handle to talk to the xenstore */
> 
>    virDomain:
> 
>     int handle;             /* internal handle for the domnain ID */
> 
> 
>    One idea for resolving this is to have an array of slots, one per
>    drivers in which drivers can store data they need.
> 
>       void **handles
> 
>    Or perhaps, to allow simple int type too
> 
>       void union {
>         int  num;
>         void *ptr
>       } *handles

  Hum, I think I would worry when we have half a dozen back-ends, virConnect
content is opaque, allocated/freed only by the library so changing that
later won't generate any kind of API or ABI issues. Having explicit pointers
at worse may loose a few bytes per connections, and on the other hand having
the explicit types there ease debugging. So at this point I think there isn't
really to worry about it.

> 
>  * Connect URIs.  The 'virDomainOpen' and 'virDomainOpenReadOnly' methods
>    have an optional parameter 'name'. The Xen drivers currently ignore
>    this, or expect it to be NULL / the string "Xen". For sake of back-compat
>    we'll ned to preserve existing behaviour for NULL, but we should hook
>    up URI parsing for the XenD backend to allow non local connections to
>    work.

  yes, that's an area which need refining.

>  This gives the question of what format should the URI be for
>    Xen domains ?  Although 'http://' is the protocol XenD uses, this isn't
>    likely a good idea, because a later VMWare driver might also use a
>     http based protocol. So, perhaps we should use generic URIs:?
> 
>         xend://somehost:port/

yes I was thinking of somthing like this. The only annoying point is that 
xend isn't really a protocol i.e. it deviates a bit from URI real semantic
and one could think of multiple xend access types (see Anthony's patch for
Xend XML-RPC though ssh on xen-devel), but we could do things like

          xend:///var/run/xend/socket

          xendssh://user@somehost:port

while being relatively clean w.r.t RFC 2396 and Co.

>  * Driver method hookup. The libvirt.c file has alot of methods which are
>    either not hooked up to the driver backend, or hooked up, but still have
>    duplicated (redundant?) Xen specific calls. Here is the complete status:

  Okay, I need to clean them up, please bugzilla this I will fix this soonish.

>     virGetVersion:
>     
>      - Hardcodes support for Xen HV. No virConnectPtr handle, so
>        how would we call out to driver backends ?
>     

  yes that's an API bug :-\ , I'm afraid that mean I will have to make a
release breaking compatibility, annoying, better do that as soon as possible.

>     virConnectClose:
>     
>      - Does not call out to driver backends, simply free's struct

  okay need to call the virDrvClose if non NULL.
>     
>     virConnectGetType:
>     
>      - Does not call out to driver backends, hardcodes Xen HV

  Should return the value of virDrvGetType() or the string identifying the
driver if NULL

>     
>     virConnectGetVersion
>     
>      - Does not call out to driver backends, hardcodes Xen HV

  Should return value of virDrvGetVersion()

>     
>     virConnectListDomains
>     
>      - Calls out to drivers, but also has duplicated code for 
>        XenD & XenStore

  Should remove the fallback, that should just work

>     virConnectNumOfDomains
>     
>      - Calls out to drivers, but also has duplicated code for 
>        XenD & XenStore

  same as previous
>     
>     virDomainLookupByID
>     
>      - Calls out to drivers, but also has duplicated code for 
>        XenD & XenStore
 same as previous
>     
>     virDomainLookupByUUID
>     
>      - Calls out to drivers, but also has duplicated code for 
>        XenD & XenStore

  same as previous

>     virDomainLookupByName
>     
>      - Calls out to drivers, but also has duplicated code for 
>        XenD & XenStore
>     
   same as previous

>     
>     virDomainCreateLinux
>     
>      - Does not call out to driver backends, hardcodes XenD

  that one is a bit complex because that's multistep, but yeah
if needed the meat of the routine should just be moved in the xend driver.

>     
>     virDomainLookupByUUIDString
>     
>      - OK  (but delegates to virDomainLookupByUUID)
>     
>     
>     virDomainDestroy
>     
>      - Does not call out to driver backends, hardcodes XenD & Xen HV
>     

  bad need fixing to call the driver entry point.

>     virDomainFree
>     
>      - Does not call out to driver backends, simply free's struct
>     

  same as previous

>     virDomainSuspend
>     
>      - Does not call out to driver backends, hardcodes XenD & Xen HV
>     
> 
  same as previous

>     virDomainResume
>     
>      - Does not call out to driver backends, hardcodes XenD & Xen HV
> 
  same as previous

>     
>     virDomainSave
>     
>      - Does not call out to driver backends, hardcodes XenD
> 
  same as previous

>     
>     virDomainRestore
>     
>      - Does not call out to driver backends, hardcodes XenD
> 
  same as previous

>     
>     virDomainShutdown
>     
>      - Does not call out to driver backends, hardcodes XenD
> 
  same as previous

>     
>     virDomainReboot
>     
>      - Does not call out to driver backends, hardcodes XenD
> 
  same as previous

>     
>     virDomainGetUUID
>     
>      - Does not call out to driver backends, hardcodes XenD
>     
>     
>     virDomainGetName
>     
>      - OK
>     
>     
>     virDomainGetUUIDString
>     
>      - OK  (but delegates to virDomainGetUUID)
>     
>     
>     virDomainGetOSType
>     
>      - Does not call out to driver backends, calls function in XenStore driver
>     
>     
>     virDomainGetMaxMemory
>     
>      - Does not call out to driver backends, hardcodes XenD, Xen HV, XenStore
>     
>     
>     virDomainGetXMLDesc
>     
>      - Does not call out to driver backends, hardcodes XenD

  Those 3 need to call the corresponding driver entries.

>     
>     virDomainSetMaxMemory
>     
>      - OK
>     
>     
>     virDomainSetMemory
>     
>      - OK
>     
>     
>     virDomainGetInfo
>     
>      - Calls out to drivers, but also has duplicated code for 
>        XenD & XenStore
>     

  fall back need to be removed

>     virNodeGetInfo
>     
>      - OK
>     
>     
>     virDomainDefineXML
>     
>      - OK
>     
>     
>     virDomainUndefineXML
>     
>      - OK
>     
>     
>     virDomainListDefinedDomains
>     
>      - No implemented
>     
>     
>     virDomainCreate
>     
>      - No implemented

  I need to implement the entry point but I'm waiting on Xend changes to
support defined but not running domains.

> My immediate needs for testing, are to hook up more of the methods which
> aren't connected to the driver backends.

  Okay I need to clean this up, should not be that hard except the Version
API change needed, :-\ maybe I can avoid this by using the version extraction
from the first activated driver found.

Thanks a lot for going though this !

Daniel

-- 
Daniel Veillard      | Red Hat http://redhat.com/
veillard at redhat.com  | libxml GNOME XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/