Hi Daniel,
I've added some notes (lines starting with **) to the LDoms XML
examples to show some semantics for the current XML tags/formats.
Please see the attached files and let me know if you have any
questions.
Thanks,
Eunice
Daniel Veillard wrote:
On Thu, Apr 10, 2008 at 04:10:02PM -0500, Eunice Moon wrote:
Hi,
As John mentioned, the LDoms Manager (ldm) XML interface has been
used by a different set of software such as SNMP MIB, BUI, and other
tools/applications (before the libvirt), so we can't really change
the ldm XML formats.
I understood the existing format comes from other legacy uses,
no problem for me, looking at the second XML example made that clear :-)
But, I will look into the way (conversion between the LDoms XML
and libvirt XML formats) to make it compatible with the official
libvirt.
I can give an hand, it's probably also a good opportunity to refactor
a lot of the XML handling code coming from the patch since we will have
to change the way things are done. The hardest for me is understand the
semantic of the current document, we need this anyway to find how to best
map things onto the libvirt XML format (and back). Then for the revamp of
the conversion code i can probably do part of it, and probably faster than
you considering expertise on libxml2 ;-)
But I really need a good description of the current XML format,
Daniel
** This is an example of the virsh 'dumpxml' output which
** shows the configuration of the LDoms domain in XML format.
<?xml version="1.0"?>
** This <LDM_interface> tag should be present for all LDoms XML documents.
** It should have a version attribute and the current version is 1.0.
<LDM_interface version="1.0">
** There should be at least one or more <cmd> tags. Multiple commands
** can be sent to the LDM per document.
** Each <cmd> section must have only one <action> tag. The LDM also provides
** the CLI to create and manage logical domains, and the content for <action> tag
** correspons to the specific CLI.
<cmd>
<action>list-constraints</action>
** The <data> section is used to contain information which is pertinent
** to the command in the <action> tag. It should have a version attribute and
** the data version used for LDoms 1.0.1 and 1.0.2 is v2. There is a plan
** to move to the data version 3 to make a more generic XML interface, but
** the backward compatibility will be provided to the existing v2 formats.
<data version="2.0">
** The <ldom> tag should be present.
<ldom>
** The <ldom_info> section will contain the domain name and the MAC address
** for the domain.
<ldom_info>
<ldom_name>primary</ldom_name>
<mac_address>00:14:4f:02:7d:c6</mac_address>
</ldom_info>
** The <cpu> section is used for the number of virtual CPUs for the given domain.
<cpu>
<number>10</number>
</cpu>
** The <mau> section is used for the number of cryptographic units for the given
** domain. MAU is the Modular Arithmetic Unit which is the cryptographic device
** for Sun UltraSPARC T1-based platformas.
<mau>
<number>3</number>
</mau>
** The <memory> section is used for the virtual memory for the given domain.
** Default size is in bytes, or it can be specified gigabytes (G), kilobytes (K),
** or megabytes (M).
<memory>
<size>1920M</size>
</memory>
** The <physio_device> section is used for the physical IO device such as a PCI
** bus for the given domain.
<physio_device>
<name>pci@780</name>
</physio_device>
<physio_device>
<name>pci@7c0</name>
</physio_device>
** The <vsw> section is used for the virtual network switch (vsw) service that
** connects the virtual network devices to the external network and also switches
** packets between them.
<vsw>
<service_name>primary-vsw0</service_name>
<dev_path>e1000g0</dev_path>
</vsw>
** The <vcc> section is used for the virtual console concentrator service (vcc)
** with a specific range of TCP ports to assign to each guest domain.
<vcc>
<service_name>primary-vcc0</service_name>
<min_port>5000</min_port>
<max_port>5033</max_port>
</vcc>
** The <var> section is used for the OBP variables for the given domain.
** Each <var> section has the name and value pair for a variable.
<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>
** This <response> section contains the result of an XML request sent to the LDM
** for the <data> section.
<response>
<status>success</status>
</response>
</data>
** This <response> section contains the result of an XML request sent to the LDM
** for the <cmd> section.
<response>
<status>success</status>
</response>
</cmd>
** This <response> section contains the result of an XML request sent to the LDM
** for the entire request.
<response>
<status>success</status>
</response>
</LDM_interface>
** This is an example of the response XML document from the LDoms Manager (LDM)
** to the "list-bindings" request.
**
** For LDoms, the resources such as cpu or memory are added to the guest domain
** and then those resources should be bound before the domain can be started.
** Initialy, the state of the domain is "inactive", then it becomes "bound"
** when the resources are bound (with the bind-domain CLI or XML requests).
** Then, the state can be "active" when the domain gets started (with the
** start-domain command).
<?xml version="1.0"?>
<LDM_interface version="1.0">
<cmd>
<action>list-bindings</action>
<data version="2.0">
<ldom>
<ldom_info>
<ldom_name>ldom1</ldom_name>
<mac_address>00:14:4f:fa:fb:63</mac_address>
</ldom_info>
** The <cpu> section in the list-bindings output shows the number of
** CPUs bound to the given domain with the virtual/physical CPU IDs
** and strand in percent.
<cpu>
<number>1</number>
<binding>
<vid>0</vid>
<pid>12</pid>
<strand_percent>100</strand_percent>
</binding>
</cpu>
** The <memory> section contains the bound memory resources
** such as the real memory address, physical memory address, and
** the size of the memory for the given domain.
** Memory space seen in the domain is referred to as the real
** memory (virtual memory) and the memory space seen by the
** hypervisor is referred to as physical memory. The hypervisor
** maps blocks of physical memory to form a block of real memory
** which is used by a logical domain.
<memory>
<size>128M</size>
<binding>
<real_addr>0x8000000</real_addr>
<phys_addr>0x88000000</phys_addr>
<size>128M</size>
</binding>
</memory>
** The <console> section contains the console port number.
<console>
<service_name>primary-vcc0</service_name>
<port>5001</port>
</console>
</ldom>
<response>
<status>success</status>
</response>
</data>
<response>
<status>success</status>
</response>
</cmd>
<response>
<status>success</status>
</response>
</LDM_interface>
--
Libvir-list mailing list
Libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list