[libvirt] Some questions about the libvirt ESX driver

[Matthias Bolte]

2009/12/31 Richard W.M. Jones <rjones at 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