Re: [PATCH][RFC] libvirt ldoms support

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

-- 
Red Hat Virtualization group http://redhat.com/virtualization/
Daniel Veillard      | virtualization library  http://libvirt.org/
veillard@xxxxxxxxxx  | libxml GNOME XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine  http://rpmfind.net/

--
Libvir-list mailing list
Libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list

[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]