In some situations triggered by errors found on guest side,
the device will be held forever, due to the online flag being still
on. Detach operations mostly fails from this point on, as the backend
will not see frontend's state change anymore.
Signed-off-by: Glauber de Oliveira Costa <gcosta@redhat.com>
It's a long story, but basically a small divergence in xenppc-unstable meant a
large number of changesets couldn't be directly imported to xen-unstable, so
this changeset includes all of them.
Signed-off-by: Hollis Blanchard <hollisb@us.ibm.com>
They were inconsistently represented as strings or lists making it
difficult to know the type of the IP parameter for vifs. Since both xm
and DevController represents these as space separated strings, that is
what it will be stored as.
Signed-off-by: Alastair Tse <atse@xensource.com>
be returned by XENMEM_memory_map. Hook this into the domain builder.
Based on a patch by Glauber de Oliveira Costa <gcosta@redhat.com>
Signed-off-by: Keir Fraser <keir@xensource.com>
Fix breakage with storing VIF and VBD refs, remove extraneous
debugging. Also fixing some type errors in default values for Xen API
if things are missing in XendConfig.
Signed-off-by: Alastair Tse <atse@xensource.com>
be performed on domains - new, start and delete. libvirt has had no-op
stub implementations of these APIs for a while & thus we'd enable their
use for Xen 3.0.4 builds. The new APIs are not currently exposed via the
existing SEXPR protocol, and since the new Xen-API protocol is unsupported
tech-preview for 3.0.4 we don't want to re-write against that just yet.
Thus the attached patch adds the 3 neccessary bindings for the SEXPR protocol
to allow the lifecycle functionality to be invoked. It also allows the 'state'
parameter to be specified when listing domains, so we can explicitly request
inactive domains if we know we're running against a 3.0.4 era XenD
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
incoming client requests. Since some requests can take non-trivial time
blocking out other clients in this way has bad consequences. The attached
patch makes XenD spawn a new thread to handle each incoming HTTP request.
This same approach is already taken in the XML-RPC service in XenD so I
don't anticipate any multi-thread issues (at least none which don't already
exist).
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
- An 'xc_error' struct is used to pass around error
details. Currently contains two members 'code' an enumeration of
error types, and 'message' a free text description of the specific
problem.
- The xc_get_last_error() method returns a const pointer to the
internal instance of this struct manged by libxc. By returning a
const pointer we can add extra members to the end of the struct at
any time without worrying about ABI of callers. This will let us
provide more fine-grained info if needed in the future.
- The xc_error instance is statically defined inside libxc and marked
__thread. This ensures that errors are recorded per-thread, and
that when dealing with errors we never need to call malloc - all
storage needed is statically allocated.
- The xc_clear_last_error() method resets any currently recorded
error details
- The xc_error_code_to_desc() method converts the integer error code
into a generic user facing messsage. eg "Invalid kernel". Together
with the 'message' field from xc_error, this provides the user
visible feedback. eg "Invalid kernel: Non PAE-kernel on PAE host."
- A callback can be registered with xc_set_error_handler to receive
notification whenever an error is recorded, rather than querying
for error details after the fact with xc_get_last_error
- If built with -DDEBUG set, a default error handler will be
registered which calls fprintf(stderr), thus maintaining current
behaviour of logging errors to stderr during developer builds.
- The python binding for libxc is updated to use xc_get_last_error
to pull out error details whenever appropriate, instead of
returning info based on 'errno'
- The xc_set_error method is private to libxc internals, and is used
for setting error details
- The ERROR and PERROR macros have been updated to call xc_set_error
automatically specifying XC_INTERNAL_ERROR as the error code. This
gives a generic error report for all current failure points
- Some uses of the ERROR macro have been replaced with explicit
calls to xc_set_error to enable finer grained error reporting. In
particular the code dealing with invalid kernel types uses this
to report about PAE/architecture/wordsize mismatches
The patch has been tested by calling xm create against a varietry of
config files defining invalid kernels of various kinds. It has also
been tested with libvirt talking to xend. In both cases the error
messages were propagated all the way back up the stack.
There is only one place where I need to do further work. The suspend
& restore APIs in Xend invoke external helper programs rather than
calling libxc directly. This means that error details are essentially
lost. Since there is already code in XenD which scans STDERR from
these programs I will investigate adapting this to extract actual
error messages from these helpers.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
contact and authentication details for the Xen-API server.
The default behaviour is still to use the existing legacy XML-RPC server.
Signed-off-by: Ewan Mellor <ewan@xensource.com>
Ewan Mellor
kfraser@localhost.localdomain
awilliam@xenbuild2.aw
jfehlig@jfehlig2.provo.novell.com
Hollis Blanchard
kaf24@localhost.localdomain
john.levon@sun.com
Alastair Tse