libvirt/docs/schemas/basictypes.rng

619 lines
18 KiB
Plaintext
Raw Normal View History

<?xml version="1.0"?>
<!-- network-related definitions used in multiple grammars -->
<grammar xmlns="http://relaxng.org/ns/structure/1.0" datatypeLibrary="http://www.w3.org/2001/XMLSchema-datatypes">
<!-- Our unsignedInt doesn't allow a leading "+" in its lexical form -->
<define name="unsignedInt">
<data type="unsignedInt">
<param name="pattern">[0-9]+</param>
</data>
</define>
<define name="unsignedLong">
<data type="unsignedLong">
<param name="pattern">[0-9]+</param>
</data>
</define>
<define name="hexuint">
<data type="string">
<param name="pattern">(0x)?[0-9a-f]+</param>
</data>
</define>
<define name="positiveInteger">
<data type="positiveInteger">
<param name="pattern">[0-9]+</param>
</data>
</define>
<define name="octalMode">
<data type="unsignedInt">
<param name="pattern">[0-7]+</param>
</data>
</define>
<define name="uint8">
<choice>
<data type="string">
<param name="pattern">0x[0-9a-fA-F]{1,2}</param>
</data>
<data type="int">
<param name="minInclusive">0</param>
<param name="maxInclusive">255</param>
</data>
</choice>
</define>
<define name="uint16">
<choice>
<data type="string">
<param name="pattern">(0x)?[0-9a-fA-F]{1,4}</param>
</data>
<data type="int">
<param name="minInclusive">0</param>
<param name="maxInclusive">65535</param>
</data>
</choice>
</define>
<define name="uint24">
<choice>
<data type="string">
<param name="pattern">0x[0-9a-fA-F]{1,6}</param>
</data>
<data type="int">
<param name="minInclusive">0</param>
<param name="maxInclusive">16777215</param>
</data>
</choice>
</define>
<define name="uint32">
<choice>
<data type="string">
<param name="pattern">(0x)?[0-9a-fA-F]{1,8}</param>
</data>
<data type="unsignedInt">
<param name="minInclusive">0</param>
<param name="maxInclusive">4294967295</param>
</data>
</choice>
</define>
<define name="UUID">
<choice>
<data type="string">
<param name="pattern">[a-fA-F0-9]{32}</param>
</data>
<data type="string">
<param name="pattern">[a-fA-F0-9]{8}\-([a-fA-F0-9]{4}\-){3}[a-fA-F0-9]{12}</param>
</data>
</choice>
</define>
numa: describe siblings distances within cells Add support for describing NUMA distances in a domain's <numa> <cell> XML description. Below is an example of a 4 node setup: <cpu> <numa> <cell id='0' cpus='0-3' memory='2097152' unit='KiB'> <distances> <sibling id='0' value='10'/> <sibling id='1' value='21'/> <sibling id='2' value='31'/> <sibling id='3' value='21'/> </distances> </cell> <cell id='1' cpus='4-7' memory='2097152' unit='KiB'> <distances> <sibling id='0' value='21'/> <sibling id='1' value='10'/> <sibling id='2' value='21'/> <sibling id='3' value='31'/> </distances> </cell> <cell id='2' cpus='8-11' memory='2097152' unit='KiB'> <distances> <sibling id='0' value='31'/> <sibling id='1' value='21'/> <sibling id='2' value='10'/> <sibling id='3' value='21'/> </distances> <cell id='3' cpus='12-15' memory='2097152' unit='KiB'> <distances> <sibling id='0' value='21'/> <sibling id='1' value='31'/> <sibling id='2' value='21'/> <sibling id='3' value='10'/> </distances> </cell> </numa> </cpu> A <cell> defines a NUMA node. <distances> describes the NUMA distance from the <cell> to the other NUMA nodes (the <sibling>s). For example, in above XML description, the distance between NUMA node0 <cell id='0' ...> and NUMA node2 <sibling id='2' ...> is 31. Valid distance values are '10 <= value <= 255'. A distance value of 10 represents the distance to the node itself. A distance value of 20 represents the default value for remote nodes but other values are possible depending on the physical topology of the system. When distances are not fully described, any missing sibling distance values will default to 10 for local nodes and 20 for remote nodes. If distance is given for A -> B, then we default B -> A to the same value instead of 20. Signed-off-by: Wim ten Have <wim.ten.have@oracle.com> Reviewed-by: Daniel P. Berrange <berrange@redhat.com> Signed-off-by: Jim Fehlig <jfehlig@suse.com>
2017-11-02 15:47:20 +00:00
<define name="numaDistanceValue">
<data type="unsignedInt">
<param name="minInclusive">10</param>
<param name="maxInclusive">255</param>
</data>
</define>
<define name="pciaddress">
<optional>
<attribute name="domain">
<ref name="pciDomain"/>
</attribute>
</optional>
<optional>
<attribute name="bus">
<ref name="pciBus"/>
</attribute>
</optional>
<optional>
<attribute name="slot">
<ref name="pciSlot"/>
</attribute>
</optional>
<optional>
<attribute name="function">
<ref name="pciFunc"/>
</attribute>
</optional>
<optional>
<attribute name="multifunction">
<ref name="virOnOff"/>
</attribute>
</optional>
</define>
<define name="zpciaddress">
<optional>
<element name="zpci">
<optional>
<attribute name="uid">
<ref name="uint16"/>
</attribute>
</optional>
<optional>
<attribute name="fid">
<ref name="uint32"/>
</attribute>
</optional>
</element>
</optional>
</define>
<!-- a 6 byte MAC address in ASCII-hex format, eg "12:34:56:78:9A:BC" -->
<!-- The lowest bit of the 1st byte is the "multicast" bit. a -->
<!-- uniMacAddr requires that bit to be 0, and a multiMacAddr -->
<!-- requires it to be 1. Plain macAddr will accept either. -->
<!-- Currently there is no use of multiMacAddr in libvirt, it -->
<!-- is included here for documentation/comparison purposes. -->
<define name="uniMacAddr">
<data type="string">
<param name="pattern">[a-fA-F0-9][02468aAcCeE](:[a-fA-F0-9]{2}){5}</param>
</data>
</define>
<define name="multiMacAddr">
<data type="string">
<param name="pattern">[a-fA-F0-9][13579bBdDfF](:[a-fA-F0-9]{2}){5}</param>
</data>
</define>
<define name="macAddr">
<data type="string">
<param name="pattern">[a-fA-F0-9]{2}(:[a-fA-F0-9]{2}){5}</param>
</data>
</define>
<!--====================================================================-->
<!--The duid is a unique identifier used in DHCPv6 to identity an -->
<!--interface on a device (system). The duid is often used by servers -->
<!--such as dnsmasq to assign a specific IP address (and optionally a -->
<!--name to an interface. The applicable standards are RFC3315 and -->
<!--RFC6355. These standards actually require the duid to be fixed for -->
<!--the hardware device and applicable to all network interfaces on -->
<!--that device. It is not clear that any software currently enforces -->
<!--this requirement although it could be implemented manually. -->
<!--====================================================================-->
<!--There are currently four types of duids defined: -->
<!-- type 1, duid-LLT, link-layer (MAC) plus 32 bit time when the -->
<!-- duid-LLT was created in seconds from January 1, 2000 -->
<!-- type 2, duid-EN, 32 bit "enterprise number" followed by a -->
<!-- variable length unique identifier. -->
<!-- type 3, duid-LL, link-layer (MAC) -->
<!-- type 4, duid-UUID, a 128 bit UUID (16 bytes) -->
<!--RFC3315 states that the maximum length of a duid is 128 bytes plus -->
<!--the 16 bit type field. Often, the machine type is "1" which is the -->
<!--number assigned to ethernet. -->
<define name="duidLLT">
<data type="string">
<!-- 0======| type======| 0======| machine type======| time================| link-layer============| -->
<param name="pattern">[0]{1,2}:[0]{0,1}[1]:[0]{1,2}:[0]{0,1}[a-fA-F1-9](:[a-fA-F0-9]{1,2}){4}(:[a-fA-F0-9]{1,2}){6,8}</param>
</data>
</define>
<define name="duidEN">
<data type="string">
<!-- 0======| type======| Enterprise number===| unique id ==============| -->
<param name="pattern">[0]{1,2}:[0]{0,1}[2](:[a-fA-F0-9]{1,2}){4}(:[a-fA-F0-9]{1,2}){1,124}</param>
</data>
</define>
<define name="duidLL">
<data type="string">
<!-- 0======| type======| 0======| machine type======| link-layer============| -->
<param name="pattern">[0]{1,2}:[0]{0,1}[3]:[0]{1,2}:[0]{0,1}[a-fA-F1-9](:[a-fA-F0-9]{1,2}){6,8}</param>
</data>
</define>
<define name="duidUUID">
<data type="string">
<!-- 0======| type======| UUID=================| -->
<param name="pattern">[0]{1,2}:[0]{0,1}[4](:[a-fA-F0-9]{1,2}){16}</param>
</data>
</define>
<define name="DUID">
<choice>
<ref name="duidLLT"/>
<ref name="duidEN"/>
<ref name="duidLL"/>
<ref name="duidUUID"/>
</choice>
</define>
<!--======================================================================-->
<!-- An ipv4 "dotted quad" address -->
<define name="ipv4Addr">
<data type="string">
<param name="pattern">(((25[0-5])|(2[0-4][0-9])|(1[0-9]{2})|([1-9][0-9])|([0-9]))\.){3}((25[0-5])|(2[0-4][0-9])|(1[0-9]{2})|([1-9][0-9])|([0-9]))</param>
</data>
</define>
<!-- Based on http://blog.mes-stats.fr/2008/10/09/regex-ipv4-et-ipv6 -->
<define name="ipv6Addr">
<data type="string">
<!-- To understand this better, take apart the toplevel "|"s -->
<param name="pattern">(([0-9A-Fa-f]{1,4}:){7}[0-9A-Fa-f]{1,4})|(([0-9A-Fa-f]{1,4}:){6}:[0-9A-Fa-f]{1,4})|(([0-9A-Fa-f]{1,4}:){5}:([0-9A-Fa-f]{1,4}:)?[0-9A-Fa-f]{1,4})|(([0-9A-Fa-f]{1,4}:){4}:([0-9A-Fa-f]{1,4}:){0,2}[0-9A-Fa-f]{1,4})|(([0-9A-Fa-f]{1,4}:){3}:([0-9A-Fa-f]{1,4}:){0,3}[0-9A-Fa-f]{1,4})|(([0-9A-Fa-f]{1,4}:){2}:([0-9A-Fa-f]{1,4}:){0,4}[0-9A-Fa-f]{1,4})|(([0-9A-Fa-f]{1,4}:){6}(((25[0-5])|(2[0-4][0-9])|(1[0-9]{2})|([1-9][0-9])|([0-9]))\.){3}((25[0-5])|(2[0-4][0-9])|(1[0-9]{2})|([1-9][0-9])|([0-9])))|(([0-9A-Fa-f]{1,4}:){0,5}:(((25[0-5])|(2[0-4][0-9])|(1[0-9]{2})|([1-9][0-9])|([0-9]))\.){3}((25[0-5])|(2[0-4][0-9])|(1[0-9]{2})|([1-9][0-9])|([0-9])))|(::([0-9A-Fa-f]{1,4}:){0,5}(((25[0-5])|(2[0-4][0-9])|(1[0-9]{2})|([1-9][0-9])|([0-9]))\.){3}((25[0-5])|(2[0-4][0-9])|(1[0-9]{2})|([1-9][0-9])|([0-9])))|([0-9A-Fa-f]{1,4}::([0-9A-Fa-f]{1,4}:){0,5}[0-9A-Fa-f]{1,4})|(::([0-9A-Fa-f]{1,4}:){0,6}[0-9A-Fa-f]{1,4})|(([0-9A-Fa-f]{1,4}:){1,7}:)|(::)</param>
</data>
</define>
<define name="ipAddr">
<choice>
<ref name="ipv4Addr"/>
<ref name="ipv6Addr"/>
</choice>
</define>
<define name="ipv4Prefix">
<data type="unsignedInt">
<param name="maxInclusive">32</param>
</data>
</define>
<define name="ipv6Prefix">
<data type="unsignedInt">
<param name="maxInclusive">128</param>
</data>
</define>
<define name="ipPrefix">
<choice>
<ref name="ipv4Prefix"/>
<ref name="ipv6Prefix"/>
</choice>
</define>
<define name="genericName">
<data type="string">
<param name="pattern">[a-zA-Z0-9_\+\-]+</param>
</data>
</define>
<define name="dnsName">
<data type="string">
<param name="pattern">[a-zA-Z0-9\.\-]+</param>
</data>
</define>
<define name="deviceName">
<data type="string">
<param name="pattern">[a-zA-Z0-9_\.\-\\:/]+</param>
</data>
</define>
<define name="zoneName">
<data type="string">
<param name="pattern">[a-zA-Z0-9_\-]+</param>
</data>
</define>
<define name="filePath">
<data type="string">
<param name="pattern">.+</param>
</data>
</define>
<define name="dirPath">
<data type="string">
<param name="pattern">.+</param>
</data>
</define>
<define name="absFilePath">
<data type="string">
<param name="pattern">/.+</param>
</data>
</define>
<define name="absDirPath">
<data type="string">
<param name="pattern">/.*</param>
</data>
</define>
<define name="unit">
<data type="string">
<param name="pattern">([bB]([yY][tT][eE][sS]?)?)|([kKmMgGtTpPeE]([iI]?[bB])?)</param>
</data>
</define>
<define name="scaledInteger">
xml: output memory unit for clarity Make it obvious to 'dumpxml' readers what unit we are using, since our default of KiB for memory (1024) differs from qemu's default of MiB; and differs from our use of bytes for storage. Tests were updated via: $ find tests/*data tests/*out -name '*.xml' | \ xargs sed -i 's/<\(memory\|currentMemory\|hard_limit\|soft_limit\|min_guarantee\|swap_hard_limit\)>/<\1 unit='"'KiB'>/" $ find tests/*data tests/*out -name '*.xml' | \ xargs sed -i 's/<\(capacity\|allocation\|available\)>/<\1 unit='"'bytes'>/" followed by a few fixes for the stragglers. Note that with this patch, the RNG for <memory> still forbids validation of anything except unit='KiB', since the code silently ignores the attribute; a later patch will expand <memory> to allow scaled input in the code and update the RNG to match. * docs/schemas/basictypes.rng (unit): Add 'bytes'. (scaledInteger): New define. * docs/schemas/storagevol.rng (sizing): Use it. * docs/schemas/storagepool.rng (sizing): Likewise. * docs/schemas/domaincommon.rng (memoryKBElement): New define; use for memory elements. * src/conf/storage_conf.c (virStoragePoolDefFormat) (virStorageVolDefFormat): Likewise. * src/conf/domain_conf.h (_virDomainDef): Document unit used internally. * src/conf/storage_conf.h (_virStoragePoolDef, _virStorageVolDef): Likewise. * tests/*data/*.xml: Update all tests. * tests/*out/*.xml: Likewise. * tests/define-dev-segfault: Likewise. * tests/openvzutilstest.c (testReadNetworkConf): Likewise. * tests/qemuargv2xmltest.c (blankProblemElements): Likewise.
2012-02-23 00:48:38 +00:00
<optional>
<attribute name="unit">
<ref name="unit"/>
xml: output memory unit for clarity Make it obvious to 'dumpxml' readers what unit we are using, since our default of KiB for memory (1024) differs from qemu's default of MiB; and differs from our use of bytes for storage. Tests were updated via: $ find tests/*data tests/*out -name '*.xml' | \ xargs sed -i 's/<\(memory\|currentMemory\|hard_limit\|soft_limit\|min_guarantee\|swap_hard_limit\)>/<\1 unit='"'KiB'>/" $ find tests/*data tests/*out -name '*.xml' | \ xargs sed -i 's/<\(capacity\|allocation\|available\)>/<\1 unit='"'bytes'>/" followed by a few fixes for the stragglers. Note that with this patch, the RNG for <memory> still forbids validation of anything except unit='KiB', since the code silently ignores the attribute; a later patch will expand <memory> to allow scaled input in the code and update the RNG to match. * docs/schemas/basictypes.rng (unit): Add 'bytes'. (scaledInteger): New define. * docs/schemas/storagevol.rng (sizing): Use it. * docs/schemas/storagepool.rng (sizing): Likewise. * docs/schemas/domaincommon.rng (memoryKBElement): New define; use for memory elements. * src/conf/storage_conf.c (virStoragePoolDefFormat) (virStorageVolDefFormat): Likewise. * src/conf/domain_conf.h (_virDomainDef): Document unit used internally. * src/conf/storage_conf.h (_virStoragePoolDef, _virStorageVolDef): Likewise. * tests/*data/*.xml: Update all tests. * tests/*out/*.xml: Likewise. * tests/define-dev-segfault: Likewise. * tests/openvzutilstest.c (testReadNetworkConf): Likewise. * tests/qemuargv2xmltest.c (blankProblemElements): Likewise.
2012-02-23 00:48:38 +00:00
</attribute>
</optional>
<ref name="unsignedLong"/>
xml: output memory unit for clarity Make it obvious to 'dumpxml' readers what unit we are using, since our default of KiB for memory (1024) differs from qemu's default of MiB; and differs from our use of bytes for storage. Tests were updated via: $ find tests/*data tests/*out -name '*.xml' | \ xargs sed -i 's/<\(memory\|currentMemory\|hard_limit\|soft_limit\|min_guarantee\|swap_hard_limit\)>/<\1 unit='"'KiB'>/" $ find tests/*data tests/*out -name '*.xml' | \ xargs sed -i 's/<\(capacity\|allocation\|available\)>/<\1 unit='"'bytes'>/" followed by a few fixes for the stragglers. Note that with this patch, the RNG for <memory> still forbids validation of anything except unit='KiB', since the code silently ignores the attribute; a later patch will expand <memory> to allow scaled input in the code and update the RNG to match. * docs/schemas/basictypes.rng (unit): Add 'bytes'. (scaledInteger): New define. * docs/schemas/storagevol.rng (sizing): Use it. * docs/schemas/storagepool.rng (sizing): Likewise. * docs/schemas/domaincommon.rng (memoryKBElement): New define; use for memory elements. * src/conf/storage_conf.c (virStoragePoolDefFormat) (virStorageVolDefFormat): Likewise. * src/conf/domain_conf.h (_virDomainDef): Document unit used internally. * src/conf/storage_conf.h (_virStoragePoolDef, _virStorageVolDef): Likewise. * tests/*data/*.xml: Update all tests. * tests/*out/*.xml: Likewise. * tests/define-dev-segfault: Likewise. * tests/openvzutilstest.c (testReadNetworkConf): Likewise. * tests/qemuargv2xmltest.c (blankProblemElements): Likewise.
2012-02-23 00:48:38 +00:00
</define>
<define name="pciDomain">
<ref name="uint32"/>
</define>
<define name="pciBus">
<ref name="uint8"/>
</define>
<define name="pciSlot">
<choice>
<data type="string">
<param name="pattern">(0x)?[0-1]?[0-9a-fA-F]</param>
</data>
<data type="int">
<param name="minInclusive">0</param>
<param name="maxInclusive">31</param>
</data>
</choice>
</define>
<define name="pciFunc">
<choice>
<data type="string">
<param name="pattern">(0x)?[0-7]</param>
</data>
<data type="int">
<param name="minInclusive">0</param>
<param name="maxInclusive">7</param>
</data>
</choice>
</define>
<define name="wwn">
<data type="string">
<param name="pattern">(0x)?[0-9a-fA-F]{16}</param>
</data>
</define>
<define name="ccwCssidRange">
<choice>
<data type="string">
<param name="pattern">0x[0-9a-eA-E][0-9a-fA-F]?</param>
</data>
<data type="string">
<param name="pattern">0x[fF][0-9a-eA-E]?</param>
</data>
<data type="int">
<param name="minInclusive">0</param>
<param name="maxInclusive">254</param>
</data>
</choice>
</define>
<define name="ccwSsidRange">
<data type="string">
<param name="pattern">(0x)?[0-3]</param>
</data>
</define>
<define name="ccwDevnoRange">
<choice>
<data type="string">
<param name="pattern">0x[0-9a-fA-F]{1,4}</param>
</data>
<data type="int">
<param name="minInclusive">0</param>
<param name="maxInclusive">65535</param>
</data>
</choice>
</define>
<define name="cpuset">
<data type="string">
<param name="pattern">([0-9]+(-[0-9]+)?|\^[0-9]+)(,([0-9]+(-[0-9]+)?|\^[0-9]+))*</param>
</data>
</define>
<define name="volName">
storage: use valid XML for awkward volume names $ touch /var/lib/libvirt/images/'a<b>c' $ virsh pool-refresh default $ virsh vol-dumpxml 'a<b>c' default | head -n2 <volume> <name>a<b>c</name> Oops. That's not valid XML. And when we fix the XML generation, it fails RelaxNG validation. I'm also tired of seeing <key>(null)</key> in the example output for volume xml; while we used NULLSTR() to avoid a NULL deref rather than relying on glibc's printf extension behavior, it's even better if we avoid the issue in the first place. But this requires being careful that we don't invalidate any storage backends that were relying on key being unassigned during virStoragVolCreateXML[From]. I would have split this into two patches (one for escaping, one for avoiding <key>(null)</key>), but since they both end up touching a lot of the same test files, I ended up merging it into one. Note that this patch allows pretty much any volume name that can appear in a directory (excluding . and .. because those are special), but does nothing to change the current (unenforced) RelaxNG claim that pool names will consist only of letters, numbers, _, -, and +. Tightening the C code to match RelaxNG patterns and/or relaxing the grammar to match the C code for pool names is a task for another day (but remember, we DID recently tighten C code for domain names to exclude a leading '.'). * src/conf/storage_conf.c (virStoragePoolSourceFormat) (virStoragePoolDefFormat, virStorageVolTargetDefFormat) (virStorageVolDefFormat): Escape user-controlled strings. (virStorageVolDefParseXML): Parse key, for use in unit tests. * src/storage/storage_driver.c (storageVolCreateXML) (storageVolCreateXMLFrom): Ensure parsed key doesn't confuse volume creation. * docs/schemas/basictypes.rng (volName): Relax definition. * tests/storagepoolxml2xmltest.c (mymain): Test it. * tests/storagevolxml2xmltest.c (mymain): Likewise. * tests/storagepoolxml2xmlin/pool-dir-naming.xml: New file. * tests/storagepoolxml2xmlout/pool-dir-naming.xml: Likewise. * tests/storagevolxml2xmlin/vol-file-naming.xml: Likewise. * tests/storagevolxml2xmlout/vol-file-naming.xml: Likewise. * tests/storagevolxml2xmlout/vol-*.xml: Fix fallout. Signed-off-by: Eric Blake <eblake@redhat.com>
2013-11-21 00:04:05 +00:00
<!-- directory pools allow almost any file name as a volume name -->
<data type="string">
storage: use valid XML for awkward volume names $ touch /var/lib/libvirt/images/'a<b>c' $ virsh pool-refresh default $ virsh vol-dumpxml 'a<b>c' default | head -n2 <volume> <name>a<b>c</name> Oops. That's not valid XML. And when we fix the XML generation, it fails RelaxNG validation. I'm also tired of seeing <key>(null)</key> in the example output for volume xml; while we used NULLSTR() to avoid a NULL deref rather than relying on glibc's printf extension behavior, it's even better if we avoid the issue in the first place. But this requires being careful that we don't invalidate any storage backends that were relying on key being unassigned during virStoragVolCreateXML[From]. I would have split this into two patches (one for escaping, one for avoiding <key>(null)</key>), but since they both end up touching a lot of the same test files, I ended up merging it into one. Note that this patch allows pretty much any volume name that can appear in a directory (excluding . and .. because those are special), but does nothing to change the current (unenforced) RelaxNG claim that pool names will consist only of letters, numbers, _, -, and +. Tightening the C code to match RelaxNG patterns and/or relaxing the grammar to match the C code for pool names is a task for another day (but remember, we DID recently tighten C code for domain names to exclude a leading '.'). * src/conf/storage_conf.c (virStoragePoolSourceFormat) (virStoragePoolDefFormat, virStorageVolTargetDefFormat) (virStorageVolDefFormat): Escape user-controlled strings. (virStorageVolDefParseXML): Parse key, for use in unit tests. * src/storage/storage_driver.c (storageVolCreateXML) (storageVolCreateXMLFrom): Ensure parsed key doesn't confuse volume creation. * docs/schemas/basictypes.rng (volName): Relax definition. * tests/storagepoolxml2xmltest.c (mymain): Test it. * tests/storagevolxml2xmltest.c (mymain): Likewise. * tests/storagepoolxml2xmlin/pool-dir-naming.xml: New file. * tests/storagepoolxml2xmlout/pool-dir-naming.xml: Likewise. * tests/storagevolxml2xmlin/vol-file-naming.xml: Likewise. * tests/storagevolxml2xmlout/vol-file-naming.xml: Likewise. * tests/storagevolxml2xmlout/vol-*.xml: Fix fallout. Signed-off-by: Eric Blake <eblake@redhat.com>
2013-11-21 00:04:05 +00:00
<param name="pattern">[^/]+</param>
<except>
<choice>
<value>.</value>
<value>..</value>
</choice>
</except>
</data>
</define>
<define name="archnames">
<choice>
<value>aarch64</value>
<value>alpha</value>
<value>armv6l</value>
<value>armv7l</value>
<value>cris</value>
<value>i686</value>
<value>ia64</value>
<value>lm32</value>
<value>m68k</value>
<value>microblaze</value>
<value>microblazeel</value>
<value>mips</value>
<value>mipsel</value>
<value>mips64</value>
<value>mips64el</value>
<value>openrisc</value>
<value>parisc</value>
<value>parisc64</value>
<value>ppc</value>
<value>ppc64</value>
<value>ppc64le</value>
<value>ppcemb</value>
<value>riscv32</value>
<value>riscv64</value>
<value>s390</value>
<value>s390x</value>
<value>sh4</value>
<value>sh4eb</value>
<value>sparc</value>
<value>sparc64</value>
<value>unicore32</value>
<value>x86_64</value>
<value>xtensa</value>
<value>xtensaeb</value>
</choice>
</define>
<define name="PortNumber">
<data type="int">
<param name="minInclusive">-1</param>
<param name="maxInclusive">65535</param>
</data>
</define>
<define name="sourceinfoadapter">
<element name="adapter">
<choice>
<group>
<!-- To keep back-compat, "type" is not mandatory for
scsi_host adapter -->
<optional>
<attribute name="type">
<value>scsi_host</value>
</attribute>
</optional>
storage: Introduce parentaddr into virStoragePoolSourceAdapter Between reboots and kernel reloads, the SCSI host number used for SCSI storage pools may change requiring modification to the storage pool XML in order to use a specific SCSI host adapter. This patch introduces the "parentaddr" element and "unique_id" attribute for the SCSI host adapter in order to uniquely identify the adapter between reboots and kernel reloads. For now the goal is to only parse and format the XML. Both will be required to be provided in order to uniquely identify the desired SCSI host. The new XML is expected to be as follows: <adapter type='scsi_host'> <parentaddr unique_id='3'> <address domain='0x0000' bus='0x00' slot='0x1f' func='0x2'/> </parentaddr> </adapter> where "parentaddr" is the parent device of the SCSI host using the PCI address on which the device resides and the value from the unique_id file for the device. Both the PCI address and unique_id values will be used to traverse the /sys/class/scsi_host/ directories looking at each link to match the PCI address reformatted to the directory link format where "domain:bus:slot:function" is found. Then for each matching directory the unique_id file for the scsi_host will be used to match the unique_id value in the xml. For a PCI address listed above, this will be formatted to "0000:00:1f.2" and the links in /sys/class/scsi_host will be used to find the host# to be used for the 'scsi_host' device. Each entry is a link to the /sys/bus/pci/devices directories, e.g.: % ls -al /sys/class/scsi_host/host2 lrwxrwxrwx. 1 root root 0 Jun 1 00:22 /sys/class/scsi_host/host2 -> ../../devices/pci0000:00/0000:00:1f.2/ata3/host2/scsi_host/host2 % cat /sys/class/scsi_host/host2/unique_id 3 The "parentaddr" and "name" attributes are mutually exclusive to identify the SCSI host number. Use of the "parentaddr" element will be the preferred mechanism. This patch only supports to parse and format the XMLs. Later patches will add code to find out the scsi host number.
2014-03-04 03:15:13 +00:00
<choice>
<group>
<attribute name="name">
storage: Introduce parentaddr into virStoragePoolSourceAdapter Between reboots and kernel reloads, the SCSI host number used for SCSI storage pools may change requiring modification to the storage pool XML in order to use a specific SCSI host adapter. This patch introduces the "parentaddr" element and "unique_id" attribute for the SCSI host adapter in order to uniquely identify the adapter between reboots and kernel reloads. For now the goal is to only parse and format the XML. Both will be required to be provided in order to uniquely identify the desired SCSI host. The new XML is expected to be as follows: <adapter type='scsi_host'> <parentaddr unique_id='3'> <address domain='0x0000' bus='0x00' slot='0x1f' func='0x2'/> </parentaddr> </adapter> where "parentaddr" is the parent device of the SCSI host using the PCI address on which the device resides and the value from the unique_id file for the device. Both the PCI address and unique_id values will be used to traverse the /sys/class/scsi_host/ directories looking at each link to match the PCI address reformatted to the directory link format where "domain:bus:slot:function" is found. Then for each matching directory the unique_id file for the scsi_host will be used to match the unique_id value in the xml. For a PCI address listed above, this will be formatted to "0000:00:1f.2" and the links in /sys/class/scsi_host will be used to find the host# to be used for the 'scsi_host' device. Each entry is a link to the /sys/bus/pci/devices directories, e.g.: % ls -al /sys/class/scsi_host/host2 lrwxrwxrwx. 1 root root 0 Jun 1 00:22 /sys/class/scsi_host/host2 -> ../../devices/pci0000:00/0000:00:1f.2/ata3/host2/scsi_host/host2 % cat /sys/class/scsi_host/host2/unique_id 3 The "parentaddr" and "name" attributes are mutually exclusive to identify the SCSI host number. Use of the "parentaddr" element will be the preferred mechanism. This patch only supports to parse and format the XMLs. Later patches will add code to find out the scsi host number.
2014-03-04 03:15:13 +00:00
<text/>
</attribute>
</group>
<group>
<interleave>
<element name="parentaddr">
<optional>
<attribute name="unique_id">
<ref name="positiveInteger"/>
storage: Introduce parentaddr into virStoragePoolSourceAdapter Between reboots and kernel reloads, the SCSI host number used for SCSI storage pools may change requiring modification to the storage pool XML in order to use a specific SCSI host adapter. This patch introduces the "parentaddr" element and "unique_id" attribute for the SCSI host adapter in order to uniquely identify the adapter between reboots and kernel reloads. For now the goal is to only parse and format the XML. Both will be required to be provided in order to uniquely identify the desired SCSI host. The new XML is expected to be as follows: <adapter type='scsi_host'> <parentaddr unique_id='3'> <address domain='0x0000' bus='0x00' slot='0x1f' func='0x2'/> </parentaddr> </adapter> where "parentaddr" is the parent device of the SCSI host using the PCI address on which the device resides and the value from the unique_id file for the device. Both the PCI address and unique_id values will be used to traverse the /sys/class/scsi_host/ directories looking at each link to match the PCI address reformatted to the directory link format where "domain:bus:slot:function" is found. Then for each matching directory the unique_id file for the scsi_host will be used to match the unique_id value in the xml. For a PCI address listed above, this will be formatted to "0000:00:1f.2" and the links in /sys/class/scsi_host will be used to find the host# to be used for the 'scsi_host' device. Each entry is a link to the /sys/bus/pci/devices directories, e.g.: % ls -al /sys/class/scsi_host/host2 lrwxrwxrwx. 1 root root 0 Jun 1 00:22 /sys/class/scsi_host/host2 -> ../../devices/pci0000:00/0000:00:1f.2/ata3/host2/scsi_host/host2 % cat /sys/class/scsi_host/host2/unique_id 3 The "parentaddr" and "name" attributes are mutually exclusive to identify the SCSI host number. Use of the "parentaddr" element will be the preferred mechanism. This patch only supports to parse and format the XMLs. Later patches will add code to find out the scsi host number.
2014-03-04 03:15:13 +00:00
</attribute>
</optional>
<element name="address">
<ref name="pciaddress"/>
</element>
</element>
</interleave>
</group>
</choice>
</group>
<group>
<attribute name="type">
<value>fc_host</value>
</attribute>
<optional>
<attribute name="parent">
<text/>
</attribute>
</optional>
storage: Introduce 'managed' for the fchost parent https://bugzilla.redhat.com/show_bug.cgi?id=1160926 Introduce a 'managed' attribute to allow libvirt to decide whether to delete a vHBA vport created via external means such as nodedev-create. The code currently decides whether to delete the vHBA based solely on whether the parent was provided at creation time. However, that may not be the desired action, so rather than delete and force someone to create another vHBA via an additional nodedev-create allow the configuration of the storage pool to decide the desired action. During createVport when libvirt does the VPORT_CREATE, set the managed value to YES if not already set to indicate to the deleteVport code that it should delete the vHBA when the pool is destroyed. If libvirtd is restarted all the memory only state was lost, so for a persistent storage pool, use the virStoragePoolSaveConfig in order to write out the managed value. Because we're now saving the current configuration, we need to be sure to not save the parent in the output XML if it was undefined at start. Saving the name would cause future starts to always use the same parent which is not the expected result when not providing a parent. By not providing a parent, libvirt is expected to find the best available vHBA port for each subsequent (re)start. At deleteVport, use the new managed value to decide whether to execute the VPORT_DELETE. Since we no longer save the parent in memory or in XML when provided, if it was not provided, then we have to look it up.
2014-11-10 16:19:51 +00:00
<optional>
<attribute name="managed">
storage: Introduce 'managed' for the fchost parent https://bugzilla.redhat.com/show_bug.cgi?id=1160926 Introduce a 'managed' attribute to allow libvirt to decide whether to delete a vHBA vport created via external means such as nodedev-create. The code currently decides whether to delete the vHBA based solely on whether the parent was provided at creation time. However, that may not be the desired action, so rather than delete and force someone to create another vHBA via an additional nodedev-create allow the configuration of the storage pool to decide the desired action. During createVport when libvirt does the VPORT_CREATE, set the managed value to YES if not already set to indicate to the deleteVport code that it should delete the vHBA when the pool is destroyed. If libvirtd is restarted all the memory only state was lost, so for a persistent storage pool, use the virStoragePoolSaveConfig in order to write out the managed value. Because we're now saving the current configuration, we need to be sure to not save the parent in the output XML if it was undefined at start. Saving the name would cause future starts to always use the same parent which is not the expected result when not providing a parent. By not providing a parent, libvirt is expected to find the best available vHBA port for each subsequent (re)start. At deleteVport, use the new managed value to decide whether to execute the VPORT_DELETE. Since we no longer save the parent in memory or in XML when provided, if it was not provided, then we have to look it up.
2014-11-10 16:19:51 +00:00
<ref name="virYesNo"/>
</attribute>
</optional>
<optional>
<attribute name="parent_wwnn">
<ref name="wwn"/>
</attribute>
</optional>
<optional>
<attribute name="parent_wwpn">
<ref name="wwn"/>
</attribute>
</optional>
<optional>
<attribute name="parent_fabric_wwn">
<ref name="wwn"/>
</attribute>
storage: Introduce 'managed' for the fchost parent https://bugzilla.redhat.com/show_bug.cgi?id=1160926 Introduce a 'managed' attribute to allow libvirt to decide whether to delete a vHBA vport created via external means such as nodedev-create. The code currently decides whether to delete the vHBA based solely on whether the parent was provided at creation time. However, that may not be the desired action, so rather than delete and force someone to create another vHBA via an additional nodedev-create allow the configuration of the storage pool to decide the desired action. During createVport when libvirt does the VPORT_CREATE, set the managed value to YES if not already set to indicate to the deleteVport code that it should delete the vHBA when the pool is destroyed. If libvirtd is restarted all the memory only state was lost, so for a persistent storage pool, use the virStoragePoolSaveConfig in order to write out the managed value. Because we're now saving the current configuration, we need to be sure to not save the parent in the output XML if it was undefined at start. Saving the name would cause future starts to always use the same parent which is not the expected result when not providing a parent. By not providing a parent, libvirt is expected to find the best available vHBA port for each subsequent (re)start. At deleteVport, use the new managed value to decide whether to execute the VPORT_DELETE. Since we no longer save the parent in memory or in XML when provided, if it was not provided, then we have to look it up.
2014-11-10 16:19:51 +00:00
</optional>
<attribute name="wwnn">
<ref name="wwn"/>
</attribute>
<attribute name="wwpn">
<ref name="wwn"/>
</attribute>
</group>
</choice>
<empty/>
</element>
</define>
<define name="isaaddress">
<optional>
<attribute name="iobase">
<data type="string">
<param name="pattern">0x[a-fA-F0-9]{1,4}</param>
</data>
</attribute>
</optional>
<optional>
<attribute name="irq">
<data type="string">
<param name="pattern">0x[a-fA-F0-9]</param>
</data>
</attribute>
</optional>
</define>
<define name="link-speed-state">
<optional>
<element name="link">
<optional>
<attribute name="speed">
<ref name="unsignedInt"/>
</attribute>
</optional>
<optional>
<attribute name="state">
<choice>
<value>unknown</value>
<value>notpresent</value>
<value>down</value>
<value>lowerlayerdown</value>
<value>testing</value>
<value>dormant</value>
<value>up</value>
</choice>
</attribute>
</optional>
</element>
</optional>
</define>
<define name="virYesNo">
<choice>
<value>yes</value>
<value>no</value>
</choice>
</define>
<define name="virOnOff">
<choice>
<value>on</value>
<value>off</value>
</choice>
</define>
<define name="metadata">
<element name="metadata">
<zeroOrMore>
<ref name="customElement"/>
</zeroOrMore>
</element>
</define>
<define name="customElement">
<element>
<anyName/>
<zeroOrMore>
<choice>
<attribute>
<anyName/>
</attribute>
<text/>
<ref name="customElement"/>
</choice>
</zeroOrMore>
</element>
</define>
<define name="leaseUnit">
<choice>
<value>seconds</value>
<value>minutes</value>
<value>hours</value>
</choice>
</define>
</grammar>