3:15 p.m.
2009/6/25 Daniel Veillard <veillard(a)redhat.com>:
> So I won't be able to complete the dump/create XML
implementation
> until tomorrow (freeze for the 0.6.5 release) that was requested in
> order to get the driver merged into the official repository. But well,
> with the short release cycle of libvirt not much is lost :)
I expect we will have another release in approx 4 weeks, to be able
to push features in Fedora 12, ESX support then would be great :-)
Dump XML will definitely be done until then and create XML will
probably be done until then (at least I hope so).
> Some details on the VMX config to domain XML mapping:
>
> I claimed before that I would need to read most information needed for
> dump XML from the VMX config file. That's not true. Possibly all
> information can be retrieved via VI API, but the information is
> scattered in various places in the VI API object model. I'm currently
yeah, I found their APIs increadibly confusing BTW...
The main problem is the size of the API, it's really huge, so it takes
a while until you come across the parts needed to accomplish the
desired task or to get the desired information.
> heading for reading this information from the VMX config file,
because
> all needed information is concentrated in this file. Also, if one
yes agreed thats probably way simpler in the end, and having a
format conversion capability available at the virsh level will be useful
in any case, so that code is needed anyway :-)
Yes, domain-xml-to/from-native are easily implemented as a side effect.
> The next goal would be a basic create XML. I claimed before that
I
> would need to write an VMX config file to the ESX host in order to
> create a new virtual machine, but as I dig trough the VI API in more
> detail, it seems that this claim maybe false. I'll just have to test
> this, but haven't had time to do it yet.
on the other hand sending the VMX config may make the set of VI apis
used simpler.
I'll take the simpler route, but I haven't just tested yet. If I can
create a new virtual machine in the way as I assumed before, I'll do
so. But I'll need to test this first and than decide what to do.
> One problem here is the essential guestOS field of the VMX
config, see
> http://sanbarrow.com/vmx/vmx-guestos.html . For a first try I would
> set it to 'other' by default, because there is currently no field
> available in the domain XML to map this information to. But to allow
> the user to set this filed, I would want to extend to domain XML
> definition in order to reuse existing code. So how would I do this?
Hum, that need to be though out a bit, as we do the same kind of
things at the higher level (e.g. virt-install) and then convert that
to various tweaks in the XML. I think Cole was starting to write a
library to ease making per OS guest definitions, maybe we need to
bring this down to libvirt level. I doubt the format at the XML level
will be very hard, it's more a problem of making the information
database available globally for the whole stack, either within libvirt
or as a component that can be called consistently from top to bottom.
Well, I got told today (after I wrote the first mail) that using the
correct guestOS type for an ESX virtual machine is important. Using
the wrong type could prevent a virtual machine from even booting up.
As I said for the first implementation I would use 'other' or
'other-64' depending on the configured architecture. That should work
for all possible guests, but would disable possible optimizations, but
I need to test this also. Because of this it would be good If there
would be a way to pass the guestOS type to the ESX driver. Passing it
via the domain XML just seemed natural to me. But if you say there is
work going on regarding this topic, that's good.
> Currently I'm just using the virDomainDef struct and the
related parse
> and format functions. One option would be to add a guest field to the
> virDomainOSDef struct and extend the parse and format functions to
> handle it. The parse and format functions take flags already, so a
> flag could be added to indicate if the guest field should be handled
> or not (just like the VMX extension for the virConfParser).
Yes extending the Def and the XML (and RNG) syntax are things which
are rather simple but we need to provide this in a consistant way,
and that call to an API extension or a separate library. but we don't
need this in a first step to build a first version of the ESX driver.
Correct, 'other' or 'other-64' will do for a first version of the ESX
driver. I just wanted to point out that at least the ESX driver has a
need for the guestOS type information and that I don't see how to pass
this information to the driver with the current API. And you'er
correct, because this is a concern of the public libvirt API it
shouldn't the done in a hurry, but be designed with caution.
Regards,
Matthias