[Libvir] [PATCH][RFC] libvirt ldoms support

[Eunice Moon]

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 at 780</name>
>>       </physio_device>
>>       <physio_device>
>>         <name>pci at 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 at 7c0/pci at 0/pci at 1/pci at 0,2/LSILogic,sas at 2/disk at 0,0:a disk net</value>
>>       </var>
>>       <var>
>>         <name>nvramrc</name>
>>         <value>devalias disk /pci at 7c0/pci at 0/pci at 1/pci at 0,2/LSILogic,sas at 2/disk at 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
>