5:11 a.m.
Hi,
I'm still working on the VMX config to domain XML mapping for
dump/create XML, but it's not complete yet. I got distracted by other
urgent, Uni related work that had to be done first.
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 :)
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
heading for reading this information from the VMX config file, because
all needed information is concentrated in this file. Also, if one
changes properties of a virtual machine via VI API and this properties
is reflected in the VMX config, the ESX host updates the VMX config,
so the information is kept in sync between the object model and the
config file.
I guess, that the VMX config files contains enough information to fill
all or at least most fields of a virDomainDef. So the first goal is to
fill a virDomainDef for dump XML.
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.
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?
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).
Regards,
Matthias
10:26 a.m.
On Thu, Jun 25, 2009 at 12:11:26PM +0200, Matthias Bolte wrote:
Hi,
I'm still working on the VMX config to domain XML mapping for
dump/create XML, but it's not complete yet. I got distracted by other
urgent, Uni related work that had to be done first.
Okay :-)
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 :-)
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...
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 :-)
changes properties of a virtual machine via VI API and this
properties
is reflected in the VMX config, the ESX host updates the VMX config,
so the information is kept in sync between the object model and the
config file.
that's good to know !
I guess, that the VMX config files contains enough information to
fill
all or at least most fields of a virDomainDef. So the first goal is to
fill a virDomainDef for dump XML.
yes that sounds right
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.
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.
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.
thanks for the feedback, it's appreciated :-)
Daniel
--
Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/
daniel(a)veillard.com | Rpmfind RPM search engine http://rpmfind.net/
http://veillard.com/ | virtualization library http://libvirt.org/
10:33 a.m.
On Thu, Jun 25, 2009 at 05:26:45PM +0200, Daniel Veillard wrote:
On Thu, Jun 25, 2009 at 12:11:26PM +0200, Matthias Bolte wrote:
> 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.
> 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.
Yes, Cole got a start on the library, got some feedback from various
folks, but I don't know what the current status is. We also need this
for oVirt and for various other interesting libguestfs interactions
(virt-inspector...). If you think it's in scope for libvirt I would love
to have it there, it would make things easier for us.
--Hugh
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
5:03 a.m.
On Thu, Jun 25, 2009 at 05:26:45PM +0200, Daniel Veillard wrote:
> 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.
The information at the virt-install level is alot of fine grained,
and currently planed to be based of the full release name of each
OS. I don't think there's any need to pull the full information into
libvirt - this library cole is writing is actaully standalone and
independnat of any particular tool. What we really need to figure
out is how to map/cross-reference there data where needed.
Daniel
--
|: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
5:01 a.m.
On Thu, Jun 25, 2009 at 12:11:26PM +0200, Matthias Bolte wrote:
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
heading for reading this information from the VMX config file, because
all needed information is concentrated in this file. Also, if one
changes properties of a virtual machine via VI API and this properties
is reflected in the VMX config, the ESX host updates the VMX config,
so the information is kept in sync between the object model and the
config file.
I guess, that the VMX config files contains enough information to fill
all or at least most fields of a virDomainDef. So the first goal is to
fill a virDomainDef for dump XML.
The thought occurs to me, that using VMX config files would also
enable someone to write a libvirt driver for VMWare Desktop too,
since that uses VMX format files.
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?
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).
We don't generally use flags in the parser method for turning on/off
hypervisor specific pieces. Our goal for the XML is to figure a format
that is usable for all hypervisors, even if only one currently
implements it. So we'd want to try and figure our how to present this
OS type information.
Daniel
--
|: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
5628
days inactive
5629
days old
5 comments
4 participants
participants (4)
-
Daniel P. Berrange -
Daniel Veillard -
Hugh O. Brock -
Matthias Bolte