[Libvir] State of driver backend infrastructure

[Daniel P. Berrange]

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


 * 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.  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/

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

    
    virGetVersion:
    
     - Hardcodes support for Xen HV. No virConnectPtr handle, so
       how would we call out to driver backends ?
    
    
    virConnectOpen
    
     - OK
    
    
    virConnectOpenReadOnly
    
     - OK
    
    
    virConnectClose:
    
     - Does not call out to driver backends, simply free's struct
    
    
    virConnectGetType:
    
     - Does not call out to driver backends, hardcodes Xen HV
    
    
    virConnectGetVersion
    
     - Does not call out to driver backends, hardcodes Xen HV
    
    
    virConnectListDomains
    
     - Calls out to drivers, but also has duplicated code for 
       XenD & XenStore
    
    
    virConnectNumOfDomains
    
     - Calls out to drivers, but also has duplicated code for 
       XenD & XenStore
    
    
    virDomainCreateLinux
    
     - Does not call out to driver backends, hardcodes XenD
    
    
    virDomainLookupByID
    
     - Calls out to drivers, but also has duplicated code for 
       XenD & XenStore
    
    
    virDomainLookupByUUID
    
     - Calls out to drivers, but also has duplicated code for 
       XenD & XenStore
    
    
    virDomainLookupByUUIDString
    
     - OK  (but delegates to virDomainLookupByUUID)
    
    
    virDomainLookupByName
    
     - Calls out to drivers, but also has duplicated code for 
       XenD & XenStore
    
    
    virDomainDestroy
    
     - Does not call out to driver backends, hardcodes XenD & Xen HV
    
    
    virDomainFree
    
     - Does not call out to driver backends, simply free's struct
    
    
    virDomainSuspend
    
     - Does not call out to driver backends, hardcodes XenD & Xen HV
    
    
    virDomainResume
    
     - Does not call out to driver backends, hardcodes XenD & Xen HV
    
    
    virDomainSave
    
     - Does not call out to driver backends, hardcodes XenD
    
    
    virDomainRestore
    
     - Does not call out to driver backends, hardcodes XenD
    
    
    virDomainShutdown
    
     - Does not call out to driver backends, hardcodes XenD
    
    
    virDomainReboot
    
     - Does not call out to driver backends, hardcodes XenD
    
    
    virDomainGetName
    
     - OK
    
    
    virDomainGetUUID
    
     - Does not call out to driver backends, hardcodes XenD
    
    
    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
    
    
    virDomainSetMaxMemory
    
     - OK
    
    
    virDomainSetMemory
    
     - OK
    
    
    virDomainGetInfo
    
     - Calls out to drivers, but also has duplicated code for 
       XenD & XenStore
    
    
    virDomainGetXMLDesc
    
     - Does not call out to driver backends, hardcodes XenD
    
    
    virNodeGetInfo
    
     - OK
    
    
    virDomainDefineXML
    
     - OK
    
    
    virDomainUndefineXML
    
     - OK
    
    
    virDomainListDefinedDomains
    
     - No implemented
    
    
    virDomainCreate
    
     - No implemented

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

Regards,
Dan.
-- 
|=- Red Hat, Engineering, Emerging Technologies, Boston.  +1 978 392 2496 -=|
|=-           Perl modules: http://search.cpan.org/~danberr/              -=|
|=-               Projects: http://freshmeat.net/~danielpb/               -=|
|=-  GnuPG: 7D3B9505   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505  -=|