2011-06-26 13:13:10 +04:00
<?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>
xml: share 'unit' in RNG
The code supported unit='E' for "exabyte", but the RNG did not;
conversely, the RNG supported "z" and "y" but the code did not
(I'm jealous if you have that much storage, particularly since
it won't fit in 64-bit off_t). Also, the code supported
<allocation unit='...'>, but not the RNG.
In an effort to make 'unit' more worthwhile in future patches,
it's easier to share it between files.
In making this factorization, note that absFilePath is more
permissive than 'path', so storage pools and storage volumes
will now validate with a wider set of file names than before.
I don't think this should be a problem in practice.
* docs/schemas/storagepool.rng: Include basic types, rather than
repeating things here.
* docs/schemas/storagevol.rng: Likewise.
* docs/schemas/basictypes.rng: Add 'unsignedLong', 'unit', and fix
to match storage code.
2012-02-29 08:16:28 +04:00
<define name='unsignedLong'>
<data type='unsignedLong'>
<param name='pattern'>[0-9]+</param>
</data>
</define>
2011-06-26 13:13:10 +04:00
2014-12-11 16:50:11 +03:00
<define name='hexuint'>
<data type='string'>
<param name="pattern">(0x)?[0-9a-f]+</param>
</data>
</define>
2011-06-26 13:13:10 +04:00
<define name="positiveInteger">
<data type="positiveInteger">
<param name="pattern">[0-9]+</param>
</data>
</define>
2013-02-26 12:14:20 +04:00
<define name='octalMode'>
<data type="unsignedInt">
<param name='pattern'>[0-7]+</param>
</data>
</define>
2016-03-22 19:00:40 +03:00
<define name="uint8">
2011-06-26 13:13:10 +04:00
<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>
2016-03-22 19:10:16 +03:00
<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>
2016-03-22 19:00:40 +03:00
<define name="uint24">
2011-06-26 13:13:10 +04:00
<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="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>
2012-08-16 19:41:41 +04:00
<define name="pciaddress">
<optional>
<attribute name="domain">
<ref name="pciDomain"/>
</attribute>
</optional>
conf: allow type='pci' addresses with no address attributes specified
Prior to this, <address type='pci'/> wasn't allowed when parsing
(domain+bus+slot+function needed to be a "valid" PCI address, meaning
that at least one of domain/bus/slot had to be non-0), the RNG
required bus to be specified, and if type was set to PCI when
formatting, domain+bus+slot+function would always be output.
This makes all the address attributes optional during parse and RNG
validation, and suppresses domain+bus+slot+function if domain+bus+slot
are all 0 (NB: if d+b+s are all 0, any value for function is
nonsensical as that will never happen in the real world, and after
the next patch we will always assign a real working address to any
empty PCI address before it is ever output to anywhere).
Note that explicitly setting all attributes to 0 is equivalent to
setting none of them, which is okay, since 0000:00:00 is reserved in
any PCI bus setup, and can't be used anyway.
2016-05-17 21:03:00 +03:00
<optional>
<attribute name="bus">
<ref name="pciBus"/>
</attribute>
</optional>
2016-03-22 18:38:53 +03:00
<optional>
<attribute name="slot">
<ref name="pciSlot"/>
</attribute>
</optional>
<optional>
<attribute name="function">
<ref name="pciFunc"/>
</attribute>
</optional>
2012-08-16 19:41:41 +04:00
<optional>
<attribute name="multifunction">
2014-09-08 10:06:35 +04:00
<ref name="virOnOff"/>
2012-08-16 19:41:41 +04:00
</attribute>
</optional>
</define>
2011-06-26 13:13:10 +04:00
<!-- a 6 byte MAC address in ASCII-hex format, eg "12:34:56:78:9A:BC" -->
2012-03-19 20:49:17 +04:00
<!-- 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>
2011-06-26 13:13:10 +04:00
<define name="macAddr">
<data type="string">
2012-03-19 20:49:17 +04:00
<param name="pattern">[a-fA-F0-9]{2}(:[a-fA-F0-9]{2}){5}</param>
2011-06-26 13:13:10 +04:00
</data>
</define>
2013-02-15 23:02:26 +04:00
<!--====================================================================-->
<!--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 -->
2015-03-19 18:53:00 +03:00
<!--RFC6355. These standards actually require the duid to be fixed for -->
2013-02-15 23:02:26 +04:00
<!--the hardward 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>
<!--======================================================================-->
2011-06-26 13:13:10 +04:00
<!-- 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 -->
2015-01-14 12:42:19 +03:00
<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>
2011-06-26 13:13:10 +04:00
</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>
2011-10-29 01:19:34 +04:00
<define name="genericName">
<data type="string">
<param name="pattern">[a-zA-Z0-9_\+\-]+</param>
</data>
</define>
2011-06-26 13:13:10 +04:00
<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="filePath">
<data type="string">
2016-08-12 11:52:30 +03:00
<param name="pattern">.+</param>
2011-06-26 13:13:10 +04:00
</data>
</define>
2014-05-28 17:47:38 +04:00
<define name="dirPath">
<data type="string">
2016-08-12 11:52:30 +03:00
<param name="pattern">.+</param>
2014-05-28 17:47:38 +04:00
</data>
</define>
2011-06-26 13:13:10 +04:00
<define name="absFilePath">
<data type="string">
2016-08-12 11:52:30 +03:00
<param name="pattern">/.+</param>
2011-06-26 13:13:10 +04:00
</data>
</define>
<define name="absDirPath">
<data type="string">
2016-08-12 11:52:30 +03:00
<param name="pattern">/.*</param>
2011-06-26 13:13:10 +04:00
</data>
</define>
xml: share 'unit' in RNG
The code supported unit='E' for "exabyte", but the RNG did not;
conversely, the RNG supported "z" and "y" but the code did not
(I'm jealous if you have that much storage, particularly since
it won't fit in 64-bit off_t). Also, the code supported
<allocation unit='...'>, but not the RNG.
In an effort to make 'unit' more worthwhile in future patches,
it's easier to share it between files.
In making this factorization, note that absFilePath is more
permissive than 'path', so storage pools and storage volumes
will now validate with a wider set of file names than before.
I don't think this should be a problem in practice.
* docs/schemas/storagepool.rng: Include basic types, rather than
repeating things here.
* docs/schemas/storagevol.rng: Likewise.
* docs/schemas/basictypes.rng: Add 'unsignedLong', 'unit', and fix
to match storage code.
2012-02-29 08:16:28 +04:00
<define name='unit'>
<data type='string'>
2012-03-06 01:06:33 +04:00
<param name='pattern'>([bB]([yY][tT][eE][sS]?)?)|([kKmMgGtTpPeE]([iI]?[bB])?)</param>
xml: share 'unit' in RNG
The code supported unit='E' for "exabyte", but the RNG did not;
conversely, the RNG supported "z" and "y" but the code did not
(I'm jealous if you have that much storage, particularly since
it won't fit in 64-bit off_t). Also, the code supported
<allocation unit='...'>, but not the RNG.
In an effort to make 'unit' more worthwhile in future patches,
it's easier to share it between files.
In making this factorization, note that absFilePath is more
permissive than 'path', so storage pools and storage volumes
will now validate with a wider set of file names than before.
I don't think this should be a problem in practice.
* docs/schemas/storagepool.rng: Include basic types, rather than
repeating things here.
* docs/schemas/storagevol.rng: Likewise.
* docs/schemas/basictypes.rng: Add 'unsignedLong', 'unit', and fix
to match storage code.
2012-02-29 08:16:28 +04:00
</data>
</define>
2012-02-23 04:48:38 +04:00
<define name='scaledInteger'>
<optional>
<attribute name='unit'>
<ref name='unit'/>
</attribute>
</optional>
<ref name='unsignedLong'/>
</define>
xml: share 'unit' in RNG
The code supported unit='E' for "exabyte", but the RNG did not;
conversely, the RNG supported "z" and "y" but the code did not
(I'm jealous if you have that much storage, particularly since
it won't fit in 64-bit off_t). Also, the code supported
<allocation unit='...'>, but not the RNG.
In an effort to make 'unit' more worthwhile in future patches,
it's easier to share it between files.
In making this factorization, note that absFilePath is more
permissive than 'path', so storage pools and storage volumes
will now validate with a wider set of file names than before.
I don't think this should be a problem in practice.
* docs/schemas/storagepool.rng: Include basic types, rather than
repeating things here.
* docs/schemas/storagevol.rng: Likewise.
* docs/schemas/basictypes.rng: Add 'unsignedLong', 'unit', and fix
to match storage code.
2012-02-29 08:16:28 +04:00
2012-08-16 19:41:41 +04:00
<define name="pciDomain">
2016-03-22 19:24:08 +03:00
<ref name="uint16"/>
2012-08-16 19:41:41 +04:00
</define>
<define name="pciBus">
2016-03-22 19:24:08 +03:00
<ref name="uint8"/>
2012-08-16 19:41:41 +04:00
</define>
<define name="pciSlot">
2016-03-22 19:24:08 +03:00
<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>
2012-08-16 19:41:41 +04:00
</define>
<define name="pciFunc">
2016-03-22 19:24:08 +03:00
<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>
2012-08-16 19:41:41 +04:00
</define>
2012-09-11 12:57:01 +04:00
<define name='wwn'>
<data type='string'>
qemu: Allow the disk wwn to have "0x" prefix
The recent qemu requires "0x" prefix for the disk wwn, this patch
changes virValidateWWN to allow the prefix, and prepend "0x" if
it's not specified. E.g.
qemu-kvm: -device scsi-hd,bus=scsi0.0,channel=0,scsi-id=0,lun=0,\
drive=drive-scsi0-0-0-0,id=scsi0-0-0-0,wwn=6000c60016ea71ad:
Property 'scsi-hd.wwn' doesn't take value '6000c60016ea71ad'
Though it's a qemu regression, but it's nice to allow the prefix,
and doesn't hurt for us to always output "0x".
2013-04-17 17:23:44 +04:00
<param name='pattern'>(0x)?[0-9a-fA-F]{16}</param>
2012-09-11 12:57:01 +04:00
</data>
</define>
2017-05-22 09:38:22 +03:00
<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>
2013-01-18 22:29:40 +04:00
<define name="cpuset">
<data type="string">
<param name="pattern">([0-9]+(-[0-9]+)?|\^[0-9]+)(,([0-9]+(-[0-9]+)?|\^[0-9]+))*</param>
</data>
</define>
2013-01-23 15:04:34 +04:00
<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 04:04:05 +04:00
<!-- directory pools allow almost any file name as a volume name -->
2013-01-23 15:04:34 +04:00
<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 04:04:05 +04:00
<param name="pattern">[^/]+</param>
<except>
<choice>
<value>.</value>
<value>..</value>
</choice>
</except>
2013-01-23 15:04:34 +04:00
</data>
</define>
2013-02-21 15:20:25 +04:00
<define name='archnames'>
<choice>
2013-10-08 17:49:11 +04:00
<value>aarch64</value>
2013-02-21 15:20:25 +04:00
<value>alpha</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>
2015-02-26 17:10:58 +03:00
<value>ppc64le</value>
2013-02-21 15:20:25 +04:00
<value>ppcemb</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>
2013-04-09 06:32:41 +04:00
<define name="PortNumber">
2015-04-23 13:49:23 +03:00
<data type="int">
2013-04-09 06:32:41 +04:00
<param name="minInclusive">-1</param>
2015-04-23 13:49:23 +03:00
<param name="maxInclusive">65535</param>
2013-04-09 06:32:41 +04:00
</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>
2014-03-04 07:15:13 +04:00
<choice>
<group>
<attribute name='name'>
<text/>
</attribute>
</group>
<group>
<interleave>
<element name="parentaddr">
<optional>
<attribute name='unique_id'>
<ref name='positiveInteger'/>
</attribute>
</optional>
<element name="address">
<ref name="pciaddress"/>
</element>
</element>
</interleave>
</group>
</choice>
2013-04-09 06:32:41 +04:00
</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 19:19:51 +03:00
<optional>
<attribute name='managed'>
<ref name="virYesNo"/>
</attribute>
2016-11-18 01:48:35 +03:00
</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 19:19:51 +03:00
</optional>
2013-04-09 06:32:41 +04:00
<attribute name='wwnn'>
<ref name='wwn'/>
</attribute>
<attribute name='wwpn'>
<ref name='wwn'/>
</attribute>
</group>
</choice>
<empty/>
</element>
</define>
2013-12-09 13:11:13 +04:00
<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>
2014-05-07 16:21:35 +04:00
<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>
2014-09-08 10:06:35 +04:00
<define name="virYesNo">
<choice>
<value>yes</value>
<value>no</value>
</choice>
</define>
<define name="virOnOff">
<choice>
<value>on</value>
<value>off</value>
</choice>
</define>
2016-06-23 01:05:50 +03:00
<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>
2011-06-26 13:13:10 +04:00
</grammar>
