- 20 1月, 2015 1 次提交
-
-
由 Josh Stone 提交于
This adds a new "localOnly" attribute on the domain element of the network xml. With this set to "yes", DNS requests under that domain will only be resolved by libvirt's dnsmasq, never forwarded upstream. This was how it worked before commit f69a6b98, and I found that functionality useful. For example, I have my host's NetworkManager dnsmasq configured to forward that domain to libvirt's dnsmasq, so I can easily resolve guest names from outside. But if libvirt's dnsmasq doesn't know a name and forwards it to the host, I'd get an endless forwarding loop. Now I can set localOnly="yes" to prevent the loop. Signed-off-by: NJosh Stone <jistone@redhat.com>
-
- 09 12月, 2014 1 次提交
-
-
由 Laine Stump 提交于
The macTableManager attribute of a network's bridge subelement tells libvirt how the bridge's MAC address table (used to determine the egress port for packets) is managed. In the default mode, "kernel", management is left to the kernel, which usually determines entries in part by turning on promiscuous mode on all ports of the bridge, flooding packets to all ports when the correct destination is unknown, and adding/removing entries to the fdb as it sees incoming traffic from particular MAC addresses. In "libvirt" mode, libvirt turns off learning and flooding on all the bridge ports connected to guest domain interfaces, and adds/removes entries according to the MAC addresses in the domain interface configurations. A side effect of turning off learning and unicast_flood on the ports of a bridge is that (with Linux kernel 3.17 and newer), the kernel can automatically turn off promiscuous mode on one or more of the bridge's ports (usually only the one interface that is used to connect the bridge to the physical network). The result is better performance (because packets aren't being flooded to all ports, and can be dropped earlier when they are of no interest) and slightly better security (a guest can still send out packets with a spoofed source MAC address, but will only receive traffic intended for the guest interface's configured MAC address). The attribute looks like this in the configuration: <network> <name>test</name> <bridge name='br0' macTableManager='libvirt'/> ... This patch only adds the config knob, documentation, and test cases. The functionality behind this knob is added in later patches.
-
- 06 12月, 2014 1 次提交
-
-
由 Chen Fan 提交于
this patch fix some weird typos: 1. < hostdev> => <hostdev> 2. < type> => <type> 3. <virtualport > => <virtualport> 4. redundant comma 5. missing right-half bracket Signed-off-by: NChen Fan <chen.fan.fnst@cn.fujitsu.com>
-
- 06 10月, 2014 1 次提交
-
-
由 Laine Stump 提交于
This new attribute will control whether or not libvirt will pay attention to guest notifications about changes to network device mac addresses and receive filters. The default for this is 'no' (for security reasons). If it is set to 'yes' *and* the specified device model and connection support it (currently only macvtap+virtio) then libvirt will watch for NIC_RX_FILTER_CHANGED events, and when it receives one, it will issue a query-rx-filter command, retrieve the result, and modify the host-side macvtap interface's mac address and unicast/multicast filters accordingly. The functionality behind this attribute will be in a later patch. This patch merely adds the attribute to the top-level of a domain's <interface> as well as to <network> and <portgroup>, and adds documentation and schema/xml2xml tests. Rather than adding even more test files, I've just added the net attribute in various applicable places of existing test files.
-
- 18 4月, 2014 1 次提交
-
-
由 Laine Stump 提交于
When the default was changed from kvm to vfio, the documentation for hostdev and interface was changed, but the documentation in <network> was forgotten. Also document when the default was changed from "always kvm" to "vfio if available, else kvm" (1.0.5).
-
- 21 2月, 2014 1 次提交
-
-
由 John Ferlan 提交于
Recent autotest/virt-test testing on f20 discovered an anomaly in how the bandwidth options are documented and used. This was discovered due to a bug fix in the /sbin/tc utility found in iproute-3.11.0.1 (on f20) in which overflow was actually caught and returned as an error. The fix was first introduced in iproute-3.10 (search on iproute2 commit 'a303853e'). The autotest/virt-test test for virsh domiftune was attempting to send the largest unsigned integer value (4294967295) for maximum value testing. The libvirt xml implementation was designed to manage values in kilobytes thus when this value was passed to /sbin/tc, it (now) properly rejected the 4294967295kbps value. Investigation of the problem discovered that formatdomain.html.in and formatnetwork.html.in described the elements and property types slightly differently, although they use the same code - virNetDevBandwidthParseRate() (shared by portgroups, domains, and networks xml parsers). Rather than have the descriptions in two places, this patch will combine and reword the description under formatnetwork.html.in and have formatdomain.html.in link to that description. This documentation faux pas was continued into the virsh man page where the bandwidth description for both 'attach-interface' and 'domiftune' did not indicate the format of each value, thus leading to the test using largest unsigned integer value assuming "bps" rather than "kbps", which ultimately was wrong.
-
- 05 2月, 2014 1 次提交
-
-
由 Laine Stump 提交于
https://bugzilla.redhat.com/show_bug.cgi?id=1057321 pointed out that we weren't honoring the <bandwidth> element in libvirt networks using <forward mode='bridge'/>. In fact, these networks are just a method of giving a libvirt network name to an existing Linux host bridge on the system, and libvirt doesn't have enough information to know where to set such limits. We are working on a method of supporting network bandwidths for some specific cases of <forward mode='bridge'/>, but currently libvirt doesn't support it. So the proper thing to do now is just log an error when someone tries to put a <bandwidth> element in that type of network. (It's unclear if we will be able to do proper bandwidth limiting for macvtap networks, and most definitely we will not be able to support it for hostdev networks). While looking through the network XML documentation and comparing it to the networkValidate function, I noticed that we also ignore the presence of a mac address in the config in the same cases, rather than failing so that the user will understand that their desired action has not been taken. This patch updates networkValidate() (which is called any time a persistent network is defined, or a transient network created) to log an error and fail if it finds either a <bandwidth> or <mac> element and the network forward mode is anything except 'route'. 'nat', or nothing. (Yes, neither of those elements is acceptable for any macvtap mode, nor for a hostdev network). NB: This does *not* cause failure to start any existing network that contains one of those elements, so someone might have erroneously defined such a network in the past, and that network will continue to function unmodified. I considered it too disruptive to suddenly break working configs on the next reboot after a libvirt upgrade.
-
- 18 9月, 2013 1 次提交
-
-
由 Diego Woitasen 提交于
Useful to set custom forwarders instead of using the contents of /etc/resolv.conf. It helps me to setup dnsmasq as local nameserver to resolve VM domain names from domain 0, when domain option is used. Signed-off-by: NDiego Woitasen <diego.woitasen@vhgroup.net> Signed-off-by: NEric Blake <eblake@redhat.com>
-
- 11 9月, 2013 1 次提交
-
-
由 Oskari Saarenmaa 提交于
Signed-off-by: NOskari Saarenmaa <os@ohmu.fi> Signed-off-by: NEric Blake <eblake@redhat.com>
-
- 05 9月, 2013 1 次提交
-
-
由 Ján Tomko 提交于
-
- 14 8月, 2013 1 次提交
-
-
由 Laine Stump 提交于
This resolves the issue that prompted the filing of https://bugzilla.redhat.com/show_bug.cgi?id=928638 (although the request there is for something much larger and more general than this patch). commit f3868259 disabled the forwarding to upstream DNS servers of unresolved DNS requests for names that had no domain, but were just simple host names (no "." character anywhere in the name). While this behavior is frowned upon by DNS root servers (that's why it was changed in libvirt), it is convenient in some cases, and since dnsmasq can be configured to allow it, it must not be strictly forbidden. This patch restores the old behavior, but since it is usually undesirable, restoring it requires specification of a new option in the network config. Adding the attribute "forwardPlainNames='yes'" to the <dns> elemnt does the trick - when that attribute is added to a network config, any simple hostnames that can't be resolved by the network's dnsmasq instance will be forwarded to the DNS servers listed in the host's /etc/resolv.conf for an attempt at resolution (just as any FQDN would be forwarded). When that attribute *isn't* specified, unresolved simple names will *not* be forwarded to the upstream DNS server - this is the default behavior.
-
- 26 6月, 2013 1 次提交
-
-
由 Laine Stump 提交于
Somehow I put an example of a domain interface with a <vlan> element into the network documentation. This patch replaces that with an example of a network definition that has a vlan element with trunk='yes', multiple tags, and even the new nativeMode attribute. It also includes a <portgroup> that has a vlan defined.
-
- 25 6月, 2013 2 次提交
-
-
由 Ján Tomko 提交于
Since we already have the v1.1.0-rc1 tag in git.
-
由 james robson 提交于
This patch adds functionality to allow libvirt to configure the 'native-tagged' and 'native-untagged' modes on openvswitch networks. Signed-off-by: NLaine Stump <laine@redhat.com>
-
- 14 5月, 2013 1 次提交
-
-
由 Gene Czarcinski 提交于
network: static route support for <network> This patch adds the <route> subelement of <network> to define a static route. the address and prefix (or netmask) attribute identify the destination network, and the gateway attribute specifies the next hop address (which must be directly reachable from the containing <network>) which is to receive the packets destined for "address/(prefix|netmask)". These attributes are translated into an "ip route add" command that is executed when the network is started. The command used is of the following form: ip route add <address>/<prefix> via <gateway> \ dev <virbr-bridge> proto static metric <metric> Tests are done to validate that the input data are correct. For example, for a static route ip definition, the address must be a network address and not a host address. Additional checks are added to ensure that the specified gateway is directly reachable via this network (i.e. that the gateway IP address is in the same subnet as one of the IP's defined for the network). prefix='0' is supported for both family='ipv4' address='0.0.0.0' netmask='0.0.0.0' or prefix='0', and for family='ipv6' address='::', prefix=0', although care should be taken to not override a desired system default route. Anytime an attempt is made to define a static route which *exactly* duplicates an existing static route (for example, address=::, prefix=0, metric=1), the following error message will be sent to syslog: RTNETLINK answers: File exists This can be overridden by decreasing the metric value for the route that should be preferred, or increasing the metric for the route that shouldn't be preferred (and is thus in place only in anticipation that the preferred route may be removed in the future). Caution should be used when manipulating route metrics, especially for a default route. Note: The use of the command-line interface should be replaced by direct use of libnl so that error conditions can be handled better. But, that is being left as an exercise for another day. Signed-off-by: NGene Czarcinski <gene@czarc.net> Signed-off-by: NLaine Stump <laine@laine.org>
-
- 03 5月, 2013 1 次提交
-
-
由 Daniel P. Berrange 提交于
The rule generating the HTML docs passing the --html flag to xsltproc. This makes it use the legacy HTML parser, which either ignores or tries to fix all sorts of broken XML tags. There's no reason why we should be writing broken XML in the first place, so removing --html and adding the XHTML doctype to all files forces us to create good XML. This adds the XHTML doc type and fixes many, many XML tag problems it exposes. Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
- 26 4月, 2013 1 次提交
-
-
由 Laine Stump 提交于
A domain's <interface> or <hostdev>, as well as a <network>'s <forward>, can now have an optional <driver name='kvm|vfio'/> element. As of this patch, there is no functionality behind this new knob - this patch adds support to the domain and network formatter/parser, and to the RNG and documentation. When the backend is added, legacy KVM PCI device assignment will continue to be used when no driver name is specified (or if <driver name='kvm'/> is specified), but if driver name is 'vfio', the new UEFI Secure Boot compatible VFIO device assignment will be used. Note that the parser doesn't automatically insert the current default value of this setting. This is done on purpose because the two possibilities are functionally equivalent from the guest's point of view, and we want to be able to automatically start using vfio as the default (even for existing domains) at some time in the future. This is similar to what was done with the "vhost" driver option in <interface>.
-
- 28 2月, 2013 1 次提交
-
-
由 Eric Blake 提交于
* docs/formatnetwork.html.in: Spell variation correctly.
-
- 25 2月, 2013 1 次提交
-
-
由 Gene Czarcinski 提交于
Originally, only a host name was used to associate a DHCPv6 request with a specific IPv6 address. Further testing demonstrates that this is an unreliable method and, instead, a client-id or DUID needs to be used. According to DHCPv6 standards, this id can be a duid-LLT, duid-LL, or duid-UUID even though dnsmasq will accept almost any text string. Although validity checking of a specified string makes sure it is hexadecimal notation with bytes separated by colons, there is no rigorous check to make sure it meets the standard. Documentation and schemas have been updated. Signed-off-by: NGene Czarcinski <gene@czarc.net> Signed-off-by: NLaine Stump <laine@laine.org>
-
- 21 2月, 2013 1 次提交
-
-
由 Jiri Denemark 提交于
<pre> is forbidden inside <p>
-
- 20 2月, 2013 2 次提交
-
-
由 Natanael Copa 提交于
Let users set the port range to be used for forward mode NAT: ... <forward mode='nat'> <nat> <port start='1024' end='65535'/> </nat> </forward> ... Signed-off-by: NNatanael Copa <ncopa@alpinelinux.org> Signed-off-by: NLaine Stump <laine@laine.org>
-
由 Natanael Copa 提交于
Support setting which public ip to use for NAT via attribute address in subelement <nat> in <forward>: ... <forward mode='nat'> <address start='1.2.3.4' end='1.2.3.10'/> </forward> ... This will construct an iptables line using: '-j SNAT --to-source <start>-<end>' instead of: '-j MASQUERADE' Signed-off-by: NNatanael Copa <ncopa@alpinelinux.org> Signed-off-by: NLaine Stump <laine@laine.org>
-
- 11 12月, 2012 1 次提交
-
-
由 Gene Czarcinski 提交于
The DHCPv6 support includes IPV6 dhcp-range and dhcp-host for one IPv6 subnetwork on one interface. This support will only work if dnsmasq version >= 2.64; otherwise an error occurs if dhcp-range or dhcp-host is specified for an IPv6 address. Essentially, this change provides the same DHCP support for IPv6 that has been available for IPv4. With dnsmasq >= 2.64, support for the RA service is also now provided by dnsmasq (radvd is no longer used/started). (Although at least one version of dnsmasq prior to 2.64 "supported" IPv6 Router Advertisement, there were bugs (fixed in 2.64) that rendered it unusable.) Documentation and the network schema has been updated to reflect the new support.
-
- 06 12月, 2012 1 次提交
-
-
由 Gene Czarcinski 提交于
This patch adds the capability for virtual guests to do IPv6 communication via a virtual network interface with no IPv6 (gateway) addresses specified. This capability has always been enabled by default for IPv4, but disabled for IPv6 for security concerns, and because it requires the ip6tables command to be operational (which isn't the case on a system with the ipv6 module completely disabled). This patch adds a new attribute "ipv6" at the toplevel of a <network> object. If ipv6='yes', the extra ip6tables rules required to permite inter-guest communications are added when the network is started. If it is 'no', or not present, those rules will not be added; thus the default behavior doesn't change, so there should be no compatibility issues with any existing installations. Note that virtual guests cannot communication with the virtualization host via this interface, because the following kernel tunable has been set: net.ipv6.conf.<bridge_interface_name>.disable_ipv6 = 1 This assures that the bridge interface will not have an IPv6 link-local (fe80::) address. To control this behavior so that it is not enabled by default, the parameter ipv6='yes' on the <network> statement has been added. Documentation related to this patch has been updated. The network schema has also been updated.
-
- 18 8月, 2012 1 次提交
-
-
由 Shradha Shah 提交于
This patch updates the network driver to properly utilize the new attributes/elements that are now in virNetworkDef Signed-off-by: NShradha Shah <sshah@solarflare.com> Signed-off-by: NLaine Stump <laine@laine.org>
-
- 16 8月, 2012 1 次提交
-
-
由 Laine Stump 提交于
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.)
-
- 15 8月, 2012 2 次提交
-
-
由 Laine Stump 提交于
Just as each physical device used by a network has a connections counter, now each network has a connections counter which is incremented once for each guest interface that connects using this network. The count is output in the live network XML, like this: <network connections='20'> ... </network> It is read-only, and for informational purposes only - it isn't used internally anywhere by libvirt.
-
由 Laine Stump 提交于
One of the original ideas behind allowing a <virtualport> in an interface definition as well as in the <network> definition *and*one or more <portgroup>s within the network, was that guest-specific parameteres (like instanceid and interfaceid) could be given in the interface's virtualport, and more general things (portid, managerid, etc) could be given in the network and/or portgroup, with all the bits brought together at guest startup time and combined into a single virtualport to be used by the guest. This was somehow overlooked in the implementation, though - it simply picks the "most specific" virtualport, and uses the entire thing, with no attempt to merge in details from the others. This patch uses virNetDevVPortProfileMerge3() to combine the three possible virtualports into one, then uses virNetDevVPortProfileCheck*() to verify that the resulting virtualport type is appropriate for the type of network, and that all the required attributes for that type are present. An example of usage is this: assuming a <network> definitions on host ABC of: <network> <name>testA</name> ... <virtualport type='openvswitch'/> ... <portgroup name='engineering'> <virtualport> <parameters profileid='eng'/> </virtualport> </portgroup> <portgroup name='sales'> <virtualport> <parameters profileid='sales'/> </virtualport> </portgroup> </network> and the same <network> on host DEF of: <network> <name>testA</name> ... <virtualport type='802.1Qbg'> <parameters typeid="1193047" typeidversion="2"/> </virtualport> ... <portgroup name='engineering'> <virtualport> <parameters managerid="11"/> </virtualport> </portgroup> <portgroup name='sales'> <virtualport> <parameters managerid="55"/> </virtualport> </portgroup> </network> and a guest <interface> definition of: <interface type='network'> <source network='testA' portgroup='sales'/> <virtualport> <parameters instanceid="09b11c53-8b5c-4eeb-8f00-d84eaa0aaa4f" interfaceid="09b11c53-8b5c-4eeb-8f00-d84eaa0aaa4f"\> </virtualport> ... </interface> If the guest was started on host ABC, the <virtualport> used would be: <virtualport type='openvswitch'> <parameters interfaceid='09b11c53-8b5c-4eeb-8f00-d84eaa0aaa4f' profileid='sales'/> </virtualport> but if that guest was started on host DEF, the <virtualport> would be: <virtualport type='802.1Qbg'> <parameters instanceid="09b11c53-8b5c-4eeb-8f00-d84eaa0aaa4f" typeid="1193047" typeidversion="2" managerid="55"/> </virtualport> Additionally, if none of the involved <virtualport>s had a specified type (this includes cases where no virtualport is given at all),
-
- 20 3月, 2012 1 次提交
-
-
由 Martin Kletzander 提交于
End tag for "host" element was missing in example configuration
-
- 12 1月, 2012 1 次提交
-
-
由 Shradha Shah 提交于
This element will help the user to just specify the SR-IOV physical function in order to access all the Virtual functions attached to it.
-
- 02 1月, 2012 1 次提交
-
-
由 Michal Novotny 提交于
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: NMichal Novotny <minovotn@redhat.com>
-
- 21 10月, 2011 1 次提交
-
-
由 Laine Stump 提交于
In a recent expansion of the documentation on network forward modes, I incorrectly stated that incoming sessions to guests on routed networks were blocked. This is true for guests on NATed networks, but not routed. This patch corrects that error, and adds a pointer to the nwfilter page for those who do want to restrict incoming sessions to hosts on routed networks.
-
- 15 10月, 2011 1 次提交
-
-
由 Laine Stump 提交于
A few people have attempted to use the new forwarding modes with older versions of libvirt. The docs where the modes are described have always stated the minimum required libvirt version, but the examples at the end didn't, which I believe is what has caused the confusion. Similarly, the section on portgroups now has a version tag added at the beginning. I also noticed that there was no example of defining a <dns> hostname, so I added one, as well as making the domain name example more recognizable (by adding ".com" to the domain).
-
- 11 8月, 2011 2 次提交
-
-
由 Laine Stump 提交于
Someone in an IRC channel or an email pointed out a few days ago that the examples of IPv6 addresses in the libvirt documentation were not in the officially reserved "documentation" range. This addresses their concern.
-
由 Laine Stump 提交于
This should have been done with the rest of the patch for virtual switch / network device abstraction. If documents the new elements (and new usage of existing elements) in the <network> XML to support libvirt networks that use existing host bridges and macvtap direct connections, as well as the new <portgroup> element.
-
- 27 7月, 2011 1 次提交
-
-
由 Michal Privoznik 提交于
Every DomainNetDef has a bandwidth, as does every portgroup. Whenever a DomainNetDef of type NETWORK is about to be used, a call is made to networkAllocateActualDevice(). This function chooses the "best" bandwidth object and places it in the DomainActualNetDef. From that point on, whenever some code needs to use the bandwidth data for the interface, it's retrieved with virDomainNetGetActualBandwidth(), which will always return the "best" info as determined in the previous step.
-
- 25 7月, 2011 1 次提交
-
-
由 Michal Privoznik 提交于
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'.
-
- 25 6月, 2011 3 次提交
-
-
由 Laine Stump 提交于
The sub-elements of <ip> had been placed at the same level of indentation as ip itself, implying that they were really elements of <network>. Within that, sub-elements of ip/dhcp were also at that same level. These have been double-indented. At the same time, I realized that the documentation for the new <dns> element had been placed right in the middle of the description of the sub-elements of <ip>. I moved it up out of the way.
-
由 Michal Novotny 提交于
This commit introduces names definition for the DNS hosts file using the following syntax: <dns> <host ip="192.168.1.1"> <name>alias1</name> <name>alias2</name> </host> </dns> Some of the improvements and fixes were done by Laine Stump so I'm putting him into the SOB clause again ;-) Signed-off-by: NMichal Novotny <minovotn@redhat.com> Signed-off-by: NLaine Stump <laine@laine.org>
-
由 Michal Novotny 提交于
This commit introduces the <dns> element and <txt> record for the virtual DNS network. The DNS TXT record can be defined using following syntax in the network XML file: <dns> <txt name="example" value="example value" /> </dns> Also, the Relax-NG scheme has been altered to allow the texts without spaces only for the name element and some nitpicks about memory free'ing have been fixed by Laine so therefore I'm adding Laine to the SOB clause ;-) Signed-off-by: NMichal Novotny <minovotn@redhat.com> Signed-off-by: NLaine Stump <laine@laine.org>
-