<html><body>
<p>T<br>
Thanks Daniel. I agree on both counts: the list I attached (as given to me) is still pretty anemic, and our Xen CIM consumer today would also prefer generic, broadly useful common error codes and not just Xen (or VMWare) specific ones, although some of this normalization will probably be handled at the CIM level. I'll check out your suggested links. thnx again.<br>
<br>
<tt>>(and if know of a way to invite the WMWare folks to help here I would be grateful :-).</tt><br>
<br>
<tt>I will plant a seed and see if it grows... :-)</tt><br>
<br>
- G<br>
<br>
<br>
Gareth S. Bestor, PhD.<br>
<br>
IBM Linux Technology Center<br>
M/S DES2-01<br>
15300 SW Koll Parkway, Beaverton, OR 97006<br>
503-578-3186, T/L 775-3186, Fax 503-578-3186<br>

<p><font size="2" color="#800080">Please respond to veillard@redhat.com </font>
<p><font size="2" color="#800080">To:   </font><font size="2">Gareth S Bestor/Poughkeepsie/IBM@IBMUS</font><br>
<font size="2" color="#800080">cc:    </font><font size="2">libvir-list@redhat.com</font><font size="2" color="#800080"> </font><br>
<font size="2" color="#800080">Subject:       </font><font size="2">Re: [Libvir] XML-RPC support for libvirt</font><br>
<br>
<br>
<tt>On Fri, Mar 10, 2006 at 02:57:57PM -0800, Gareth S Bestor wrote:<br>
> >> Of course, using the xml-rpc code, we now have access to rich fault<br>
> >> information.  Xend never actually returns errors for things and instead<br>
> >> throws exceptions.<br>
> ><br>
> >  the new error code tries at least to extract the error message when<br>
> >an HTTP POST or GEt fails with an error code, but the XML-RPC should<br>
> >give a far more reliable framework for error handling.<br>
> <br>
> Nice segway... I've been recently pinged a few times by our Xen CIM<br>
> consumers about the lack of good errors coming out of our providers (which<br>
> in turn are limited by what we get back from libxm today), especially in<br>
> regards to conditions that might cause a create() operation to fail. Do you<br>
> have a sense today of what errors we might expect to get reported back from<br>
> libvirt?<br>
<br>
  I think the prerequisite read is the following page where I tried to<br>
write down how I planned and implemented error handling:<br>
    </tt><tt><a href="http://libvirt.org/errors.html">http://libvirt.org/errors.html</a></tt><tt><br>
  it's not coming from nowhere, it's actually the model used by libxml2<br>
"structured" error handling the latest evolution of error processing in<br>
that library. It's not completely broken as people seems to be satisfied<br>
now with it (and its set of users is quite diverse :-)<br>
<br>
> Not that this will constitute any sort of meaningful 'requirements' with<br>
> which to write code, but the following is a list of errors that my Xen CIM<br>
> consumers handle today for the likes VMWare. I am trying to get more info<br>
> on under what specific circumstance(s) these are generated...<br>
> <br>
> ERR_SUCCESS<br>
> ERR_UNABLE_TO_VERIFY_STATE<br>
> ERR_OUT_OF_DISK_SPACE<br>
> ERR_BAD_PARAMETER<br>
> ERR_VM_CONTROL_OP_FAILED<br>
> ERR_INVALID_PARM_NUM<br>
> ERR_CANNOT_ACCESS_DISK_FILE<br>
> ERR_UNKNOWN<br>
> ERR_VIRTUAL_DISK_CREATE_FAILED<br>
> ERR_VM_STUCK<br>
> ERR_CREDENTIALS_NOT_SET<br>
> ERR_UNACCEPTED_CREDENTIALS<br>
> ERR_OUT_OF_MEMORY<br>
> ERR_WRONG_STATE_FOR_OP<br>
> ERR_VM_NOT_FOUND<br>
> ERR_HOST_NOT_FOUND<br>
> ERR_ACCESS_DENIED<br>
> ERR_ALREADY_EXIST<br>
> ERR_OPERATION_FAILED<br>
> ERR_UNDOABLE_DISK_NOT_SUPPORTED<br>
> ERR_VMM_CMD_FORMAT_ERROR<br>
> ERR_COMMUNICATION_NOT_ESTABLISHED<br>
> ERR_FILE_COPY_FAILED<br>
> ERR_NAME_TOO_LONG<br>
> ERR_OS_NOT_SUPPORTED<br>
> ERR_MOUNT_FAILED_DIR_NOT_EMPTY<br>
> ERR_CANT_DISMOUNT_BOOT_OR_SYSTEM<br>
> ERR_FILE_IN_USE<br>
<br>
  That look actually a bit short to me for such a complete tool ;-)<br>
<br>
> I think error reporting is an area where we will definitely want to drive<br>
> clients' requirements down into the likes of libvirt. Thnx.<br>
<br>
  Well you can consult libvirt current list of errors in <br>
    </tt><tt><a href="http://libvirt.org/html/libvirt-virterror.html#virErrorNumber">http://libvirt.org/html/libvirt-virterror.html#virErrorNumber</a></tt><tt><br>
if we can get more details from the Xend internals then the <br>
VIR_ERR_GET_FAILED  and VIR_ERR_POST_FAILED could be replaced by <br>
more precise informations. Also keep in mind that I would like <br>
as much as possible to keep genericity in the API among the different<br>
back-ends (and if know of a way to invite the WMWare folks to help here<br>
I would be grateful :-).<br>
<br>
Daniel<br>
<br>
-- <br>
Daniel Veillard      | Red Hat </tt><tt><a href="http://redhat.com/">http://redhat.com/</a></tt><tt><br>
veillard@redhat.com  | libxml GNOME XML XSLT toolkit  </tt><tt><a href="http://xmlsoft.org/">http://xmlsoft.org/</a></tt><tt><br>
</tt><tt><a href="http://veillard.com/">http://veillard.com/</a></tt><tt> | Rpmfind RPM search engine </tt><tt><a href="http://rpmfind.net/">http://rpmfind.net/</a></tt><tt><br>
</tt><br>
</body></html>