External/libvirt
1
0
Fork 0
mirror of https://gitlab.com/libvirt/libvirt.git synced 2024-12-27 16:15:23 +00:00
Code Issues Packages Projects Releases Wiki Activity
8ff41608f1
libvirt/docs/schemas/networkcommon.rng

250 lines
6.9 KiB
Plaintext
Raw Normal View History

conf: put virtPortProfile struct / functions in a common location virtPortProfiles are currently only used in the domain XML, but will soon also be used in the network XML. To prepare for that change, this patch moves the structure definition into util/network.h and the parse and format functions into util/network.c (I decided that this was a better choice than macvtap.h/c for something that needed to always be available on all platforms).
2011-06-29 04:38:10 +00: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">
<define name="virtualPortProfileID">
<data type="string">
<param name="maxLength">39</param>
</data>
</define>
<define name="virtualPortProfile">
<choice>
<group>
<element name="virtualport">
<attribute name="type">
<value>802.1Qbg</value>
</attribute>
conf: support partially-specified <virtualport> in parser and formatter Until now, all attributes in a <virtualport> parameter list that were acceptable for a particular type, were also required. There were no optional attributes. One of the aims of supporting <virtualport> in libvirt's virtual networks and portgroups is to allow specifying the group-wide parameters in the network's virtualport, and merge that with the interface's virtualport, which will have the instance-specific info (i.e. the interfaceid or instanceid). Additionally, the guest's interface XML shouldn't need to know what type of network connection will be used prior to runtime - it could be openvswitch, 802.1Qbh, 802.1Qbg, or none of the above - but should still be able to specify instance-specific info just in case it turns out to be applicable. Finally, up to now, the parser for virtualport has always generated a random instanceid/interfaceid when appropriate, making it impossible to leave it blank (which is what's required for virtualports within a network/portprofile definition). This patch modifies the parser and formatter of the <virtualport> element in the following ways: * because most of the attributes in a virNetDevVPortProfile are fixed size binary data with no reserved values, there is no way to embed a "this value wasn't specified" sentinel into the existing data. To solve this problem, the new *_specified fields in the virNetDevVPortProfile object that were added in a previous patch of this series are now set when the corresponding attribute is present during the parse. * allow parsing/formatting a <virtualport> that has no type set. In this case, all fields are settable, but all are also optional. * add a GENERATE_MISSING_DEFAULTS flag to the parser - if this flag is set and an instanceid/interfaceid is expected but not provided, a random one will be generated. This was previously the default behavior, but is now done only for virtualports inside an <interface> definition, not for those in <network> or <portgroup>. * add a REQUIRE_ALL_ATTRIBUTES flag to the parser - if this flag is set the parser will call the new virNetDevVPortProfileCheckComplete() functions at the end of the parser to check for any missing attributes (based on type), and return failure if anything is missing. This used to be default behavior. Now it is only used for the virtualport defined inside an interface's <actual> element (by the time you've figured out the contents of <actual>, you should have all the necessary data to fill in the entire virtualport) * add a REQUIRE_TYPE flag to the parser - if this flag is set, the parser will return an error if the virtualport has no type attribute. This also was previously the default behavior, but isn't needed in the case of the virtualport for a type='network' interface (i.e. the exact type isn't yet known), or the virtualport of a portgroup (i.e. the portgroup just has modifiers for the network's virtualport, which *does* require a type) - in those cases, the check will be done at domain startup, once the final virtualport is assembled (this is handled in the next patch).
2012-07-31 18:36:51 +00:00
<optional>
<element name="parameters">
<optional>
<attribute name="managerid">
<ref name="uint8range"/>
</attribute>
</optional>
<optional>
<attribute name="typeid">
<ref name="uint24range"/>
</attribute>
</optional>
<optional>
<attribute name="typeidversion">
<ref name="uint8range"/>
</attribute>
</optional>
<optional>
<attribute name="instanceid">
<ref name="UUID"/>
</attribute>
</optional>
</element>
</optional>
conf: put virtPortProfile struct / functions in a common location virtPortProfiles are currently only used in the domain XML, but will soon also be used in the network XML. To prepare for that change, this patch moves the structure definition into util/network.h and the parse and format functions into util/network.c (I decided that this was a better choice than macvtap.h/c for something that needed to always be available on all platforms).
2011-06-29 04:38:10 +00:00
</element>
</group>
<group>
<element name="virtualport">
<attribute name="type">
<value>802.1Qbh</value>
</attribute>
conf: support partially-specified <virtualport> in parser and formatter Until now, all attributes in a <virtualport> parameter list that were acceptable for a particular type, were also required. There were no optional attributes. One of the aims of supporting <virtualport> in libvirt's virtual networks and portgroups is to allow specifying the group-wide parameters in the network's virtualport, and merge that with the interface's virtualport, which will have the instance-specific info (i.e. the interfaceid or instanceid). Additionally, the guest's interface XML shouldn't need to know what type of network connection will be used prior to runtime - it could be openvswitch, 802.1Qbh, 802.1Qbg, or none of the above - but should still be able to specify instance-specific info just in case it turns out to be applicable. Finally, up to now, the parser for virtualport has always generated a random instanceid/interfaceid when appropriate, making it impossible to leave it blank (which is what's required for virtualports within a network/portprofile definition). This patch modifies the parser and formatter of the <virtualport> element in the following ways: * because most of the attributes in a virNetDevVPortProfile are fixed size binary data with no reserved values, there is no way to embed a "this value wasn't specified" sentinel into the existing data. To solve this problem, the new *_specified fields in the virNetDevVPortProfile object that were added in a previous patch of this series are now set when the corresponding attribute is present during the parse. * allow parsing/formatting a <virtualport> that has no type set. In this case, all fields are settable, but all are also optional. * add a GENERATE_MISSING_DEFAULTS flag to the parser - if this flag is set and an instanceid/interfaceid is expected but not provided, a random one will be generated. This was previously the default behavior, but is now done only for virtualports inside an <interface> definition, not for those in <network> or <portgroup>. * add a REQUIRE_ALL_ATTRIBUTES flag to the parser - if this flag is set the parser will call the new virNetDevVPortProfileCheckComplete() functions at the end of the parser to check for any missing attributes (based on type), and return failure if anything is missing. This used to be default behavior. Now it is only used for the virtualport defined inside an interface's <actual> element (by the time you've figured out the contents of <actual>, you should have all the necessary data to fill in the entire virtualport) * add a REQUIRE_TYPE flag to the parser - if this flag is set, the parser will return an error if the virtualport has no type attribute. This also was previously the default behavior, but isn't needed in the case of the virtualport for a type='network' interface (i.e. the exact type isn't yet known), or the virtualport of a portgroup (i.e. the portgroup just has modifiers for the network's virtualport, which *does* require a type) - in those cases, the check will be done at domain startup, once the final virtualport is assembled (this is handled in the next patch).
2012-07-31 18:36:51 +00:00
<optional>
<element name="parameters">
<optional>
<attribute name="profileid">
<ref name="virtualPortProfileID"/>
</attribute>
</optional>
</element>
</optional>
</element>
</group>
<group>
<element name="virtualport">
<attribute name="type">
<value>openvswitch</value>
</attribute>
<optional>
<element name="parameters">
<optional>
<attribute name="profileid">
<ref name="virtualPortProfileID"/>
</attribute>
</optional>
<optional>
<attribute name="interfaceid">
<ref name="UUID"/>
</attribute>
</optional>
</element>
</optional>
</element>
</group>
<group>
<!-- use this when no type attribute is present -->
<element name="virtualport">
<optional>
<element name="parameters">
<optional>
<attribute name="managerid">
<ref name="uint8range"/>
</attribute>
</optional>
<optional>
<attribute name="typeid">
<ref name="uint24range"/>
</attribute>
</optional>
<optional>
<attribute name="typeidversion">
<ref name="uint8range"/>
</attribute>
</optional>
<optional>
<attribute name="instanceid">
<ref name="UUID"/>
</attribute>
</optional>
<optional>
<attribute name="profileid">
<ref name="virtualPortProfileID"/>
</attribute>
</optional>
<optional>
<attribute name="interfaceid">
<ref name="UUID"/>
</attribute>
</optional>
</element>
</optional>
conf: put virtPortProfile struct / functions in a common location virtPortProfiles are currently only used in the domain XML, but will soon also be used in the network XML. To prepare for that change, this patch moves the structure definition into util/network.h and the parse and format functions into util/network.c (I decided that this was a better choice than macvtap.h/c for something that needed to always be available on all platforms).
2011-06-29 04:38:10 +00:00
</element>
</group>
</choice>
</define>
bandwidth: Define schema and create documentation Define new 'bandwidth' element with possible child element 'inbound' and 'outbound' addressing incoming and outgoing traffic respectively: <bandwidth> <inbound average='1000' peak='2000' burst='5120'/> <outbound average='500'/> </bandwidth> Leaving any element out means not to shape traffic in that direction. The units for average and peak (rate) are in kilobytes per second, for burst (size) are just in kilobytes. This element can be inserted into domain's 'interface' and 'network'.
2011-07-22 14:07:23 +00:00
<define name="bandwidth">
<element name="bandwidth">
<interleave>
<optional>
<element name="inbound">
<ref name="bandwidth-attributes"/>
<empty/>
</element>
</optional>
<optional>
<element name="outbound">
<ref name="bandwidth-attributes"/>
<empty/>
</element>
</optional>
</interleave>
</element>
</define>
<define name="bandwidth-attributes">
<attribute name="average">
<ref name="speed"/>
</attribute>
<optional>
<attribute name="peak">
<ref name="speed"/>
</attribute>
</optional>
bandwidth: add new 'floor' attribute This is however supported only on domain interfaces with type='network'. Moreover, target network needs to have at least inbound QoS set. This is required by hierarchical traffic shaping. From now on, the required attribute for <inbound/> is either 'average' (old) or 'floor' (new). This new attribute can be used just for interfaces type of network (<interface type='network'/>) currently.
2012-11-16 09:37:15 +00:00
<optional>
<attribute name="floor">
<ref name="speed"/>
</attribute>
</optional>
bandwidth: Define schema and create documentation Define new 'bandwidth' element with possible child element 'inbound' and 'outbound' addressing incoming and outgoing traffic respectively: <bandwidth> <inbound average='1000' peak='2000' burst='5120'/> <outbound average='500'/> </bandwidth> Leaving any element out means not to shape traffic in that direction. The units for average and peak (rate) are in kilobytes per second, for burst (size) are just in kilobytes. This element can be inserted into domain's 'interface' and 'network'.
2011-07-22 14:07:23 +00:00
<optional>
<attribute name='burst'>
<ref name="BurstSize"/>
</attribute>
</optional>
</define>
<define name="speed">
<data type="unsignedInt">
<param name="pattern">[0-9]+</param>
<param name="minInclusive">1</param>
</data>
</define>
<define name="BurstSize">
<data type="unsignedInt">
<param name="pattern">[0-9]+</param>
<param name="minInclusive">1</param>
</data>
</define>
Implement DNS SRV record into the bridge driver Hi, this is the fifth version of my SRV record for DNSMasq patch rebased for the current codebase to the bridge driver and libvirt XML file to include support for the SRV records in the DNS. The syntax is based on DNSMasq man page and tests for both xml2xml and xml2argv were added as well. There are some things written a better way in comparison with version 4, mainly there's no hack in tests/networkxml2argvtest.c and also the xPath context is changed to use a simpler query using the virXPathInt() function relative to the current node. Also, the patch is also fixing the networkxml2argv test to pass both checks, i.e. both unit tests and also syntax check. Please review, Michal Signed-off-by: Michal Novotny <minovotn@redhat.com>
2012-01-02 14:23:54 +00:00
<define name='unsignedShort'>
<data type='integer'>
<param name="minInclusive">0</param>
<param name="maxInclusive">65535</param>
</data>
</define>
<define name='protocol'>
<data type='string'>
<param name='pattern'>(tcp)|(udp)</param>
</data>
</define>
<define name='addr-family'>
<data type='string'>
<param name="pattern">(ipv4)|(ipv6)</param>
</data>
</define>
conf: add <vlan> element to network and domain interface elements The following config elements now support a <vlan> subelements: within a domain: <interface>, and the <actual> subelement of <interface> within a network: the toplevel, as well as any <portgroup> Each vlan element must have one or more <tag id='n'/> subelements. If there is more than one tag, it is assumed that vlan trunking is being requested. If trunking is required with only a single tag, the attribute "trunk='yes'" should be added to the toplevel <vlan> element. Some examples: <interface type='hostdev'/> <vlan> <tag id='42'/> </vlan> <mac address='52:54:00:12:34:56'/> ... </interface> <network> <name>vlan-net</name> <vlan trunk='yes'> <tag id='30'/> </vlan> <virtualport type='openvswitch'/> </network> <interface type='network'/> <source network='vlan-net'/> ... </interface> <network> <name>trunk-vlan</name> <vlan> <tag id='42'/> <tag id='43'/> </vlan> ... </network> <network> <name>multi</name> ... <portgroup name='production'/> <vlan> <tag id='42'/> </vlan> </portgroup> <portgroup name='test'/> <vlan> <tag id='666'/> </vlan> </portgroup> </network> <interface type='network'/> <source network='multi' portgroup='test'/> ... </interface> IMPORTANT NOTE: As of this patch there is no backend support for the vlan element for *any* network device type. When support is added in later patches, it will only be for those select network types that support setting up a vlan on the host side, without the guest's involvement. (For example, it will be possible to configure a vlan for a guest connected to an openvswitch bridge, but it won't be possible to do that for one that is connected to a standard Linux host bridge.)
2012-08-12 07:51:30 +00:00
<define name="vlan">
<element name="vlan">
<optional>
<attribute name="trunk">
<value>yes</value>
</attribute>
</optional>
<oneOrMore>
<element name="tag">
<attribute name="id">
<data type="unsignedInt">
<param name="maxInclusive">4095</param>
</data>
</attribute>
Configure native vlan modes on Open vSwitch ports This patch adds functionality to allow libvirt to configure the 'native-tagged' and 'native-untagged' modes on openvswitch networks. Signed-off-by: Laine Stump <laine@redhat.com>
2013-05-23 17:12:10 +00:00
<optional>
<attribute name="nativeMode">
<choice>
<value>tagged</value>
<value>untagged</value>
</choice>
</attribute>
</optional>
conf: add <vlan> element to network and domain interface elements The following config elements now support a <vlan> subelements: within a domain: <interface>, and the <actual> subelement of <interface> within a network: the toplevel, as well as any <portgroup> Each vlan element must have one or more <tag id='n'/> subelements. If there is more than one tag, it is assumed that vlan trunking is being requested. If trunking is required with only a single tag, the attribute "trunk='yes'" should be added to the toplevel <vlan> element. Some examples: <interface type='hostdev'/> <vlan> <tag id='42'/> </vlan> <mac address='52:54:00:12:34:56'/> ... </interface> <network> <name>vlan-net</name> <vlan trunk='yes'> <tag id='30'/> </vlan> <virtualport type='openvswitch'/> </network> <interface type='network'/> <source network='vlan-net'/> ... </interface> <network> <name>trunk-vlan</name> <vlan> <tag id='42'/> <tag id='43'/> </vlan> ... </network> <network> <name>multi</name> ... <portgroup name='production'/> <vlan> <tag id='42'/> </vlan> </portgroup> <portgroup name='test'/> <vlan> <tag id='666'/> </vlan> </portgroup> </network> <interface type='network'/> <source network='multi' portgroup='test'/> ... </interface> IMPORTANT NOTE: As of this patch there is no backend support for the vlan element for *any* network device type. When support is added in later patches, it will only be for those select network types that support setting up a vlan on the host side, without the guest's involvement. (For example, it will be possible to configure a vlan for a guest connected to an openvswitch bridge, but it won't be possible to do that for one that is connected to a standard Linux host bridge.)
2012-08-12 07:51:30 +00:00
<empty/>
</element>
</oneOrMore>
</element>
</define>
Add '<nat>' element to '<forward>' network schemas Commits 905629f4 and 1716e7a6 have added support for specifying an IPv4 range and a port range to be used by NAT: <forward mode='nat'> <nat> <address start='10.20.30.40' end='10.20.30.44'/> <port start='60000' end='65432'/> </nat> </forward> https://bugzilla.redhat.com/show_bug.cgi?id=1004364
2013-09-05 09:08:38 +00:00
<define name='port'>
<data type='integer'>
<param name='minInclusive'>1</param>
<param name='maxInclusive'>65535</param>
</data>
</define>
Move network route definition to networkcommon.rng Moving network route to the network common schema will allow reusing it.
2015-01-14 09:51:52 +00:00
<!-- The (static) route element specifies a network address and gateway
address to access that network. Both the network address and
the gateway address must be specified. -->
Use the network route definitions for domains
2015-01-14 15:15:57 +00:00
<define name='route'>
Move network route definition to networkcommon.rng Moving network route to the network common schema will allow reusing it.
2015-01-14 09:51:52 +00:00
<element name="route">
<optional>
<attribute name="family"><ref name="addr-family"/></attribute>
</optional>
<attribute name="address"><ref name="ipAddr"/></attribute>
<optional>
<choice>
<attribute name="netmask"><ref name="ipv4Addr"/></attribute>
<attribute name="prefix"><ref name="ipPrefix"/></attribute>
</choice>
</optional>
<attribute name="gateway"><ref name="ipAddr"/></attribute>
<optional>
<attribute name="metric"><ref name="unsignedInt"/></attribute>
</optional>
</element>
</define>
conf: put virtPortProfile struct / functions in a common location virtPortProfiles are currently only used in the domain XML, but will soon also be used in the network XML. To prepare for that change, this patch moves the structure definition into util/network.h and the parse and format functions into util/network.c (I decided that this was a better choice than macvtap.h/c for something that needed to always be available on all platforms).
2011-06-29 04:38:10 +00:00
</grammar>
Reference in New Issue Copy Permalink