[Libvir] bug in the virSetErrorFunc() function
by Philippe Berthault
I've written a program based on libvirt (release 0.1.0) in which I uses the
virSetErrorFunc() function to avoid messages on the screen but one message
is always displayed (on stderr) and isn't trapped by the
virSetErrorFunc() function.
This message is "Unimplemented block at xs_internal.c:255"
Thanks,
18 years, 5 months
[Libvir] State of driver backend infrastructure
by 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 -=|
18 years, 5 months
[Libvir] A question about libvirt usage
by Philippe Berthault
Is there a notion of session in libvirt ?
In other words, is it possible, between virConnectOpen() and
virConnectClose(), that some Xen domains will be started, stopped,
destroyed, etc.. by another operator using the xm command ou by another
binary command based on libvirt.
If the response is yes, is it possible to introduce a global lock in Xen
(or in libvirt ?) to avoid conflict between libvirt and xm command or
between several libvirt based commands.
Thanks,
Philippe Berthault.
18 years, 5 months
[Libvir] Patch to 'ping' XenD when opening connection
by Daniel P. Berrange
Currently the XenD driver's implementation of the 'open' method will return
success, regardless of whether XenD is even present. The attached patch
makes the open method do a 'ping' to see if XenD is actually there, returning
failure if it is not. This ensures that the XenD driver backend doesn't get
activated when connecting to alternate non-Xen backends, such as the test
backend I committed last week.
The current 'ping' is simply to call the xenDaemonGetVersion() method since
that's a pretty simle & low-overhead way to testing livliness of XenD. Any
suggestions for a better ping - if not I'll go ahead & commit this change
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 -=|
18 years, 5 months
[Libvir] A 'mock' driver enabling application unit testing
by Daniel P. Berrange
The attached patch adds a new driver which provides a 'mock' hypervisor
connection. The idea behind this is to provide a completely predictable
and isolated hypervisor implementation, which will facilitate creation
of unit tests in applications using libvirt.
The code attached is not a complete implementation, providing support only
for connecting, listing domains, getting a domain by id/uuid/name, getting
domain info, getting node info. Further work will hook up methods for
creating domains, exporting XML & the other various libvirt APIs. The driver
is intended to operate as a black box, closed system - the only interaction
an application will have is via the libVirt entry points. It starts off with
a single domain present, and fixed node info, and updates domain CPU time
based on elapsed wall clock time. When the domain create API is hooked up
this will let apps create new dummy domains within the context of the process.
As I said, I delibrately implemented this driver to only have process local
state. When the process shuts down all state is discarded. This keeps application
usage very simple. Longer term I think it would be useful to have a 2nd, dynamic,
which would allow fault injection, cross-process interaction & more to allow
advanced scripting of a test scenario. I don't have time to create such a driver
myself though, so I stuck with the simplest possible impl which will allow 95%
of application unit testing needs to be satisfied.
To use this driver, simply pass 'TestSimple' as the name parameter to
virConnectOpen / virConnectOpenReadonly instead of NULL. If you are using
'virsh' then my previous patch will let you call 'virsh --connect TestSimple'
I've also tested this with the 'gnome-vm-applet' panel applet.
The only problem I have found is that the 'xend_internal.c' driver will
always return success from its 'xenDaemonOpen' method, regardless of
whether there is actually a Xen Daemon present. So when using the test
driver, every method will first try to ue the XenD driver impl, fail (printing
an error message) and then go onto use the test driver. The xenDaemonOpen
method really needs to be fixed to only succeed when Xen is actually present.
Or perhaps it should only try to run when the 'name' passed to virConnectOpen
is NULL or 'Xen' - ie be a no op if the name is 'TestSimple' / QEMU / any
other driver implementation.
I'm not sure whether we want to commit this to the libvirt codebae just,
since there is a fair bit more work to be done to hook up additional
methods.
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 -=|
18 years, 5 months
