- 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>
-
- 08 4月, 2011 1 次提交
-
-
由 Laine Stump 提交于
It was just pointed out that, although I added documentation for the IPv6 additions to the network XML, I neglected to use those additions in the examples. This patch adds an IPv6 address to each of the examples except for the "default" network, since that is a faithful reproduction of the default network config that's automatically installed, which doesn't include any IPv6 address (for good reason - because there is no such thing as IPv6 NAT, there is no one IPv6 address that would work for all installations).
-
- 18 2月, 2011 1 次提交
-
-
由 Laine Stump 提交于
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
-
- 24 12月, 2010 1 次提交
-
-
由 Laine Stump 提交于
At this point everything is already in place to make IPv6 happen, we just need to add a few rules, remove some checks for IPv4-only, and document the changes to the XML on the website.
-
- 23 2月, 2010 2 次提交
-
-
由 Cole Robinson 提交于
-
由 Cole Robinson 提交于
-
- 06 11月, 2009 1 次提交
-
-
由 Matthew Booth 提交于
This patch is the result of running the following command in the docs directory: sed -i 's/\t/ /g; s/\s*$//' *.html.in * docs/*.html.in:convert tabs into 8 spaces and remove trailing whitespace
-
- 28 10月, 2009 1 次提交
-
-
由 Paolo Bonzini 提交于
This patch adds an optional attribute to the <bootp> tag, that allows to specify a TFTP server address other than the address of the DHCP server itself. This can be used to forward the BOOTP settings of the host down to the guest. This is something that configurations such as Xen's default network achieve naturally, but must be done manually for NAT. * docs/formatnetwork.html.in: Document new attribute. * docs/schemas/network.rng: Add it to schema. * src/conf/network_conf.h: Add it to struct. * src/conf/network_conf.c: Add it to parser and pretty printer. * src/network/bridge_driver.c: Put it in the dnsmasq command line. * tests/networkxml2xmlin/netboot-proxy-network.xml tests/networkxml2xmlout/netboot-proxy-network.xml tests/networkxml2xmltest.c: add new tests
-
- 23 9月, 2009 1 次提交
-
-
由 Paolo Bonzini 提交于
Currently, libvirtd will start a dnsmasq process for the virtual network, but (aside from killing the dnsmasq process and replacing it), there's no way to define tftp boot options. This change introduces the appropriate tags to the dhcp configuration: <network> <name>default</name> <bridge name="virbr%d" /> <forward/> <ip address="192.168.122.1" netmask="255.255.255.0"> <tftp root="/var/lib/tftproot" /> <dhcp> <range start="192.168.122.2" end="192.168.122.254" /> <bootp file="pxeboot.img"/> </dhcp> </ip> </network> When the attributes are present, these are passed to the arguments to dnsmasq: dnsmasq [...] --enable-tftp --tftp-root /srv/tftp --dhcp-boot pxeboot.img ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^^^^^ from <tftp /> from <bootp /> At present, only local tftp servers are supported (ie, dnsmasq runs as the tftp server), but we could improve this in future by adding a server= attribute. Signed-off-by: NJeremy Kerr <jk@ozlabs.org> Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com> 2009-09-21 Paolo Bonzini <pbonzini@redhat.com> Jeremy Kerr <jk@ozlabs.org> * docs/formatnetwork.html.in: Document new tags. * docs/formatnetwork.html: Regenerate. * docs/schemas/network.rng: Update. * src/network_conf.c (virNetworkDefFree): Free new fields. (virNetworkDHCPRangeDefParseXML): Parse <bootp>. (virNetworkIPParseXML): New, parsing <dhcp> and <tftp>. (virNetworkDefParseXML): Use virNetworkIPParseXML instead of virNetworkDHCPRangeDefParseXML. (virNetworkDefFormat): Pretty print new fields. * src/network_conf.h (struct _virNetworkDef): Add netboot fields. * src/network_driver.c (networkBuildDnsmasqArgv): Add TFTP and BOOTP arguments. * tests/Makefile.am (EXTRA_DIST): Add networkschemadata. * tests/networkschematest: Look in networkschemadata. * tests/networkschemadata/netboot-network.xml: New.
-
- 26 2月, 2009 1 次提交
-
-
由 Daniel Veillard 提交于
* docs/formatnetwork.html docs/formatnetwork.html.in: patch from Charles Duffy documenting static host IP assignments. daniel
-
- 09 7月, 2008 1 次提交
-
-
由 Daniel P. Berrange 提交于
-
- 07 5月, 2008 1 次提交
-
-
由 Daniel P. Berrange 提交于
-
- 29 4月, 2008 1 次提交
-
-
由 Daniel P. Berrange 提交于
-