Hi Daniel,
Yes, thanks for the feedback and we are agreeing on the
code changes to be done. I also agree that there is a big issue
regarding different XML formats.
I don't think the first option (to change the LDoms Manager XML
format to be based on the libvirt XML format) is a feasible one
since LDoms has been released public and some tools/applications
are already based on the LDom Manager's XML interfaces.
So, it seems like we need to go for the second option (to provide
a conversion layer between the LDoms Manager and libvirt XML
formats) that would require some research and scoping.
Thanks,
Eunice
Daniel Veillard wrote:
On Wed, Apr 09, 2008 at 08:52:44PM -0500, Eunice Moon wrote:
Hi Daniel,
Thanks for your comments. Please see my responses inline below.
Hi Eunice,
it seems we are basically agreeing on the needed code change, which is
great ... but there is one big problem remaining:
Example of domain definition data:
<?xml version="1.0"?>
<LDM_interface version="1.0">
<data version="2.0">
<ldom>
<ldom_info>
<ldom_name>primary</ldom_name>
<mac_address>00:14:4f:02:7d:c6</mac_address>
</ldom_info>
<cpu>
<number>10</number>
</cpu>
<mau>
<number>3</number>
</mau>
<memory>
<size>1920M</size>
</memory>
<physio_device>
<name>pci@780</name>
</physio_device>
<physio_device>
<name>pci@7c0</name>
</physio_device>
<vsw>
<service_name>primary-vsw0</service_name>
<dev_path>e1000g0</dev_path>
</vsw>
<vcc>
<service_name>primary-vcc0</service_name>
<min_port>5000</min_port>
<max_port>5033</max_port>
</vcc>
<var>
<name>boot-device</name>
<value>/pci@7c0/pci@0/pci@1/pci@0,2/LSILogic,sas@2/disk@0,0:a disk net</value>
</var>
<var>
<name>nvramrc</name>
<value>devalias disk /pci@7c0/pci@0/pci@1/pci@0,2/LSILogic,sas@2/disk@0
</value>
</var>
<var>
<name>use-nvramrc?</name>
<value>true</value>
</var>
</ldom>
</data>
</LDM_interface>
From what i understand this correspond to what you would suggest libvirt
lDOM domain to use, both as input when creating or defining a process or
when dumping the XML of a domain via 'virsh dumpxml domainame'
In a sense the XML format is also part of libvirt API and your data
is completely different from what libvirt uses for all other hypervisors:
http://libvirt.org/format.html#Normal1
I understand that your format correspond to what the virtualization
manager exports as no transformation of the data is done at the libvirt
lDOM patches level.
So basically as is we are in a situation where no existing tool based on
libvirt (like virt-manager or ovirt) can be ported to a future libvirt
for lDOM without completely changing the XML handling code. That would
seriously diminish the value of the lDOM libvirt port, isn't it ?
One option is to adapt the virtualization manager to use an XML
format which is based on libvirt existing format, I don't know if this
is possible. One problem to consider is whether the existing format is
'public' or just internal to the existing tools.
The other option I can see is to provide a conversion layer, either in
libvirt or in the manager to allow the processing of domain descriptions
based on the libvirt public format. I even thing the code could detect
the kind of format near trivially (for example by checking the name of
the root element when receiving XML, and by using a compatibility flag
when extracting XML with virDomainGetXMLDesc).
I'm not sure i would be able to trivially map your existing format to
a libvirt one, because i don't understand what some of the fields are for
and the way you name devices are a bit strange to me, but i'm sure it can
be solved. it will just take some work,
what do you think ?
Daniel
--
Libvir-list mailing list
Libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list