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