2009/12/31 Richard W.M. Jones <rjones@redhat.com>:
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