2009/12/31 Richard W.M. Jones <rjones@xxxxxxxxxx>: > On Wed, Dec 30, 2009 at 09:29:10PM +0100, Matthias Bolte wrote: >> I've never seen this error message from the ESX server before. Many >> errors reported by the ESX server contain a details section, but the >> deserialization of this details requires many new SOAP types and I >> haven't implemented this yet. > > Can we get LIBVIRT_DEBUG=1 to just dump the SOAP response? > > /me checks the source ... > > It seems like currently debug output is hard-coded into a #define. > Having it wired to LIBVIRT_DEBUG would allow people to debug these > issues without needing to recompile. I assume you refer to ESX_VI__CURL__ENABLE_DEBUG_OUTPUT and esxVI_CURL_Debug. I just noticed that this is broken and also doesn't dump the transfered SOAP messages. I don't think that dumping the complete SOAP communication using VIR_DEBUG is useful in general, but I'm going to dump the undeserialized SOAP faults so the message details are available in the debug output. >> Can you start the domain using the VI client? Maybe the domain really >> is in a state where it cannot be started. > > OK, turns out that the VMWare server was in "maintenance mode". Ah. I should add a check to the ESX driver and output a warning or at least an info about the ESX server being in maintenance mode. >> What's wrong with it in your opinion? The <source file> attribute is >> correct. See the ESX driver website section [3] about this. > > Nothing wrong with it, just a bit unusual. But as you say, it is a > valid path according to ESX's unusual path convention. > >> > (e) pool-list, net-list are not supported by the driver. > [...] >> I plan to implement the ESX driver as complete as possible, this >> includes network and storage handling. I've took a look at this some >> time ago and saw some problems. For examples datastores don't have a >> UUID, so I may need to make them up and store them somewhere like the >> IBM Power driver does it for the domain UUIDs, the libvirt network >> model cannot represent a vSwitch ... I think these drivers are much >> harder to implemented than the main ESX driver, so don't expect any >> news on this in the next weeks, but stay tuned :) >> >> What do you mean by "to access the VMDK files that contain domains", >> just list them? > > It's so that we can inspect the VM's disk, for virt-inspector: > > http://libguestfs.org/virt-inspector.1.html > > Ideally we'd like to download all or part of the VM's disk (ie. VMDK > file(s)). Hm, I haven't looked into the storage driver API in detail yet, but maybe it allows report an URL to access a volume. An ESX server exposes its datastores (local and remote) and all files in them over https://<hostname>/folder. You can also put files there using this mechanism. > Thanks for your detailed reply! > > Rich. > Matthias -- Libvir-list mailing list Libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list