[libvirt] VMware ESX driver status update
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
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@veillard.com | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/
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
2009/6/25 Daniel Veillard <veillard@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
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 :|
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 :|
participants (4)
-
Daniel P. Berrange -
Daniel Veillard -
Hugh O. Brock -
Matthias Bolte