5:52 p.m.
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(a)redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/