2011-06-26 09:13:10 +00:00
|
|
|
<?xml version="1.0"?>
|
2007-07-24 09:19:40 +00:00
|
|
|
<!-- A Relax NG schema for the libvirt network XML format -->
|
2010-11-11 19:48:51 +00:00
|
|
|
<grammar xmlns="http://relaxng.org/ns/structure/1.0"
|
2007-07-24 09:19:40 +00:00
|
|
|
datatypeLibrary="http://www.w3.org/2001/XMLSchema-datatypes">
|
2010-11-11 19:48:51 +00:00
|
|
|
<start>
|
|
|
|
|
<ref name="network"/>
|
|
|
|
|
</start>
|
|
|
|
|
|
2011-06-26 09:13:10 +00:00
|
|
|
<include href='basictypes.rng'/>
|
conf: support abstracted interface info in network XML
The network XML is updated in the following ways:
1) The <forward> element can now contain a list of forward interfaces:
<forward .... >
<interface dev='eth10'/>
<interface dev='eth11'/>
<interface dev='eth12'/>
<interface dev='eth13'/>
</forward>
The first of these takes the place of the dev attribute that is
normally in <forward> - when defining a network you can specify
either one, and on output both will be present. If you specify
both on input, they must match.
2) In addition to forward modes of 'nat' and 'route', these new modes
are supported:
private, passthrough, vepa - when this network is referenced by a
domain's interface, it will have the same effect as if the
interface had been defined as type='direct', e.g.:
<interface type='direct'>
<source mode='${mode}' dev='${dev}>
...
</interface>
where ${mode} is one of the three new modes, and ${dev} is an interface
selected from the list given in <forward>.
bridge - if a <forward> dev (or multiple devs) is defined, and
forward mode is 'bridge' this is just like the modes 'private',
'passthrough', and 'vepa' above. If there is no forward dev
specified but a bridge name is given (e.g. "<bridge
name='br0'/>"), then guest interfaces using this network will use
libvirt's "host bridge" mode, equivalent to this:
<interface type='bridge'>
<source bridge='${bridge-name}'/>
...
</interface>
3) A network can have multiple <portgroup> elements, which may be
selected by the guest interface definition (by adding
"portgroup='${name}'" in the <source> element along with the
network name). Currently a portgroup can only contain a
virtportprofile, but the intent is that other configuration items
may be put there int the future (e.g. bandwidth config). When
building a guest's interface, if the <interface> XML itself has no
virtportprofile, and if the requested network has a portgroup with
a name matching the name given in the <interface> (or if one of the
network's portgroups is marked with the "default='yes'" attribute),
the virtportprofile from that portgroup will be used by the
interface.
4) A network can have a virtportprofile defined at the top level,
which will be used by a guest interface when connecting in one of
the 'direct' modes if the guest interface XML itself hasn't
specified any virtportprofile, and if there are also no matching
portgroups on the network.
2011-07-20 03:01:09 +00:00
|
|
|
<include href='networkcommon.rng'/>
|
2011-06-26 09:13:10 +00:00
|
|
|
|
2010-11-11 20:17:34 +00:00
|
|
|
<define name="network">
|
2010-11-11 19:48:51 +00:00
|
|
|
|
2010-11-11 20:17:34 +00:00
|
|
|
<element name="network">
|
|
|
|
|
<interleave>
|
2009-10-09 12:48:22 +00:00
|
|
|
|
2010-11-11 20:17:34 +00:00
|
|
|
<!-- The name of the network, used to refer to it through the API
|
|
|
|
|
and in virsh -->
|
|
|
|
|
<element name="name">
|
2009-10-09 12:48:22 +00:00
|
|
|
<text/>
|
2010-11-11 20:17:34 +00:00
|
|
|
</element>
|
2009-10-09 12:48:22 +00:00
|
|
|
|
2010-11-11 20:17:34 +00:00
|
|
|
<!-- <uuid> element -->
|
|
|
|
|
<optional>
|
2011-06-26 09:13:10 +00:00
|
|
|
<element name="uuid"><ref name="UUID"/></element>
|
2010-11-11 20:17:34 +00:00
|
|
|
</optional>
|
2009-10-09 12:48:22 +00:00
|
|
|
|
2010-11-11 20:17:34 +00:00
|
|
|
<!-- <bridge> element -->
|
|
|
|
|
<optional>
|
|
|
|
|
<!-- The name of the network to be set up; this will back
|
|
|
|
|
the network on the host -->
|
|
|
|
|
<element name="bridge">
|
|
|
|
|
<optional>
|
|
|
|
|
<attribute name="name">
|
2011-06-26 09:13:10 +00:00
|
|
|
<ref name="deviceName"/>
|
2010-11-11 20:17:34 +00:00
|
|
|
</attribute>
|
|
|
|
|
</optional>
|
2009-10-09 12:48:22 +00:00
|
|
|
|
2010-11-11 20:17:34 +00:00
|
|
|
<optional>
|
|
|
|
|
<attribute name="stp">
|
|
|
|
|
<choice>
|
|
|
|
|
<value>on</value>
|
|
|
|
|
<value>off</value>
|
|
|
|
|
</choice>
|
|
|
|
|
</attribute>
|
|
|
|
|
</optional>
|
2009-10-09 12:48:22 +00:00
|
|
|
|
2010-11-11 20:17:34 +00:00
|
|
|
<optional>
|
|
|
|
|
<attribute name="delay">
|
|
|
|
|
<data type="integer"/>
|
|
|
|
|
</attribute>
|
|
|
|
|
</optional>
|
2009-10-09 12:48:22 +00:00
|
|
|
|
2010-11-11 20:17:34 +00:00
|
|
|
</element>
|
|
|
|
|
</optional>
|
2009-10-09 12:48:22 +00:00
|
|
|
|
Give each virtual network bridge its own fixed MAC address
This fixes https://bugzilla.redhat.com/show_bug.cgi?id=609463
The problem was that, since a bridge always acquires the MAC address
of the connected interface with the numerically lowest MAC, as guests
are started and stopped, it was possible for the MAC address to change
over time, and this change in the network was being detected by
Windows 7 (it sees the MAC of the default route change), so on each
reboot it would bring up a dialog box asking about this "new network".
The solution is to create a dummy tap interface with a MAC guaranteed
to be lower than any guest interface's MAC, and attach that tap to the
bridge as soon as it's created. Since all guest MAC addresses start
with 0xFE, we can just generate a MAC with the standard "0x52, 0x54,
0" prefix, and it's guaranteed to always win (physical interfaces are
never connected to these bridges, so we don't need to worry about
competing numerically with them).
Note that the dummy tap is never set to IFF_UP state - that's not
necessary in order for the bridge to take its MAC, and not setting it
to UP eliminates the clutter of having an (eg) "virbr0-nic" displayed
in the output of the ifconfig command.
I chose to not auto-generate the MAC address in the network XML
parser, as there are likely to be consumers of that API that don't
need or want to have a MAC address associated with the
bridge.
Instead, in bridge_driver.c when the network is being defined, if
there is no MAC, one is generated. To account for virtual network
configs that already exist when upgrading from an older version of
libvirt, I've added a %post script to the specfile that searches for
all network definitions in both the config directory
(/etc/libvirt/qemu/networks) and the state directory
(/var/lib/libvirt/network) that are missing a mac address, generates a
random address, and adds it to the config (and a matching address to
the state file, if there is one).
docs/formatnetwork.html.in: document <mac address.../>
docs/schemas/network.rng: add nac address to schema
libvirt.spec.in: %post script to update existing networks
src/conf/network_conf.[ch]: parse and format <mac address.../>
src/libvirt_private.syms: export a couple private symbols we need
src/network/bridge_driver.c:
auto-generate mac address when needed,
create dummy interface if mac address is present.
tests/networkxml2xmlin/isolated-network.xml
tests/networkxml2xmlin/routed-network.xml
tests/networkxml2xmlout/isolated-network.xml
tests/networkxml2xmlout/routed-network.xml: add mac address to some tests
2011-02-09 08:28:12 +00:00
|
|
|
<!-- <mac> element -->
|
|
|
|
|
<optional>
|
|
|
|
|
<element name="mac">
|
2011-06-26 09:13:10 +00:00
|
|
|
<attribute name="address"><ref name="macAddr"/></attribute>
|
Give each virtual network bridge its own fixed MAC address
This fixes https://bugzilla.redhat.com/show_bug.cgi?id=609463
The problem was that, since a bridge always acquires the MAC address
of the connected interface with the numerically lowest MAC, as guests
are started and stopped, it was possible for the MAC address to change
over time, and this change in the network was being detected by
Windows 7 (it sees the MAC of the default route change), so on each
reboot it would bring up a dialog box asking about this "new network".
The solution is to create a dummy tap interface with a MAC guaranteed
to be lower than any guest interface's MAC, and attach that tap to the
bridge as soon as it's created. Since all guest MAC addresses start
with 0xFE, we can just generate a MAC with the standard "0x52, 0x54,
0" prefix, and it's guaranteed to always win (physical interfaces are
never connected to these bridges, so we don't need to worry about
competing numerically with them).
Note that the dummy tap is never set to IFF_UP state - that's not
necessary in order for the bridge to take its MAC, and not setting it
to UP eliminates the clutter of having an (eg) "virbr0-nic" displayed
in the output of the ifconfig command.
I chose to not auto-generate the MAC address in the network XML
parser, as there are likely to be consumers of that API that don't
need or want to have a MAC address associated with the
bridge.
Instead, in bridge_driver.c when the network is being defined, if
there is no MAC, one is generated. To account for virtual network
configs that already exist when upgrading from an older version of
libvirt, I've added a %post script to the specfile that searches for
all network definitions in both the config directory
(/etc/libvirt/qemu/networks) and the state directory
(/var/lib/libvirt/network) that are missing a mac address, generates a
random address, and adds it to the config (and a matching address to
the state file, if there is one).
docs/formatnetwork.html.in: document <mac address.../>
docs/schemas/network.rng: add nac address to schema
libvirt.spec.in: %post script to update existing networks
src/conf/network_conf.[ch]: parse and format <mac address.../>
src/libvirt_private.syms: export a couple private symbols we need
src/network/bridge_driver.c:
auto-generate mac address when needed,
create dummy interface if mac address is present.
tests/networkxml2xmlin/isolated-network.xml
tests/networkxml2xmlin/routed-network.xml
tests/networkxml2xmlout/isolated-network.xml
tests/networkxml2xmlout/routed-network.xml: add mac address to some tests
2011-02-09 08:28:12 +00:00
|
|
|
<empty/>
|
|
|
|
|
</element>
|
|
|
|
|
</optional>
|
|
|
|
|
|
2010-11-11 20:17:34 +00:00
|
|
|
<!-- <forward> element -->
|
|
|
|
|
<optional>
|
|
|
|
|
<!-- The device through which the bridge is connected to the
|
|
|
|
|
rest of the network -->
|
|
|
|
|
<element name="forward">
|
|
|
|
|
<optional>
|
|
|
|
|
<attribute name="dev">
|
2011-06-26 09:13:10 +00:00
|
|
|
<ref name="deviceName"/>
|
2010-11-11 20:17:34 +00:00
|
|
|
</attribute>
|
|
|
|
|
</optional>
|
2009-10-09 12:48:22 +00:00
|
|
|
|
2010-11-11 20:17:34 +00:00
|
|
|
<optional>
|
|
|
|
|
<attribute name="mode">
|
|
|
|
|
<choice>
|
|
|
|
|
<value>nat</value>
|
|
|
|
|
<value>route</value>
|
conf: support abstracted interface info in network XML
The network XML is updated in the following ways:
1) The <forward> element can now contain a list of forward interfaces:
<forward .... >
<interface dev='eth10'/>
<interface dev='eth11'/>
<interface dev='eth12'/>
<interface dev='eth13'/>
</forward>
The first of these takes the place of the dev attribute that is
normally in <forward> - when defining a network you can specify
either one, and on output both will be present. If you specify
both on input, they must match.
2) In addition to forward modes of 'nat' and 'route', these new modes
are supported:
private, passthrough, vepa - when this network is referenced by a
domain's interface, it will have the same effect as if the
interface had been defined as type='direct', e.g.:
<interface type='direct'>
<source mode='${mode}' dev='${dev}>
...
</interface>
where ${mode} is one of the three new modes, and ${dev} is an interface
selected from the list given in <forward>.
bridge - if a <forward> dev (or multiple devs) is defined, and
forward mode is 'bridge' this is just like the modes 'private',
'passthrough', and 'vepa' above. If there is no forward dev
specified but a bridge name is given (e.g. "<bridge
name='br0'/>"), then guest interfaces using this network will use
libvirt's "host bridge" mode, equivalent to this:
<interface type='bridge'>
<source bridge='${bridge-name}'/>
...
</interface>
3) A network can have multiple <portgroup> elements, which may be
selected by the guest interface definition (by adding
"portgroup='${name}'" in the <source> element along with the
network name). Currently a portgroup can only contain a
virtportprofile, but the intent is that other configuration items
may be put there int the future (e.g. bandwidth config). When
building a guest's interface, if the <interface> XML itself has no
virtportprofile, and if the requested network has a portgroup with
a name matching the name given in the <interface> (or if one of the
network's portgroups is marked with the "default='yes'" attribute),
the virtportprofile from that portgroup will be used by the
interface.
4) A network can have a virtportprofile defined at the top level,
which will be used by a guest interface when connecting in one of
the 'direct' modes if the guest interface XML itself hasn't
specified any virtportprofile, and if there are also no matching
portgroups on the network.
2011-07-20 03:01:09 +00:00
|
|
|
<value>bridge</value>
|
|
|
|
|
<value>passthrough</value>
|
|
|
|
|
<value>private</value>
|
|
|
|
|
<value>vepa</value>
|
2010-11-11 20:17:34 +00:00
|
|
|
</choice>
|
|
|
|
|
</attribute>
|
|
|
|
|
</optional>
|
conf: support abstracted interface info in network XML
The network XML is updated in the following ways:
1) The <forward> element can now contain a list of forward interfaces:
<forward .... >
<interface dev='eth10'/>
<interface dev='eth11'/>
<interface dev='eth12'/>
<interface dev='eth13'/>
</forward>
The first of these takes the place of the dev attribute that is
normally in <forward> - when defining a network you can specify
either one, and on output both will be present. If you specify
both on input, they must match.
2) In addition to forward modes of 'nat' and 'route', these new modes
are supported:
private, passthrough, vepa - when this network is referenced by a
domain's interface, it will have the same effect as if the
interface had been defined as type='direct', e.g.:
<interface type='direct'>
<source mode='${mode}' dev='${dev}>
...
</interface>
where ${mode} is one of the three new modes, and ${dev} is an interface
selected from the list given in <forward>.
bridge - if a <forward> dev (or multiple devs) is defined, and
forward mode is 'bridge' this is just like the modes 'private',
'passthrough', and 'vepa' above. If there is no forward dev
specified but a bridge name is given (e.g. "<bridge
name='br0'/>"), then guest interfaces using this network will use
libvirt's "host bridge" mode, equivalent to this:
<interface type='bridge'>
<source bridge='${bridge-name}'/>
...
</interface>
3) A network can have multiple <portgroup> elements, which may be
selected by the guest interface definition (by adding
"portgroup='${name}'" in the <source> element along with the
network name). Currently a portgroup can only contain a
virtportprofile, but the intent is that other configuration items
may be put there int the future (e.g. bandwidth config). When
building a guest's interface, if the <interface> XML itself has no
virtportprofile, and if the requested network has a portgroup with
a name matching the name given in the <interface> (or if one of the
network's portgroups is marked with the "default='yes'" attribute),
the virtportprofile from that portgroup will be used by the
interface.
4) A network can have a virtportprofile defined at the top level,
which will be used by a guest interface when connecting in one of
the 'direct' modes if the guest interface XML itself hasn't
specified any virtportprofile, and if there are also no matching
portgroups on the network.
2011-07-20 03:01:09 +00:00
|
|
|
<zeroOrMore>
|
|
|
|
|
<element name='interface'>
|
|
|
|
|
<attribute name='dev'>
|
|
|
|
|
<ref name='deviceName'/>
|
|
|
|
|
</attribute>
|
|
|
|
|
</element>
|
|
|
|
|
</zeroOrMore>
|
2007-07-24 09:19:40 +00:00
|
|
|
</element>
|
2010-11-11 20:17:34 +00:00
|
|
|
</optional>
|
|
|
|
|
|
conf: support abstracted interface info in network XML
The network XML is updated in the following ways:
1) The <forward> element can now contain a list of forward interfaces:
<forward .... >
<interface dev='eth10'/>
<interface dev='eth11'/>
<interface dev='eth12'/>
<interface dev='eth13'/>
</forward>
The first of these takes the place of the dev attribute that is
normally in <forward> - when defining a network you can specify
either one, and on output both will be present. If you specify
both on input, they must match.
2) In addition to forward modes of 'nat' and 'route', these new modes
are supported:
private, passthrough, vepa - when this network is referenced by a
domain's interface, it will have the same effect as if the
interface had been defined as type='direct', e.g.:
<interface type='direct'>
<source mode='${mode}' dev='${dev}>
...
</interface>
where ${mode} is one of the three new modes, and ${dev} is an interface
selected from the list given in <forward>.
bridge - if a <forward> dev (or multiple devs) is defined, and
forward mode is 'bridge' this is just like the modes 'private',
'passthrough', and 'vepa' above. If there is no forward dev
specified but a bridge name is given (e.g. "<bridge
name='br0'/>"), then guest interfaces using this network will use
libvirt's "host bridge" mode, equivalent to this:
<interface type='bridge'>
<source bridge='${bridge-name}'/>
...
</interface>
3) A network can have multiple <portgroup> elements, which may be
selected by the guest interface definition (by adding
"portgroup='${name}'" in the <source> element along with the
network name). Currently a portgroup can only contain a
virtportprofile, but the intent is that other configuration items
may be put there int the future (e.g. bandwidth config). When
building a guest's interface, if the <interface> XML itself has no
virtportprofile, and if the requested network has a portgroup with
a name matching the name given in the <interface> (or if one of the
network's portgroups is marked with the "default='yes'" attribute),
the virtportprofile from that portgroup will be used by the
interface.
4) A network can have a virtportprofile defined at the top level,
which will be used by a guest interface when connecting in one of
the 'direct' modes if the guest interface XML itself hasn't
specified any virtportprofile, and if there are also no matching
portgroups on the network.
2011-07-20 03:01:09 +00:00
|
|
|
<!-- <virtualport> element -->
|
|
|
|
|
<optional>
|
|
|
|
|
<ref name="virtualPortProfile"/>
|
|
|
|
|
</optional>
|
|
|
|
|
|
|
|
|
|
<!-- <portgroup> elements -->
|
|
|
|
|
<zeroOrMore>
|
|
|
|
|
<element name="portgroup">
|
|
|
|
|
<attribute name="name">
|
|
|
|
|
<ref name="deviceName"/>
|
|
|
|
|
</attribute>
|
|
|
|
|
<optional>
|
|
|
|
|
<attribute name="default">
|
|
|
|
|
<choice>
|
|
|
|
|
<value>yes</value>
|
|
|
|
|
<value>no</value>
|
|
|
|
|
</choice>
|
|
|
|
|
</attribute>
|
|
|
|
|
</optional>
|
|
|
|
|
<optional>
|
|
|
|
|
<ref name="virtualPortProfile"/>
|
|
|
|
|
</optional>
|
|
|
|
|
</element>
|
|
|
|
|
</zeroOrMore>
|
|
|
|
|
|
2010-11-11 20:17:34 +00:00
|
|
|
<!-- <domain> element -->
|
|
|
|
|
<optional>
|
|
|
|
|
<element name="domain">
|
2011-06-26 09:13:10 +00:00
|
|
|
<attribute name="name"><ref name="dnsName"/></attribute>
|
2009-07-02 14:02:18 +00:00
|
|
|
</element>
|
2010-11-11 20:17:34 +00:00
|
|
|
</optional>
|
|
|
|
|
|
2011-06-24 10:04:36 +00:00
|
|
|
<!-- Define the DNS related elements like TXT records
|
|
|
|
|
and other features in the <dns> element -->
|
|
|
|
|
<optional>
|
|
|
|
|
<element name="dns">
|
|
|
|
|
<zeroOrMore>
|
|
|
|
|
<element name="txt">
|
2011-06-26 09:13:10 +00:00
|
|
|
<attribute name="name"><ref name="dnsName"/></attribute>
|
2011-06-24 10:04:36 +00:00
|
|
|
<attribute name="value"><text/></attribute>
|
|
|
|
|
</element>
|
|
|
|
|
</zeroOrMore>
|
2012-01-02 14:23:54 +00:00
|
|
|
<zeroOrMore>
|
|
|
|
|
<element name="srv">
|
|
|
|
|
<attribute name="service"><text/></attribute>
|
|
|
|
|
<attribute name="protocol"><ref name="protocol"/></attribute>
|
|
|
|
|
<optional>
|
|
|
|
|
<attribute name="domain"><ref name="dnsName"/></attribute>
|
|
|
|
|
<attribute name="target"><text/></attribute>
|
|
|
|
|
<attribute name="port"><ref name="unsignedShort"/></attribute>
|
|
|
|
|
<attribute name="priority"><ref name="unsignedShort"/></attribute>
|
|
|
|
|
<attribute name="weight"><ref name="unsignedShort"/></attribute>
|
|
|
|
|
</optional>
|
|
|
|
|
</element>
|
|
|
|
|
</zeroOrMore>
|
2011-06-24 10:04:40 +00:00
|
|
|
<zeroOrMore>
|
|
|
|
|
<element name="host">
|
2011-06-26 09:13:10 +00:00
|
|
|
<attribute name="ip"><ref name="ipv4Addr"/></attribute>
|
2011-06-24 10:04:40 +00:00
|
|
|
<oneOrMore>
|
2011-06-26 09:13:10 +00:00
|
|
|
<element name="hostname"><ref name="dnsName"/></element>
|
2011-06-24 10:04:40 +00:00
|
|
|
</oneOrMore>
|
|
|
|
|
</element>
|
|
|
|
|
</zeroOrMore>
|
2011-06-24 10:04:36 +00:00
|
|
|
</element>
|
|
|
|
|
</optional>
|
2011-07-22 14:07:23 +00:00
|
|
|
<optional>
|
|
|
|
|
<ref name="bandwidth"/>
|
|
|
|
|
</optional>
|
2011-09-06 08:08:15 +00:00
|
|
|
<optional>
|
|
|
|
|
<element name="link">
|
|
|
|
|
<attribute name="state">
|
|
|
|
|
<choice>
|
|
|
|
|
<value>up</value>
|
|
|
|
|
<value>down</value>
|
|
|
|
|
</choice>
|
|
|
|
|
</attribute>
|
|
|
|
|
<empty/>
|
|
|
|
|
</element>
|
|
|
|
|
</optional>
|
2011-06-24 10:04:36 +00:00
|
|
|
|
2010-11-11 20:17:34 +00:00
|
|
|
<!-- <ip> element -->
|
2010-11-17 18:36:19 +00:00
|
|
|
<zeroOrMore>
|
2010-11-11 20:17:34 +00:00
|
|
|
<!-- The IP element sets up NAT'ing and an optional DHCP server
|
|
|
|
|
local to the host. -->
|
|
|
|
|
<element name="ip">
|
|
|
|
|
<optional>
|
2011-06-26 09:13:10 +00:00
|
|
|
<attribute name="address"><ref name="ipAddr"/></attribute>
|
2010-11-17 18:36:19 +00:00
|
|
|
</optional>
|
|
|
|
|
<optional>
|
|
|
|
|
<choice>
|
2011-06-26 09:13:10 +00:00
|
|
|
<attribute name="netmask"><ref name="ipv4Addr"/></attribute>
|
|
|
|
|
<attribute name="prefix"><ref name="ipPrefix"/></attribute>
|
2010-11-17 18:36:19 +00:00
|
|
|
</choice>
|
2010-11-11 20:17:34 +00:00
|
|
|
</optional>
|
|
|
|
|
<optional>
|
2010-11-17 18:36:19 +00:00
|
|
|
<attribute name="family"><ref name="addr-family"/></attribute>
|
2010-11-11 20:17:34 +00:00
|
|
|
</optional>
|
2009-10-28 14:57:49 +00:00
|
|
|
<optional>
|
2010-11-11 20:17:34 +00:00
|
|
|
<element name="tftp">
|
|
|
|
|
<attribute name="root"><text/></attribute>
|
|
|
|
|
</element>
|
2009-10-28 14:57:49 +00:00
|
|
|
</optional>
|
2010-12-16 17:36:19 +00:00
|
|
|
<optional>
|
|
|
|
|
<!-- Define the range(s) of IP addresses that the DHCP
|
|
|
|
|
server should hand out -->
|
|
|
|
|
<element name="dhcp">
|
|
|
|
|
<zeroOrMore>
|
|
|
|
|
<element name="range">
|
2011-06-26 09:13:10 +00:00
|
|
|
<attribute name="start"><ref name="ipv4Addr"/></attribute>
|
|
|
|
|
<attribute name="end"><ref name="ipv4Addr"/></attribute>
|
2010-12-16 17:36:19 +00:00
|
|
|
</element>
|
|
|
|
|
</zeroOrMore>
|
|
|
|
|
<zeroOrMore>
|
|
|
|
|
<element name="host">
|
2011-06-26 09:13:10 +00:00
|
|
|
<attribute name="mac"><ref name="macAddr"/></attribute>
|
2010-12-16 17:36:19 +00:00
|
|
|
<attribute name="name"><text/></attribute>
|
2011-06-26 09:13:10 +00:00
|
|
|
<attribute name="ip"><ref name="ipv4Addr"/></attribute>
|
2010-12-16 17:36:19 +00:00
|
|
|
</element>
|
|
|
|
|
</zeroOrMore>
|
|
|
|
|
<optional>
|
|
|
|
|
<element name="bootp">
|
2011-06-26 09:13:10 +00:00
|
|
|
<attribute name="file"><ref name="filePath"/></attribute>
|
2010-12-16 17:36:19 +00:00
|
|
|
<optional>
|
2011-06-26 09:13:10 +00:00
|
|
|
<attribute name="server"><ref name="dnsName"/></attribute>
|
2010-12-16 17:36:19 +00:00
|
|
|
</optional>
|
|
|
|
|
</element>
|
|
|
|
|
</optional>
|
|
|
|
|
</element>
|
|
|
|
|
</optional>
|
2010-03-01 19:09:26 +00:00
|
|
|
</element>
|
2010-11-17 18:36:19 +00:00
|
|
|
</zeroOrMore>
|
2010-11-11 20:17:34 +00:00
|
|
|
</interleave>
|
2007-07-24 09:19:40 +00:00
|
|
|
</element>
|
2010-11-11 20:17:34 +00:00
|
|
|
</define>
|
2010-11-11 19:48:51 +00:00
|
|
|
</grammar>
|
