2008-10-10 13:57:13 +00:00
|
|
|
/*
|
2010-06-19 18:08:25 +00:00
|
|
|
* bridge_driver.c: core driver methods for managing network
|
2008-10-10 13:57:13 +00:00
|
|
|
*
|
2011-12-14 10:50:30 +00:00
|
|
|
* Copyright (C) 2006-2012 Red Hat, Inc.
|
2008-10-10 13:57:13 +00:00
|
|
|
* Copyright (C) 2006 Daniel P. Berrange
|
|
|
|
*
|
|
|
|
* This library is free software; you can redistribute it and/or
|
|
|
|
* modify it under the terms of the GNU Lesser General Public
|
|
|
|
* License as published by the Free Software Foundation; either
|
|
|
|
* version 2.1 of the License, or (at your option) any later version.
|
|
|
|
*
|
|
|
|
* This library is distributed in the hope that it will be useful,
|
|
|
|
* but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
|
|
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
|
|
|
|
* Lesser General Public License for more details.
|
|
|
|
*
|
|
|
|
* You should have received a copy of the GNU Lesser General Public
|
2012-07-21 10:06:23 +00:00
|
|
|
* License along with this library; If not, see
|
|
|
|
* <http://www.gnu.org/licenses/>.
|
2008-10-10 13:57:13 +00:00
|
|
|
*
|
|
|
|
* Author: Daniel P. Berrange <berrange@redhat.com>
|
|
|
|
*/
|
|
|
|
|
|
|
|
#include <config.h>
|
|
|
|
|
|
|
|
#include <sys/types.h>
|
|
|
|
#include <sys/poll.h>
|
|
|
|
#include <limits.h>
|
|
|
|
#include <string.h>
|
|
|
|
#include <stdio.h>
|
|
|
|
#include <stdarg.h>
|
|
|
|
#include <stdlib.h>
|
|
|
|
#include <unistd.h>
|
|
|
|
#include <errno.h>
|
|
|
|
#include <sys/utsname.h>
|
|
|
|
#include <sys/stat.h>
|
|
|
|
#include <fcntl.h>
|
|
|
|
#include <signal.h>
|
|
|
|
#include <paths.h>
|
|
|
|
#include <pwd.h>
|
|
|
|
#include <stdio.h>
|
|
|
|
#include <sys/wait.h>
|
|
|
|
#include <sys/ioctl.h>
|
Split bridge.h into three separate files
Following the renaming of the bridge management APIs, we can now
split the source file into 3 corresponding pieces
* src/util/virnetdev.c: APIs for any type of network interface
* src/util/virnetdevbridge.c: APIs for bridge interfaces
* src/util/virnetdevtap.c: APIs for TAP interfaces
* src/util/virnetdev.c, src/util/virnetdev.h,
src/util/virnetdevbridge.c, src/util/virnetdevbridge.h,
src/util/virnetdevtap.c, src/util/virnetdevtap.h: Copied
from bridge.{c,h}
* src/util/bridge.c, src/util/bridge.h: Split into 3 pieces
* src/lxc/lxc_driver.c, src/network/bridge_driver.c,
src/openvz/openvz_driver.c, src/qemu/qemu_command.c,
src/qemu/qemu_conf.h, src/uml/uml_conf.c, src/uml/uml_conf.h,
src/uml/uml_driver.c: Update #include directives
2011-11-02 13:41:58 +00:00
|
|
|
#include <net/if.h>
|
2008-10-10 13:57:13 +00:00
|
|
|
|
2008-11-04 22:30:33 +00:00
|
|
|
#include "virterror_internal.h"
|
2008-11-04 23:22:06 +00:00
|
|
|
#include "datatypes.h"
|
2009-09-15 17:52:58 +00:00
|
|
|
#include "bridge_driver.h"
|
2008-10-10 13:57:13 +00:00
|
|
|
#include "network_conf.h"
|
|
|
|
#include "driver.h"
|
|
|
|
#include "buf.h"
|
2011-08-05 13:13:12 +00:00
|
|
|
#include "virpidfile.h"
|
2008-10-10 13:57:13 +00:00
|
|
|
#include "util.h"
|
2010-12-10 18:54:48 +00:00
|
|
|
#include "command.h"
|
2008-10-10 13:57:13 +00:00
|
|
|
#include "memory.h"
|
|
|
|
#include "uuid.h"
|
|
|
|
#include "iptables.h"
|
2009-05-20 13:37:30 +00:00
|
|
|
#include "logging.h"
|
2010-04-26 14:07:25 +00:00
|
|
|
#include "dnsmasq.h"
|
2010-11-16 14:54:17 +00:00
|
|
|
#include "configmake.h"
|
Split bridge.h into three separate files
Following the renaming of the bridge management APIs, we can now
split the source file into 3 corresponding pieces
* src/util/virnetdev.c: APIs for any type of network interface
* src/util/virnetdevbridge.c: APIs for bridge interfaces
* src/util/virnetdevtap.c: APIs for TAP interfaces
* src/util/virnetdev.c, src/util/virnetdev.h,
src/util/virnetdevbridge.c, src/util/virnetdevbridge.h,
src/util/virnetdevtap.c, src/util/virnetdevtap.h: Copied
from bridge.{c,h}
* src/util/bridge.c, src/util/bridge.h: Split into 3 pieces
* src/lxc/lxc_driver.c, src/network/bridge_driver.c,
src/openvz/openvz_driver.c, src/qemu/qemu_command.c,
src/qemu/qemu_conf.h, src/uml/uml_conf.c, src/uml/uml_conf.h,
src/uml/uml_driver.c: Update #include directives
2011-11-02 13:41:58 +00:00
|
|
|
#include "virnetdev.h"
|
|
|
|
#include "virnetdevbridge.h"
|
|
|
|
#include "virnetdevtap.h"
|
network: merge relevant virtualports rather than choosing one
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),
2012-08-02 18:10:00 +00:00
|
|
|
#include "virnetdevvportprofile.h"
|
2008-10-10 13:57:13 +00:00
|
|
|
|
2010-11-16 14:54:17 +00:00
|
|
|
#define NETWORK_PID_DIR LOCALSTATEDIR "/run/libvirt/network"
|
|
|
|
#define NETWORK_STATE_DIR LOCALSTATEDIR "/lib/libvirt/network"
|
2009-01-20 17:13:33 +00:00
|
|
|
|
2010-11-16 14:54:17 +00:00
|
|
|
#define DNSMASQ_STATE_DIR LOCALSTATEDIR "/lib/libvirt/dnsmasq"
|
2010-12-20 06:14:11 +00:00
|
|
|
#define RADVD_STATE_DIR LOCALSTATEDIR "/lib/libvirt/radvd"
|
2010-04-26 14:07:25 +00:00
|
|
|
|
2009-01-20 17:13:33 +00:00
|
|
|
#define VIR_FROM_THIS VIR_FROM_NETWORK
|
|
|
|
|
2008-10-10 13:57:13 +00:00
|
|
|
/* Main driver state */
|
|
|
|
struct network_driver {
|
2009-01-15 19:56:05 +00:00
|
|
|
virMutex lock;
|
2008-12-04 21:38:38 +00:00
|
|
|
|
2008-10-10 14:50:26 +00:00
|
|
|
virNetworkObjList networks;
|
2008-10-10 13:57:13 +00:00
|
|
|
|
|
|
|
iptablesContext *iptables;
|
|
|
|
char *networkConfigDir;
|
|
|
|
char *networkAutostartDir;
|
|
|
|
char *logDir;
|
|
|
|
};
|
|
|
|
|
2008-12-04 21:38:38 +00:00
|
|
|
|
|
|
|
static void networkDriverLock(struct network_driver *driver)
|
|
|
|
{
|
2009-01-15 19:56:05 +00:00
|
|
|
virMutexLock(&driver->lock);
|
2008-12-04 21:38:38 +00:00
|
|
|
}
|
|
|
|
static void networkDriverUnlock(struct network_driver *driver)
|
|
|
|
{
|
2009-01-15 19:56:05 +00:00
|
|
|
virMutexUnlock(&driver->lock);
|
2008-12-04 21:38:38 +00:00
|
|
|
}
|
|
|
|
|
2008-10-10 13:57:13 +00:00
|
|
|
static int networkShutdown(void);
|
|
|
|
|
network: separate Start/Shutdown functions for new network types
Previously all networks were composed of bridge devices created and
managed by libvirt, and the same operations needed to be done for all
of them when they were started and stopped (create and start the
bridge device, configure its MAC address and IP address, add iptables
rules). The new network types are (for now at least) managed outside
of libvirt, and the network object is used only to contain information
about the network, which is then used as each individual guest
connects itself.
This means that when starting/stopping one of these new networks, we
really want to do nothing, aside from marking the network as
active/inactive.
This has been setup as toplevel Start/Shutdown functions that do the
small bit of common stuff, then have a switch statement to execute
network type-specific start/shutdown code, then do a bit more common
code. The type-specific functions called for the new host bridge and
macvtap based types are currently empty.
In the future these functions may actually do something, and we will
surely add more functions that are similarly patterned. Once
everything has settled, we can make a table of "sub-driver" function
pointers for each network type, and store a pointer to that table in
the network object, then we can replace the switch statements with
calls to functions in the table.
The final step in this will be to add a new table (and corresponding
new functions) for new network types as they are added.
2011-06-30 21:05:07 +00:00
|
|
|
static int networkStartNetwork(struct network_driver *driver,
|
|
|
|
virNetworkObjPtr network);
|
|
|
|
|
|
|
|
static int networkShutdownNetwork(struct network_driver *driver,
|
|
|
|
virNetworkObjPtr network);
|
|
|
|
|
|
|
|
static int networkStartNetworkVirtual(struct network_driver *driver,
|
2010-02-10 10:22:52 +00:00
|
|
|
virNetworkObjPtr network);
|
2008-10-10 13:57:13 +00:00
|
|
|
|
network: separate Start/Shutdown functions for new network types
Previously all networks were composed of bridge devices created and
managed by libvirt, and the same operations needed to be done for all
of them when they were started and stopped (create and start the
bridge device, configure its MAC address and IP address, add iptables
rules). The new network types are (for now at least) managed outside
of libvirt, and the network object is used only to contain information
about the network, which is then used as each individual guest
connects itself.
This means that when starting/stopping one of these new networks, we
really want to do nothing, aside from marking the network as
active/inactive.
This has been setup as toplevel Start/Shutdown functions that do the
small bit of common stuff, then have a switch statement to execute
network type-specific start/shutdown code, then do a bit more common
code. The type-specific functions called for the new host bridge and
macvtap based types are currently empty.
In the future these functions may actually do something, and we will
surely add more functions that are similarly patterned. Once
everything has settled, we can make a table of "sub-driver" function
pointers for each network type, and store a pointer to that table in
the network object, then we can replace the switch statements with
calls to functions in the table.
The final step in this will be to add a new table (and corresponding
new functions) for new network types as they are added.
2011-06-30 21:05:07 +00:00
|
|
|
static int networkShutdownNetworkVirtual(struct network_driver *driver,
|
|
|
|
virNetworkObjPtr network);
|
|
|
|
|
|
|
|
static int networkStartNetworkExternal(struct network_driver *driver,
|
|
|
|
virNetworkObjPtr network);
|
|
|
|
|
|
|
|
static int networkShutdownNetworkExternal(struct network_driver *driver,
|
2010-02-10 10:22:52 +00:00
|
|
|
virNetworkObjPtr network);
|
2008-10-10 13:57:13 +00:00
|
|
|
|
2009-12-10 11:27:17 +00:00
|
|
|
static void networkReloadIptablesRules(struct network_driver *driver);
|
|
|
|
|
2008-10-10 13:57:13 +00:00
|
|
|
static struct network_driver *driverState = NULL;
|
|
|
|
|
2011-03-11 18:20:48 +00:00
|
|
|
static char *
|
2011-06-27 14:55:13 +00:00
|
|
|
networkDnsmasqLeaseFileNameDefault(const char *netname)
|
2011-03-11 18:20:48 +00:00
|
|
|
{
|
|
|
|
char *leasefile;
|
|
|
|
|
2011-08-02 20:26:17 +00:00
|
|
|
ignore_value(virAsprintf(&leasefile, DNSMASQ_STATE_DIR "/%s.leases",
|
|
|
|
netname));
|
2011-03-11 18:20:48 +00:00
|
|
|
return leasefile;
|
|
|
|
}
|
|
|
|
|
2011-06-27 14:55:13 +00:00
|
|
|
networkDnsmasqLeaseFileNameFunc networkDnsmasqLeaseFileName =
|
|
|
|
networkDnsmasqLeaseFileNameDefault;
|
|
|
|
|
2010-12-20 06:14:11 +00:00
|
|
|
static char *
|
|
|
|
networkRadvdPidfileBasename(const char *netname)
|
|
|
|
{
|
|
|
|
/* this is simple but we want to be sure it's consistently done */
|
|
|
|
char *pidfilebase;
|
|
|
|
|
2011-08-02 20:26:17 +00:00
|
|
|
ignore_value(virAsprintf(&pidfilebase, "%s-radvd", netname));
|
2010-12-20 06:14:11 +00:00
|
|
|
return pidfilebase;
|
|
|
|
}
|
|
|
|
|
|
|
|
static char *
|
|
|
|
networkRadvdConfigFileName(const char *netname)
|
|
|
|
{
|
|
|
|
char *configfile;
|
|
|
|
|
2011-08-02 20:26:17 +00:00
|
|
|
ignore_value(virAsprintf(&configfile, RADVD_STATE_DIR "/%s-radvd.conf",
|
|
|
|
netname));
|
2010-12-20 06:14:11 +00:00
|
|
|
return configfile;
|
|
|
|
}
|
2008-10-10 13:57:13 +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
|
|
|
static char *
|
|
|
|
networkBridgeDummyNicName(const char *brname)
|
|
|
|
{
|
network: truncate bridges' dummy tap device names to IFNAMSIZ (15) chars
This patch addresses:
https://bugzilla.redhat.com/show_bug.cgi?id=694382
In order to give each libvirt-created bridge a fixed MAC address,
commit 5754dbd56d4738112a86776c09e810e32f7c3224, added code to create
a dummy tap device with guaranteed lowest MAC address and attach it to
the bridge. This tap device was given the name "${bridgename}-nic".
However, an interface device name must be IFNAMSIZ (15) characters or
less, so a valid ${bridgename} such as "verylongname123" (15
characters) would lead to an invalid tap device name
("verylongname123-nic" - 19 characters), and that in turn led to a
failure to bring up the network.
The solution is to shorten the part of the original name used to
generate the tap device name. However, simply truncating it is
insufficient, because the last few characters of an interface name are
often a number used to indicate one of a list of several similar
devices (for example, "verylongname123", "verylongname124", etc) and
simple truncation would lead to duplicate names (eg "verlongnam-nic"
and "verylongnam-nic"). So instead we take the first 8 characters of
$bridgename ("verylong" in the example), add on the final 3 bytes
("123"), then add "-nic" (so "verylong123-nic"). Not pretty, but it
is much more likely to generate a unique name, and is reproducible
(unlike, say, a random number).
2011-04-13 16:38:58 +00:00
|
|
|
static const char dummyNicSuffix[] = "-nic";
|
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
|
|
|
char *nicname;
|
|
|
|
|
network: truncate bridges' dummy tap device names to IFNAMSIZ (15) chars
This patch addresses:
https://bugzilla.redhat.com/show_bug.cgi?id=694382
In order to give each libvirt-created bridge a fixed MAC address,
commit 5754dbd56d4738112a86776c09e810e32f7c3224, added code to create
a dummy tap device with guaranteed lowest MAC address and attach it to
the bridge. This tap device was given the name "${bridgename}-nic".
However, an interface device name must be IFNAMSIZ (15) characters or
less, so a valid ${bridgename} such as "verylongname123" (15
characters) would lead to an invalid tap device name
("verylongname123-nic" - 19 characters), and that in turn led to a
failure to bring up the network.
The solution is to shorten the part of the original name used to
generate the tap device name. However, simply truncating it is
insufficient, because the last few characters of an interface name are
often a number used to indicate one of a list of several similar
devices (for example, "verylongname123", "verylongname124", etc) and
simple truncation would lead to duplicate names (eg "verlongnam-nic"
and "verylongnam-nic"). So instead we take the first 8 characters of
$bridgename ("verylong" in the example), add on the final 3 bytes
("123"), then add "-nic" (so "verylong123-nic"). Not pretty, but it
is much more likely to generate a unique name, and is reproducible
(unlike, say, a random number).
2011-04-13 16:38:58 +00:00
|
|
|
if (strlen(brname) + sizeof(dummyNicSuffix) > IFNAMSIZ) {
|
|
|
|
/* because the length of an ifname is limited to IFNAMSIZ-1
|
|
|
|
* (usually 15), and we're adding 4 more characters, we must
|
|
|
|
* truncate the original name to 11 to fit. In order to catch
|
|
|
|
* a possible numeric ending (eg virbr0, virbr1, etc), we grab
|
|
|
|
* the first 8 and last 3 characters of the string.
|
|
|
|
*/
|
2011-08-02 20:26:17 +00:00
|
|
|
ignore_value(virAsprintf(&nicname, "%.*s%s%s",
|
|
|
|
/* space for last 3 chars + "-nic" + NULL */
|
|
|
|
(int)(IFNAMSIZ - (3 + sizeof(dummyNicSuffix))),
|
|
|
|
brname, brname + strlen(brname) - 3,
|
|
|
|
dummyNicSuffix));
|
network: truncate bridges' dummy tap device names to IFNAMSIZ (15) chars
This patch addresses:
https://bugzilla.redhat.com/show_bug.cgi?id=694382
In order to give each libvirt-created bridge a fixed MAC address,
commit 5754dbd56d4738112a86776c09e810e32f7c3224, added code to create
a dummy tap device with guaranteed lowest MAC address and attach it to
the bridge. This tap device was given the name "${bridgename}-nic".
However, an interface device name must be IFNAMSIZ (15) characters or
less, so a valid ${bridgename} such as "verylongname123" (15
characters) would lead to an invalid tap device name
("verylongname123-nic" - 19 characters), and that in turn led to a
failure to bring up the network.
The solution is to shorten the part of the original name used to
generate the tap device name. However, simply truncating it is
insufficient, because the last few characters of an interface name are
often a number used to indicate one of a list of several similar
devices (for example, "verylongname123", "verylongname124", etc) and
simple truncation would lead to duplicate names (eg "verlongnam-nic"
and "verylongnam-nic"). So instead we take the first 8 characters of
$bridgename ("verylong" in the example), add on the final 3 bytes
("123"), then add "-nic" (so "verylong123-nic"). Not pretty, but it
is much more likely to generate a unique name, and is reproducible
(unlike, say, a random number).
2011-04-13 16:38:58 +00:00
|
|
|
} else {
|
2011-08-02 20:26:17 +00:00
|
|
|
ignore_value(virAsprintf(&nicname, "%s%s", brname, dummyNicSuffix));
|
network: truncate bridges' dummy tap device names to IFNAMSIZ (15) chars
This patch addresses:
https://bugzilla.redhat.com/show_bug.cgi?id=694382
In order to give each libvirt-created bridge a fixed MAC address,
commit 5754dbd56d4738112a86776c09e810e32f7c3224, added code to create
a dummy tap device with guaranteed lowest MAC address and attach it to
the bridge. This tap device was given the name "${bridgename}-nic".
However, an interface device name must be IFNAMSIZ (15) characters or
less, so a valid ${bridgename} such as "verylongname123" (15
characters) would lead to an invalid tap device name
("verylongname123-nic" - 19 characters), and that in turn led to a
failure to bring up the network.
The solution is to shorten the part of the original name used to
generate the tap device name. However, simply truncating it is
insufficient, because the last few characters of an interface name are
often a number used to indicate one of a list of several similar
devices (for example, "verylongname123", "verylongname124", etc) and
simple truncation would lead to duplicate names (eg "verlongnam-nic"
and "verylongnam-nic"). So instead we take the first 8 characters of
$bridgename ("verylong" in the example), add on the final 3 bytes
("123"), then add "-nic" (so "verylong123-nic"). Not pretty, but it
is much more likely to generate a unique name, and is reproducible
(unlike, say, a random number).
2011-04-13 16:38:58 +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
|
|
|
return nicname;
|
|
|
|
}
|
|
|
|
|
2009-01-20 22:36:10 +00:00
|
|
|
static void
|
|
|
|
networkFindActiveConfigs(struct network_driver *driver) {
|
|
|
|
unsigned int i;
|
|
|
|
|
|
|
|
for (i = 0 ; i < driver->networks.count ; i++) {
|
|
|
|
virNetworkObjPtr obj = driver->networks.objs[i];
|
|
|
|
virNetworkDefPtr tmp;
|
|
|
|
char *config;
|
|
|
|
|
|
|
|
virNetworkObjLock(obj);
|
|
|
|
|
2010-02-10 10:22:52 +00:00
|
|
|
if ((config = virNetworkConfigFile(NETWORK_STATE_DIR,
|
2009-01-20 22:36:10 +00:00
|
|
|
obj->def->name)) == NULL) {
|
|
|
|
virNetworkObjUnlock(obj);
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (access(config, R_OK) < 0) {
|
|
|
|
VIR_FREE(config);
|
|
|
|
virNetworkObjUnlock(obj);
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Try and load the live config */
|
2010-02-10 10:22:52 +00:00
|
|
|
tmp = virNetworkDefParseFile(config);
|
2009-01-20 22:36:10 +00:00
|
|
|
VIR_FREE(config);
|
|
|
|
if (tmp) {
|
|
|
|
obj->newDef = obj->def;
|
|
|
|
obj->def = tmp;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* If bridge exists, then mark it active */
|
|
|
|
if (obj->def->bridge &&
|
2011-11-11 08:20:19 +00:00
|
|
|
virNetDevExists(obj->def->bridge) == 1) {
|
2009-01-20 22:36:10 +00:00
|
|
|
obj->active = 1;
|
|
|
|
|
2010-12-20 06:14:11 +00:00
|
|
|
/* Try and read dnsmasq/radvd pids if any */
|
|
|
|
if (obj->def->ips && (obj->def->nips > 0)) {
|
2011-08-05 13:41:25 +00:00
|
|
|
char *radvdpidbase;
|
|
|
|
|
|
|
|
ignore_value(virPidFileReadIfAlive(NETWORK_PID_DIR, obj->def->name,
|
|
|
|
&obj->dnsmasqPid, DNSMASQ));
|
2009-01-20 22:36:10 +00:00
|
|
|
|
2010-12-20 06:14:11 +00:00
|
|
|
if (!(radvdpidbase = networkRadvdPidfileBasename(obj->def->name))) {
|
2010-02-04 18:19:08 +00:00
|
|
|
virReportOOMError();
|
2009-10-16 10:09:13 +00:00
|
|
|
goto cleanup;
|
|
|
|
}
|
2011-08-05 13:41:25 +00:00
|
|
|
ignore_value(virPidFileReadIfAlive(NETWORK_PID_DIR, radvdpidbase,
|
|
|
|
&obj->radvdPid, RADVD));
|
2010-12-20 06:14:11 +00:00
|
|
|
VIR_FREE(radvdpidbase);
|
2009-01-20 22:36:10 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2009-10-16 10:09:13 +00:00
|
|
|
cleanup:
|
2009-01-20 22:36:10 +00:00
|
|
|
virNetworkObjUnlock(obj);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
|
2008-10-10 14:50:26 +00:00
|
|
|
static void
|
|
|
|
networkAutostartConfigs(struct network_driver *driver) {
|
|
|
|
unsigned int i;
|
2008-10-10 13:57:13 +00:00
|
|
|
|
2008-10-10 14:50:26 +00:00
|
|
|
for (i = 0 ; i < driver->networks.count ; i++) {
|
2008-12-04 21:38:38 +00:00
|
|
|
virNetworkObjLock(driver->networks.objs[i]);
|
2008-10-10 14:50:26 +00:00
|
|
|
if (driver->networks.objs[i]->autostart &&
|
network: separate Start/Shutdown functions for new network types
Previously all networks were composed of bridge devices created and
managed by libvirt, and the same operations needed to be done for all
of them when they were started and stopped (create and start the
bridge device, configure its MAC address and IP address, add iptables
rules). The new network types are (for now at least) managed outside
of libvirt, and the network object is used only to contain information
about the network, which is then used as each individual guest
connects itself.
This means that when starting/stopping one of these new networks, we
really want to do nothing, aside from marking the network as
active/inactive.
This has been setup as toplevel Start/Shutdown functions that do the
small bit of common stuff, then have a switch statement to execute
network type-specific start/shutdown code, then do a bit more common
code. The type-specific functions called for the new host bridge and
macvtap based types are currently empty.
In the future these functions may actually do something, and we will
surely add more functions that are similarly patterned. Once
everything has settled, we can make a table of "sub-driver" function
pointers for each network type, and store a pointer to that table in
the network object, then we can replace the switch statements with
calls to functions in the table.
The final step in this will be to add a new table (and corresponding
new functions) for new network types as they are added.
2011-06-30 21:05:07 +00:00
|
|
|
!virNetworkObjIsActive(driver->networks.objs[i])) {
|
|
|
|
if (networkStartNetwork(driver, driver->networks.objs[i]) < 0) {
|
2009-05-20 13:37:30 +00:00
|
|
|
/* failed to start but already logged */
|
network: separate Start/Shutdown functions for new network types
Previously all networks were composed of bridge devices created and
managed by libvirt, and the same operations needed to be done for all
of them when they were started and stopped (create and start the
bridge device, configure its MAC address and IP address, add iptables
rules). The new network types are (for now at least) managed outside
of libvirt, and the network object is used only to contain information
about the network, which is then used as each individual guest
connects itself.
This means that when starting/stopping one of these new networks, we
really want to do nothing, aside from marking the network as
active/inactive.
This has been setup as toplevel Start/Shutdown functions that do the
small bit of common stuff, then have a switch statement to execute
network type-specific start/shutdown code, then do a bit more common
code. The type-specific functions called for the new host bridge and
macvtap based types are currently empty.
In the future these functions may actually do something, and we will
surely add more functions that are similarly patterned. Once
everything has settled, we can make a table of "sub-driver" function
pointers for each network type, and store a pointer to that table in
the network object, then we can replace the switch statements with
calls to functions in the table.
The final step in this will be to add a new table (and corresponding
new functions) for new network types as they are added.
2011-06-30 21:05:07 +00:00
|
|
|
}
|
2008-10-10 13:57:13 +00:00
|
|
|
}
|
2008-12-04 21:38:38 +00:00
|
|
|
virNetworkObjUnlock(driver->networks.objs[i]);
|
2008-10-10 13:57:13 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* networkStartup:
|
|
|
|
*
|
|
|
|
* Initialization function for the QEmu daemon
|
|
|
|
*/
|
|
|
|
static int
|
2009-06-12 13:20:13 +00:00
|
|
|
networkStartup(int privileged) {
|
2008-10-10 13:57:13 +00:00
|
|
|
char *base = NULL;
|
|
|
|
|
|
|
|
if (VIR_ALLOC(driverState) < 0)
|
2008-12-04 21:37:52 +00:00
|
|
|
goto error;
|
2008-10-10 13:57:13 +00:00
|
|
|
|
2009-01-15 19:56:05 +00:00
|
|
|
if (virMutexInit(&driverState->lock) < 0) {
|
|
|
|
VIR_FREE(driverState);
|
|
|
|
goto error;
|
|
|
|
}
|
2008-12-04 21:38:38 +00:00
|
|
|
networkDriverLock(driverState);
|
|
|
|
|
2009-06-12 13:20:13 +00:00
|
|
|
if (privileged) {
|
2008-12-23 13:03:29 +00:00
|
|
|
if (virAsprintf(&driverState->logDir,
|
2010-11-16 14:54:17 +00:00
|
|
|
"%s/log/libvirt/qemu", LOCALSTATEDIR) == -1)
|
2008-10-10 13:57:13 +00:00
|
|
|
goto out_of_memory;
|
|
|
|
|
2010-11-16 14:54:17 +00:00
|
|
|
if ((base = strdup (SYSCONFDIR "/libvirt")) == NULL)
|
2008-10-10 13:57:13 +00:00
|
|
|
goto out_of_memory;
|
|
|
|
} else {
|
2012-05-24 12:29:42 +00:00
|
|
|
char *userdir = virGetUserCacheDirectory();
|
2009-01-22 19:41:48 +00:00
|
|
|
|
|
|
|
if (!userdir)
|
|
|
|
goto error;
|
2008-10-10 13:57:13 +00:00
|
|
|
|
2008-12-23 13:03:29 +00:00
|
|
|
if (virAsprintf(&driverState->logDir,
|
2012-05-03 16:36:27 +00:00
|
|
|
"%s/qemu/log", userdir) == -1) {
|
2009-01-22 19:41:48 +00:00
|
|
|
VIR_FREE(userdir);
|
2008-10-10 13:57:13 +00:00
|
|
|
goto out_of_memory;
|
2009-01-22 19:41:48 +00:00
|
|
|
}
|
2012-05-03 16:36:27 +00:00
|
|
|
VIR_FREE(userdir);
|
2008-10-10 13:57:13 +00:00
|
|
|
|
2012-05-24 12:29:42 +00:00
|
|
|
userdir = virGetUserConfigDirectory();
|
2012-05-03 16:36:27 +00:00
|
|
|
if (virAsprintf(&base, "%s", userdir) == -1) {
|
2009-01-22 19:41:48 +00:00
|
|
|
VIR_FREE(userdir);
|
2008-10-10 13:57:13 +00:00
|
|
|
goto out_of_memory;
|
|
|
|
}
|
2009-01-22 19:41:48 +00:00
|
|
|
VIR_FREE(userdir);
|
2008-10-10 13:57:13 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/* Configuration paths are either ~/.libvirt/qemu/... (session) or
|
|
|
|
* /etc/libvirt/qemu/... (system).
|
|
|
|
*/
|
2008-12-23 13:03:29 +00:00
|
|
|
if (virAsprintf(&driverState->networkConfigDir, "%s/qemu/networks", base) == -1)
|
2008-10-10 13:57:13 +00:00
|
|
|
goto out_of_memory;
|
|
|
|
|
2008-12-23 13:03:29 +00:00
|
|
|
if (virAsprintf(&driverState->networkAutostartDir, "%s/qemu/networks/autostart",
|
|
|
|
base) == -1)
|
2008-10-10 13:57:13 +00:00
|
|
|
goto out_of_memory;
|
|
|
|
|
|
|
|
VIR_FREE(base);
|
|
|
|
|
2009-01-20 22:36:10 +00:00
|
|
|
if (!(driverState->iptables = iptablesContextNew())) {
|
2009-05-20 13:37:30 +00:00
|
|
|
goto out_of_memory;
|
2009-01-20 22:36:10 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
2010-02-10 10:22:52 +00:00
|
|
|
if (virNetworkLoadAllConfigs(&driverState->networks,
|
2008-10-10 13:57:13 +00:00
|
|
|
driverState->networkConfigDir,
|
2008-12-04 21:37:52 +00:00
|
|
|
driverState->networkAutostartDir) < 0)
|
|
|
|
goto error;
|
|
|
|
|
2009-01-20 22:36:10 +00:00
|
|
|
networkFindActiveConfigs(driverState);
|
2009-12-10 11:27:17 +00:00
|
|
|
networkReloadIptablesRules(driverState);
|
2008-10-10 13:57:13 +00:00
|
|
|
networkAutostartConfigs(driverState);
|
|
|
|
|
2008-12-04 21:38:38 +00:00
|
|
|
networkDriverUnlock(driverState);
|
|
|
|
|
2008-10-10 13:57:13 +00:00
|
|
|
return 0;
|
|
|
|
|
2008-12-04 21:37:52 +00:00
|
|
|
out_of_memory:
|
2010-02-04 18:19:08 +00:00
|
|
|
virReportOOMError();
|
2008-12-04 21:37:52 +00:00
|
|
|
|
|
|
|
error:
|
2008-12-04 21:38:38 +00:00
|
|
|
if (driverState)
|
|
|
|
networkDriverUnlock(driverState);
|
|
|
|
|
2008-10-10 13:57:13 +00:00
|
|
|
VIR_FREE(base);
|
2008-12-04 21:37:52 +00:00
|
|
|
networkShutdown();
|
2008-10-10 13:57:13 +00:00
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* networkReload:
|
|
|
|
*
|
|
|
|
* Function to restart the QEmu daemon, it will recheck the configuration
|
|
|
|
* files and update its state and the networking
|
|
|
|
*/
|
|
|
|
static int
|
|
|
|
networkReload(void) {
|
2008-10-10 14:50:26 +00:00
|
|
|
if (!driverState)
|
|
|
|
return 0;
|
|
|
|
|
2008-12-04 21:38:38 +00:00
|
|
|
networkDriverLock(driverState);
|
2010-02-10 10:22:52 +00:00
|
|
|
virNetworkLoadAllConfigs(&driverState->networks,
|
2008-10-10 13:57:13 +00:00
|
|
|
driverState->networkConfigDir,
|
|
|
|
driverState->networkAutostartDir);
|
2009-12-10 11:27:17 +00:00
|
|
|
networkReloadIptablesRules(driverState);
|
2008-10-10 13:57:13 +00:00
|
|
|
networkAutostartConfigs(driverState);
|
2008-12-04 21:38:38 +00:00
|
|
|
networkDriverUnlock(driverState);
|
2008-10-10 13:57:13 +00:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* networkActive:
|
|
|
|
*
|
|
|
|
* Checks if the QEmu daemon is active, i.e. has an active domain or
|
|
|
|
* an active network
|
|
|
|
*
|
|
|
|
* Returns 1 if active, 0 otherwise
|
|
|
|
*/
|
|
|
|
static int
|
|
|
|
networkActive(void) {
|
2008-10-10 14:50:26 +00:00
|
|
|
unsigned int i;
|
2008-12-04 21:37:52 +00:00
|
|
|
int active = 0;
|
2008-10-10 13:57:13 +00:00
|
|
|
|
2008-10-10 14:50:26 +00:00
|
|
|
if (!driverState)
|
|
|
|
return 0;
|
|
|
|
|
2008-12-04 21:38:38 +00:00
|
|
|
networkDriverLock(driverState);
|
2008-12-04 21:37:52 +00:00
|
|
|
for (i = 0 ; i < driverState->networks.count ; i++) {
|
|
|
|
virNetworkObjPtr net = driverState->networks.objs[i];
|
2008-12-04 21:38:38 +00:00
|
|
|
virNetworkObjLock(net);
|
Rename internal APis
Rename virDomainIsActive to virDomainObjIsActive, and
virInterfaceIsActive to virInterfaceObjIsActive and finally
virNetworkIsActive to virNetworkObjIsActive.
* src/conf/domain_conf.c, src/conf/domain_conf.h,
src/conf/interface_conf.h, src/conf/network_conf.c,
src/conf/network_conf.h, src/lxc/lxc_driver.c,
src/network/bridge_driver.c, src/opennebula/one_driver.c,
src/openvz/openvz_driver.c, src/qemu/qemu_driver.c,
src/test/test_driver.c, src/uml/uml_driver.c: Update for
renamed APIs.
2009-10-20 14:51:03 +00:00
|
|
|
if (virNetworkObjIsActive(net))
|
2008-12-04 21:37:52 +00:00
|
|
|
active = 1;
|
2008-12-04 21:38:38 +00:00
|
|
|
virNetworkObjUnlock(net);
|
2008-12-04 21:37:52 +00:00
|
|
|
}
|
2008-12-04 21:38:38 +00:00
|
|
|
networkDriverUnlock(driverState);
|
2008-12-04 21:37:52 +00:00
|
|
|
return active;
|
2008-10-10 13:57:13 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* networkShutdown:
|
|
|
|
*
|
|
|
|
* Shutdown the QEmu daemon, it will stop all active domains and networks
|
|
|
|
*/
|
|
|
|
static int
|
|
|
|
networkShutdown(void) {
|
|
|
|
if (!driverState)
|
|
|
|
return -1;
|
|
|
|
|
2008-12-04 21:38:38 +00:00
|
|
|
networkDriverLock(driverState);
|
|
|
|
|
2008-10-10 13:57:13 +00:00
|
|
|
/* free inactive networks */
|
2008-10-10 14:50:26 +00:00
|
|
|
virNetworkObjListFree(&driverState->networks);
|
2008-10-10 13:57:13 +00:00
|
|
|
|
|
|
|
VIR_FREE(driverState->logDir);
|
|
|
|
VIR_FREE(driverState->networkConfigDir);
|
|
|
|
VIR_FREE(driverState->networkAutostartDir);
|
|
|
|
|
|
|
|
if (driverState->iptables)
|
|
|
|
iptablesContextFree(driverState->iptables);
|
|
|
|
|
2008-12-04 21:38:38 +00:00
|
|
|
networkDriverUnlock(driverState);
|
2009-01-15 19:56:05 +00:00
|
|
|
virMutexDestroy(&driverState->lock);
|
2008-12-04 21:38:38 +00:00
|
|
|
|
2008-10-10 13:57:13 +00:00
|
|
|
VIR_FREE(driverState);
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
network: Fix dnsmasq hostsfile creation logic and related tests
networkSaveDnsmasqHostsfile was added in 8fa9c2214247 (Apr 2010).
It has a force flag. If the dnsmasq hostsfile already exists force
needs to be true to overwrite it. networkBuildDnsmasqArgv sets force
to false, networkDefine sets it to true. This results in the
hostsfile being written only in networkDefine in the common case.
If no error occurred networkSaveDnsmasqHostsfile returns true and
networkBuildDnsmasqArgv adds the --dhcp-hostsfile to the dnsmasq
command line.
networkSaveDnsmasqHostsfile was changed in 89ae9849f744 (24 Jun 2011)
to return a new dnsmasqContext instead of reusing one. This change broke
the logic of the force flag as now networkSaveDnsmasqHostsfile returns
NULL on error, but the early return -- if force was not set and the
hostsfile exists -- returns 0. This turned the early return in an error
case and networkBuildDnsmasqArgv didn't add the --dhcp-hostsfile option
anymore if the hostsfile already exists. It did because networkDefine
created the hostsfile already.
Then 9d4e2845d498 fixed the return 0 case in networkSaveDnsmasqHostsfile
but didn't apply the force option correctly to the new addnhosts file.
Now force doesn't control an early return anymore, but influences the
handling of the hostsfile context creation and dnsmasqSave is always
called now. This commit also added test cases that reveal several
problems. First, the tests now calls functions that try to write the
dnsmasq config files to disk. If someone runs this tests as root this
might overwrite actively used dnsmasq config files, this is a no-go. Also
the tests depend on configure --localstatedir, this needs to be fixed as
well, because it makes the tests fail when localstatedir is different
from /var.
This patch does several things to fix this:
1) Move dnsmasqContext creation and saving out of networkBuildDnsmasqArgv
to the caller to separate the command line generation from the config
file writing. This makes the command line generation testable without the
risk of interfering with system files, because the tests just don't call
dnsmasqSave.
2) This refactoring of networkSaveDnsmasqHostsfile makes the force flag
useless as the saving happens somewhere else now. This fixes the wrong
usage of the force flag in combination with then newly added addnhosts
file by removing the force flag.
3) Adapt the wrong test cases to the correct behavior, by adding the
missing --dhcp-hostsfile option. Both affected tests contain DHCP host
elements but missed the necessary --dhcp-hostsfile option.
4) Rename networkSaveDnsmasqHostsfile to networkBuildDnsmasqHostsfile,
because it doesn't save the dnsmasqContext anymore.
5) Move all directory creations in dnsmasq context handling code from
the *New functions to dnsmasqSave to avoid directory creations in system
paths in the test cases.
6) Now that networkBuildDnsmasqArgv doesn't create the dnsmasqContext
anymore the test case can create one with the localstatedir that is
expected by the tests instead of the configure --localstatedir given one.
2011-06-28 11:07:59 +00:00
|
|
|
static int
|
|
|
|
networkBuildDnsmasqHostsfile(dnsmasqContext *dctx,
|
|
|
|
virNetworkIpDefPtr ipdef,
|
|
|
|
virNetworkDNSDefPtr dnsdef)
|
2010-04-26 14:07:25 +00:00
|
|
|
{
|
2011-06-24 10:04:40 +00:00
|
|
|
unsigned int i, j;
|
2010-04-26 14:07:25 +00:00
|
|
|
|
network: Fix dnsmasq hostsfile creation logic and related tests
networkSaveDnsmasqHostsfile was added in 8fa9c2214247 (Apr 2010).
It has a force flag. If the dnsmasq hostsfile already exists force
needs to be true to overwrite it. networkBuildDnsmasqArgv sets force
to false, networkDefine sets it to true. This results in the
hostsfile being written only in networkDefine in the common case.
If no error occurred networkSaveDnsmasqHostsfile returns true and
networkBuildDnsmasqArgv adds the --dhcp-hostsfile to the dnsmasq
command line.
networkSaveDnsmasqHostsfile was changed in 89ae9849f744 (24 Jun 2011)
to return a new dnsmasqContext instead of reusing one. This change broke
the logic of the force flag as now networkSaveDnsmasqHostsfile returns
NULL on error, but the early return -- if force was not set and the
hostsfile exists -- returns 0. This turned the early return in an error
case and networkBuildDnsmasqArgv didn't add the --dhcp-hostsfile option
anymore if the hostsfile already exists. It did because networkDefine
created the hostsfile already.
Then 9d4e2845d498 fixed the return 0 case in networkSaveDnsmasqHostsfile
but didn't apply the force option correctly to the new addnhosts file.
Now force doesn't control an early return anymore, but influences the
handling of the hostsfile context creation and dnsmasqSave is always
called now. This commit also added test cases that reveal several
problems. First, the tests now calls functions that try to write the
dnsmasq config files to disk. If someone runs this tests as root this
might overwrite actively used dnsmasq config files, this is a no-go. Also
the tests depend on configure --localstatedir, this needs to be fixed as
well, because it makes the tests fail when localstatedir is different
from /var.
This patch does several things to fix this:
1) Move dnsmasqContext creation and saving out of networkBuildDnsmasqArgv
to the caller to separate the command line generation from the config
file writing. This makes the command line generation testable without the
risk of interfering with system files, because the tests just don't call
dnsmasqSave.
2) This refactoring of networkSaveDnsmasqHostsfile makes the force flag
useless as the saving happens somewhere else now. This fixes the wrong
usage of the force flag in combination with then newly added addnhosts
file by removing the force flag.
3) Adapt the wrong test cases to the correct behavior, by adding the
missing --dhcp-hostsfile option. Both affected tests contain DHCP host
elements but missed the necessary --dhcp-hostsfile option.
4) Rename networkSaveDnsmasqHostsfile to networkBuildDnsmasqHostsfile,
because it doesn't save the dnsmasqContext anymore.
5) Move all directory creations in dnsmasq context handling code from
the *New functions to dnsmasqSave to avoid directory creations in system
paths in the test cases.
6) Now that networkBuildDnsmasqArgv doesn't create the dnsmasqContext
anymore the test case can create one with the localstatedir that is
expected by the tests instead of the configure --localstatedir given one.
2011-06-28 11:07:59 +00:00
|
|
|
for (i = 0; i < ipdef->nhosts; i++) {
|
|
|
|
virNetworkDHCPHostDefPtr host = &(ipdef->hosts[i]);
|
Santize naming of socket address APIs
The socket address APIs in src/util/network.h either take the
form virSocketAddrXXX, virSocketXXX or virSocketXXXAddr.
Sanitize this so everything is virSocketAddrXXXX, and ensure
that the virSocketAddr parameter is always the first one.
* src/util/network.c, src/util/network.h: Santize socket
address API naming
* src/conf/domain_conf.c, src/conf/network_conf.c,
src/conf/nwfilter_conf.c, src/network/bridge_driver.c,
src/nwfilter/nwfilter_ebiptables_driver.c,
src/nwfilter/nwfilter_learnipaddr.c,
src/qemu/qemu_command.c, src/rpc/virnetsocket.c,
src/util/dnsmasq.c, src/util/iptables.c,
src/util/virnetdev.c, src/vbox/vbox_tmpl.c: Update for
API renaming
2011-11-02 14:06:59 +00:00
|
|
|
if ((host->mac) && VIR_SOCKET_ADDR_VALID(&host->ip))
|
2011-06-28 12:07:46 +00:00
|
|
|
if (dnsmasqAddDhcpHost(dctx, host->mac, &host->ip, host->name) < 0)
|
|
|
|
return -1;
|
2011-06-24 10:04:40 +00:00
|
|
|
}
|
2010-04-26 14:07:25 +00:00
|
|
|
|
2011-06-24 10:04:40 +00:00
|
|
|
if (dnsdef) {
|
|
|
|
for (i = 0; i < dnsdef->nhosts; i++) {
|
|
|
|
virNetworkDNSHostsDefPtr host = &(dnsdef->hosts[i]);
|
Santize naming of socket address APIs
The socket address APIs in src/util/network.h either take the
form virSocketAddrXXX, virSocketXXX or virSocketXXXAddr.
Sanitize this so everything is virSocketAddrXXXX, and ensure
that the virSocketAddr parameter is always the first one.
* src/util/network.c, src/util/network.h: Santize socket
address API naming
* src/conf/domain_conf.c, src/conf/network_conf.c,
src/conf/nwfilter_conf.c, src/network/bridge_driver.c,
src/nwfilter/nwfilter_ebiptables_driver.c,
src/nwfilter/nwfilter_learnipaddr.c,
src/qemu/qemu_command.c, src/rpc/virnetsocket.c,
src/util/dnsmasq.c, src/util/iptables.c,
src/util/virnetdev.c, src/vbox/vbox_tmpl.c: Update for
API renaming
2011-11-02 14:06:59 +00:00
|
|
|
if (VIR_SOCKET_ADDR_VALID(&host->ip)) {
|
2011-06-24 10:04:40 +00:00
|
|
|
for (j = 0; j < host->nnames; j++)
|
2011-06-28 12:07:46 +00:00
|
|
|
if (dnsmasqAddHost(dctx, &host->ip, host->names[j]) < 0)
|
|
|
|
return -1;
|
2011-06-24 10:04:40 +00:00
|
|
|
}
|
|
|
|
}
|
2010-04-26 14:07:25 +00:00
|
|
|
}
|
|
|
|
|
network: Fix dnsmasq hostsfile creation logic and related tests
networkSaveDnsmasqHostsfile was added in 8fa9c2214247 (Apr 2010).
It has a force flag. If the dnsmasq hostsfile already exists force
needs to be true to overwrite it. networkBuildDnsmasqArgv sets force
to false, networkDefine sets it to true. This results in the
hostsfile being written only in networkDefine in the common case.
If no error occurred networkSaveDnsmasqHostsfile returns true and
networkBuildDnsmasqArgv adds the --dhcp-hostsfile to the dnsmasq
command line.
networkSaveDnsmasqHostsfile was changed in 89ae9849f744 (24 Jun 2011)
to return a new dnsmasqContext instead of reusing one. This change broke
the logic of the force flag as now networkSaveDnsmasqHostsfile returns
NULL on error, but the early return -- if force was not set and the
hostsfile exists -- returns 0. This turned the early return in an error
case and networkBuildDnsmasqArgv didn't add the --dhcp-hostsfile option
anymore if the hostsfile already exists. It did because networkDefine
created the hostsfile already.
Then 9d4e2845d498 fixed the return 0 case in networkSaveDnsmasqHostsfile
but didn't apply the force option correctly to the new addnhosts file.
Now force doesn't control an early return anymore, but influences the
handling of the hostsfile context creation and dnsmasqSave is always
called now. This commit also added test cases that reveal several
problems. First, the tests now calls functions that try to write the
dnsmasq config files to disk. If someone runs this tests as root this
might overwrite actively used dnsmasq config files, this is a no-go. Also
the tests depend on configure --localstatedir, this needs to be fixed as
well, because it makes the tests fail when localstatedir is different
from /var.
This patch does several things to fix this:
1) Move dnsmasqContext creation and saving out of networkBuildDnsmasqArgv
to the caller to separate the command line generation from the config
file writing. This makes the command line generation testable without the
risk of interfering with system files, because the tests just don't call
dnsmasqSave.
2) This refactoring of networkSaveDnsmasqHostsfile makes the force flag
useless as the saving happens somewhere else now. This fixes the wrong
usage of the force flag in combination with then newly added addnhosts
file by removing the force flag.
3) Adapt the wrong test cases to the correct behavior, by adding the
missing --dhcp-hostsfile option. Both affected tests contain DHCP host
elements but missed the necessary --dhcp-hostsfile option.
4) Rename networkSaveDnsmasqHostsfile to networkBuildDnsmasqHostsfile,
because it doesn't save the dnsmasqContext anymore.
5) Move all directory creations in dnsmasq context handling code from
the *New functions to dnsmasqSave to avoid directory creations in system
paths in the test cases.
6) Now that networkBuildDnsmasqArgv doesn't create the dnsmasqContext
anymore the test case can create one with the localstatedir that is
expected by the tests instead of the configure --localstatedir given one.
2011-06-28 11:07:59 +00:00
|
|
|
return 0;
|
2010-04-26 14:07:25 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
2008-10-10 13:57:13 +00:00
|
|
|
static int
|
2010-02-04 18:19:08 +00:00
|
|
|
networkBuildDnsmasqArgv(virNetworkObjPtr network,
|
2010-11-17 18:36:19 +00:00
|
|
|
virNetworkIpDefPtr ipdef,
|
2009-01-20 22:36:10 +00:00
|
|
|
const char *pidfile,
|
network: Fix dnsmasq hostsfile creation logic and related tests
networkSaveDnsmasqHostsfile was added in 8fa9c2214247 (Apr 2010).
It has a force flag. If the dnsmasq hostsfile already exists force
needs to be true to overwrite it. networkBuildDnsmasqArgv sets force
to false, networkDefine sets it to true. This results in the
hostsfile being written only in networkDefine in the common case.
If no error occurred networkSaveDnsmasqHostsfile returns true and
networkBuildDnsmasqArgv adds the --dhcp-hostsfile to the dnsmasq
command line.
networkSaveDnsmasqHostsfile was changed in 89ae9849f744 (24 Jun 2011)
to return a new dnsmasqContext instead of reusing one. This change broke
the logic of the force flag as now networkSaveDnsmasqHostsfile returns
NULL on error, but the early return -- if force was not set and the
hostsfile exists -- returns 0. This turned the early return in an error
case and networkBuildDnsmasqArgv didn't add the --dhcp-hostsfile option
anymore if the hostsfile already exists. It did because networkDefine
created the hostsfile already.
Then 9d4e2845d498 fixed the return 0 case in networkSaveDnsmasqHostsfile
but didn't apply the force option correctly to the new addnhosts file.
Now force doesn't control an early return anymore, but influences the
handling of the hostsfile context creation and dnsmasqSave is always
called now. This commit also added test cases that reveal several
problems. First, the tests now calls functions that try to write the
dnsmasq config files to disk. If someone runs this tests as root this
might overwrite actively used dnsmasq config files, this is a no-go. Also
the tests depend on configure --localstatedir, this needs to be fixed as
well, because it makes the tests fail when localstatedir is different
from /var.
This patch does several things to fix this:
1) Move dnsmasqContext creation and saving out of networkBuildDnsmasqArgv
to the caller to separate the command line generation from the config
file writing. This makes the command line generation testable without the
risk of interfering with system files, because the tests just don't call
dnsmasqSave.
2) This refactoring of networkSaveDnsmasqHostsfile makes the force flag
useless as the saving happens somewhere else now. This fixes the wrong
usage of the force flag in combination with then newly added addnhosts
file by removing the force flag.
3) Adapt the wrong test cases to the correct behavior, by adding the
missing --dhcp-hostsfile option. Both affected tests contain DHCP host
elements but missed the necessary --dhcp-hostsfile option.
4) Rename networkSaveDnsmasqHostsfile to networkBuildDnsmasqHostsfile,
because it doesn't save the dnsmasqContext anymore.
5) Move all directory creations in dnsmasq context handling code from
the *New functions to dnsmasqSave to avoid directory creations in system
paths in the test cases.
6) Now that networkBuildDnsmasqArgv doesn't create the dnsmasqContext
anymore the test case can create one with the localstatedir that is
expected by the tests instead of the configure --localstatedir given one.
2011-06-28 11:07:59 +00:00
|
|
|
virCommandPtr cmd,
|
|
|
|
dnsmasqContext *dctx)
|
|
|
|
{
|
2010-12-10 18:54:48 +00:00
|
|
|
int r, ret = -1;
|
2009-11-06 16:53:45 +00:00
|
|
|
int nbleases = 0;
|
2011-01-31 20:31:57 +00:00
|
|
|
int ii;
|
2012-02-01 09:22:21 +00:00
|
|
|
char *record = NULL;
|
|
|
|
char *recordPort = NULL;
|
|
|
|
char *recordWeight = NULL;
|
|
|
|
char *recordPriority = NULL;
|
2011-01-31 20:31:57 +00:00
|
|
|
virNetworkIpDefPtr tmpipdef;
|
2009-01-20 22:36:10 +00:00
|
|
|
|
|
|
|
/*
|
2010-12-10 18:54:48 +00:00
|
|
|
* NB, be careful about syntax for dnsmasq options in long format.
|
2009-01-20 22:36:10 +00:00
|
|
|
*
|
|
|
|
* If the flag has a mandatory argument, it can be given using
|
|
|
|
* either syntax:
|
|
|
|
*
|
|
|
|
* --foo bar
|
|
|
|
* --foo=bar
|
|
|
|
*
|
|
|
|
* If the flag has a optional argument, it *must* be given using
|
|
|
|
* the syntax:
|
|
|
|
*
|
|
|
|
* --foo=bar
|
|
|
|
*
|
|
|
|
* It is hard to determine whether a flag is optional or not,
|
2010-12-10 18:54:48 +00:00
|
|
|
* without reading the dnsmasq source :-( The manpage is not
|
|
|
|
* very explicit on this.
|
2009-01-20 22:36:10 +00:00
|
|
|
*/
|
2008-10-10 13:57:13 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Needed to ensure dnsmasq uses same algorithm for processing
|
|
|
|
* multiple namedriver entries in /etc/resolv.conf as GLibC.
|
|
|
|
*/
|
2010-12-10 18:54:48 +00:00
|
|
|
virCommandAddArgList(cmd, "--strict-order", "--bind-interfaces", NULL);
|
2008-10-10 13:57:13 +00:00
|
|
|
|
2010-12-10 18:54:48 +00:00
|
|
|
if (network->def->domain)
|
|
|
|
virCommandAddArgList(cmd, "--domain", network->def->domain, NULL);
|
2008-10-10 13:57:13 +00:00
|
|
|
|
2011-06-24 10:04:38 +00:00
|
|
|
if (pidfile)
|
|
|
|
virCommandAddArgPair(cmd, "--pid-file", pidfile);
|
2008-10-10 13:57:13 +00:00
|
|
|
|
2010-12-10 18:54:48 +00:00
|
|
|
/* *no* conf file */
|
2011-02-18 14:32:02 +00:00
|
|
|
virCommandAddArg(cmd, "--conf-file=");
|
2008-10-10 13:57:13 +00:00
|
|
|
|
2010-12-10 18:54:48 +00:00
|
|
|
virCommandAddArgList(cmd,
|
|
|
|
"--except-interface", "lo",
|
|
|
|
NULL);
|
2008-10-10 13:57:13 +00:00
|
|
|
|
2011-03-13 08:42:58 +00:00
|
|
|
/* If this is an isolated network, set the default route option
|
|
|
|
* (3) to be empty to avoid setting a default route that's
|
2011-07-29 19:42:04 +00:00
|
|
|
* guaranteed to not work, and set --no-resolv so that no dns
|
|
|
|
* requests are forwarded on to the dns server listed in the
|
|
|
|
* host's /etc/resolv.conf (since this could be used as a channel
|
|
|
|
* to build a connection to the outside).
|
2011-03-13 08:42:58 +00:00
|
|
|
*/
|
2011-07-29 19:42:04 +00:00
|
|
|
if (network->def->forwardType == VIR_NETWORK_FORWARD_NONE) {
|
|
|
|
virCommandAddArgList(cmd, "--dhcp-option=3",
|
|
|
|
"--no-resolv", NULL);
|
|
|
|
}
|
2011-03-13 08:42:58 +00:00
|
|
|
|
2011-06-24 10:04:36 +00:00
|
|
|
if (network->def->dns != NULL) {
|
|
|
|
virNetworkDNSDefPtr dns = network->def->dns;
|
|
|
|
int i;
|
|
|
|
|
|
|
|
for (i = 0; i < dns->ntxtrecords; i++) {
|
2012-02-01 23:42:33 +00:00
|
|
|
virCommandAddArgFormat(cmd, "--txt-record=%s,%s",
|
2012-02-01 09:22:21 +00:00
|
|
|
dns->txtrecords[i].name,
|
|
|
|
dns->txtrecords[i].value);
|
2011-06-24 10:04:36 +00:00
|
|
|
}
|
2012-01-02 14:23:54 +00:00
|
|
|
|
|
|
|
for (i = 0; i < dns->nsrvrecords; i++) {
|
|
|
|
if (dns->srvrecords[i].service && dns->srvrecords[i].protocol) {
|
|
|
|
if (dns->srvrecords[i].port) {
|
|
|
|
if (virAsprintf(&recordPort, "%d", dns->srvrecords[i].port) < 0) {
|
|
|
|
virReportOOMError();
|
|
|
|
goto cleanup;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
if (dns->srvrecords[i].priority) {
|
|
|
|
if (virAsprintf(&recordPriority, "%d", dns->srvrecords[i].priority) < 0) {
|
|
|
|
virReportOOMError();
|
|
|
|
goto cleanup;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
if (dns->srvrecords[i].weight) {
|
|
|
|
if (virAsprintf(&recordWeight, "%d", dns->srvrecords[i].weight) < 0) {
|
|
|
|
virReportOOMError();
|
|
|
|
goto cleanup;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
if (virAsprintf(&record, "%s.%s.%s,%s,%s,%s,%s",
|
|
|
|
dns->srvrecords[i].service,
|
|
|
|
dns->srvrecords[i].protocol,
|
|
|
|
dns->srvrecords[i].domain ? dns->srvrecords[i].domain : "",
|
|
|
|
dns->srvrecords[i].target ? dns->srvrecords[i].target : "",
|
|
|
|
recordPort ? recordPort : "",
|
|
|
|
recordPriority ? recordPriority : "",
|
|
|
|
recordWeight ? recordWeight : "") < 0) {
|
|
|
|
virReportOOMError();
|
|
|
|
goto cleanup;
|
|
|
|
}
|
|
|
|
|
|
|
|
virCommandAddArgPair(cmd, "--srv-host", record);
|
|
|
|
VIR_FREE(record);
|
2012-02-01 09:22:21 +00:00
|
|
|
VIR_FREE(recordPort);
|
|
|
|
VIR_FREE(recordWeight);
|
|
|
|
VIR_FREE(recordPriority);
|
2012-01-02 14:23:54 +00:00
|
|
|
}
|
|
|
|
}
|
2011-06-24 10:04:36 +00:00
|
|
|
}
|
|
|
|
|
2011-01-31 20:31:57 +00:00
|
|
|
/*
|
|
|
|
* --interface does not actually work with dnsmasq < 2.47,
|
|
|
|
* due to DAD for ipv6 addresses on the interface.
|
|
|
|
*
|
|
|
|
* virCommandAddArgList(cmd, "--interface", ipdef->bridge, NULL);
|
|
|
|
*
|
|
|
|
* So listen on all defined IPv[46] addresses
|
|
|
|
*/
|
|
|
|
for (ii = 0;
|
|
|
|
(tmpipdef = virNetworkDefGetIpByIndex(network->def, AF_UNSPEC, ii));
|
|
|
|
ii++) {
|
Santize naming of socket address APIs
The socket address APIs in src/util/network.h either take the
form virSocketAddrXXX, virSocketXXX or virSocketXXXAddr.
Sanitize this so everything is virSocketAddrXXXX, and ensure
that the virSocketAddr parameter is always the first one.
* src/util/network.c, src/util/network.h: Santize socket
address API naming
* src/conf/domain_conf.c, src/conf/network_conf.c,
src/conf/nwfilter_conf.c, src/network/bridge_driver.c,
src/nwfilter/nwfilter_ebiptables_driver.c,
src/nwfilter/nwfilter_learnipaddr.c,
src/qemu/qemu_command.c, src/rpc/virnetsocket.c,
src/util/dnsmasq.c, src/util/iptables.c,
src/util/virnetdev.c, src/vbox/vbox_tmpl.c: Update for
API renaming
2011-11-02 14:06:59 +00:00
|
|
|
char *ipaddr = virSocketAddrFormat(&tmpipdef->address);
|
2011-01-31 20:31:57 +00:00
|
|
|
if (!ipaddr)
|
|
|
|
goto cleanup;
|
|
|
|
virCommandAddArgList(cmd, "--listen-address", ipaddr, NULL);
|
|
|
|
VIR_FREE(ipaddr);
|
|
|
|
}
|
|
|
|
|
network driver: Start dnsmasq even if no dhcp ranges/hosts are specified.
This fixes a regression introduced in commit ad48df, and reported on
the libvirt-users list:
https://www.redhat.com/archives/libvirt-users/2011-March/msg00018.html
The problem in that commit was that we began searching a list of ip
address definitions (rather than just having one) to look for a dhcp
range or static host; when we didn't find any, our pointer (ipdef) was
left at NULL, and when ipdef was NULL, we returned without starting up
dnsmasq.
Previously dnsmasq was started even without any dhcp ranges or static
entries, because it's still useful for DNS services.
Another problem I noticed while investigating was that, if there are
IPv6 addresses, but no IPv4 addresses of any kind, we would jump out
at an ever higher level in the call chain.
This patch does the following:
1) networkBuildDnsmasqArgv() = all uses of ipdef are protected from
NULL dereference. (this patch doesn't change indentation, to make
review easier. The next patch will change just the
indentation). ipdef is intended to point to the first IPv4 address
with DHCP info (or the first IPv4 address if none of them have any
dhcp info).
2) networkStartDhcpDaemon() = if the loop looking for an ipdef with
DHCP info comes up empty, we then grab the first IPv4 def from the
list. Also, instead of returning if there are no IPv4 defs, we just
return if there are no IP defs at all (either v4 or v6). This way a
network that is IPv6-only will still get dnsmasq listening for DNS
queries.
3) in networkStartNetworkDaemon() - we will startup dhcp not just if there
are any IPv4 addresses, but also if there are any IPv6 addresses.
2011-03-11 16:47:58 +00:00
|
|
|
if (ipdef) {
|
2011-03-11 17:07:09 +00:00
|
|
|
for (r = 0 ; r < ipdef->nranges ; r++) {
|
Santize naming of socket address APIs
The socket address APIs in src/util/network.h either take the
form virSocketAddrXXX, virSocketXXX or virSocketXXXAddr.
Sanitize this so everything is virSocketAddrXXXX, and ensure
that the virSocketAddr parameter is always the first one.
* src/util/network.c, src/util/network.h: Santize socket
address API naming
* src/conf/domain_conf.c, src/conf/network_conf.c,
src/conf/nwfilter_conf.c, src/network/bridge_driver.c,
src/nwfilter/nwfilter_ebiptables_driver.c,
src/nwfilter/nwfilter_learnipaddr.c,
src/qemu/qemu_command.c, src/rpc/virnetsocket.c,
src/util/dnsmasq.c, src/util/iptables.c,
src/util/virnetdev.c, src/vbox/vbox_tmpl.c: Update for
API renaming
2011-11-02 14:06:59 +00:00
|
|
|
char *saddr = virSocketAddrFormat(&ipdef->ranges[r].start);
|
2011-03-11 17:07:09 +00:00
|
|
|
if (!saddr)
|
|
|
|
goto cleanup;
|
Santize naming of socket address APIs
The socket address APIs in src/util/network.h either take the
form virSocketAddrXXX, virSocketXXX or virSocketXXXAddr.
Sanitize this so everything is virSocketAddrXXXX, and ensure
that the virSocketAddr parameter is always the first one.
* src/util/network.c, src/util/network.h: Santize socket
address API naming
* src/conf/domain_conf.c, src/conf/network_conf.c,
src/conf/nwfilter_conf.c, src/network/bridge_driver.c,
src/nwfilter/nwfilter_ebiptables_driver.c,
src/nwfilter/nwfilter_learnipaddr.c,
src/qemu/qemu_command.c, src/rpc/virnetsocket.c,
src/util/dnsmasq.c, src/util/iptables.c,
src/util/virnetdev.c, src/vbox/vbox_tmpl.c: Update for
API renaming
2011-11-02 14:06:59 +00:00
|
|
|
char *eaddr = virSocketAddrFormat(&ipdef->ranges[r].end);
|
2011-03-11 17:07:09 +00:00
|
|
|
if (!eaddr) {
|
|
|
|
VIR_FREE(saddr);
|
|
|
|
goto cleanup;
|
|
|
|
}
|
|
|
|
virCommandAddArg(cmd, "--dhcp-range");
|
|
|
|
virCommandAddArgFormat(cmd, "%s,%s", saddr, eaddr);
|
Convert virNetwork to use virSocketAddr everywhere
Instead of storing the IP address string in virNetwork related
structs, store the parsed virSocketAddr. This will make it
easier to add IPv6 support in the future, by letting driver
code directly check what address family is present
* src/conf/network_conf.c, src/conf/network_conf.h,
src/network/bridge_driver.c: Convert to use virSocketAddr
in virNetwork, instead of char *.
* src/util/bridge.c, src/util/bridge.h,
src/util/dnsmasq.c, src/util/dnsmasq.h,
src/util/iptables.c, src/util/iptables.h: Convert to
take a virSocketAddr instead of char * for any IP
address parameters
* src/util/network.h: Add macros to determine if an address
is set, and what address family is set.
2010-10-21 12:14:33 +00:00
|
|
|
VIR_FREE(saddr);
|
2011-03-11 17:07:09 +00:00
|
|
|
VIR_FREE(eaddr);
|
Santize naming of socket address APIs
The socket address APIs in src/util/network.h either take the
form virSocketAddrXXX, virSocketXXX or virSocketXXXAddr.
Sanitize this so everything is virSocketAddrXXXX, and ensure
that the virSocketAddr parameter is always the first one.
* src/util/network.c, src/util/network.h: Santize socket
address API naming
* src/conf/domain_conf.c, src/conf/network_conf.c,
src/conf/nwfilter_conf.c, src/network/bridge_driver.c,
src/nwfilter/nwfilter_ebiptables_driver.c,
src/nwfilter/nwfilter_learnipaddr.c,
src/qemu/qemu_command.c, src/rpc/virnetsocket.c,
src/util/dnsmasq.c, src/util/iptables.c,
src/util/virnetdev.c, src/vbox/vbox_tmpl.c: Update for
API renaming
2011-11-02 14:06:59 +00:00
|
|
|
nbleases += virSocketAddrGetRange(&ipdef->ranges[r].start,
|
|
|
|
&ipdef->ranges[r].end);
|
Convert virNetwork to use virSocketAddr everywhere
Instead of storing the IP address string in virNetwork related
structs, store the parsed virSocketAddr. This will make it
easier to add IPv6 support in the future, by letting driver
code directly check what address family is present
* src/conf/network_conf.c, src/conf/network_conf.h,
src/network/bridge_driver.c: Convert to use virSocketAddr
in virNetwork, instead of char *.
* src/util/bridge.c, src/util/bridge.h,
src/util/dnsmasq.c, src/util/dnsmasq.h,
src/util/iptables.c, src/util/iptables.h: Convert to
take a virSocketAddr instead of char * for any IP
address parameters
* src/util/network.h: Add macros to determine if an address
is set, and what address family is set.
2010-10-21 12:14:33 +00:00
|
|
|
}
|
2009-11-06 16:53:45 +00:00
|
|
|
|
2011-03-11 17:07:09 +00:00
|
|
|
/*
|
|
|
|
* For static-only DHCP, i.e. with no range but at least one host element,
|
|
|
|
* we have to add a special --dhcp-range option to enable the service in
|
|
|
|
* dnsmasq.
|
|
|
|
*/
|
|
|
|
if (!ipdef->nranges && ipdef->nhosts) {
|
Santize naming of socket address APIs
The socket address APIs in src/util/network.h either take the
form virSocketAddrXXX, virSocketXXX or virSocketXXXAddr.
Sanitize this so everything is virSocketAddrXXXX, and ensure
that the virSocketAddr parameter is always the first one.
* src/util/network.c, src/util/network.h: Santize socket
address API naming
* src/conf/domain_conf.c, src/conf/network_conf.c,
src/conf/nwfilter_conf.c, src/network/bridge_driver.c,
src/nwfilter/nwfilter_ebiptables_driver.c,
src/nwfilter/nwfilter_learnipaddr.c,
src/qemu/qemu_command.c, src/rpc/virnetsocket.c,
src/util/dnsmasq.c, src/util/iptables.c,
src/util/virnetdev.c, src/vbox/vbox_tmpl.c: Update for
API renaming
2011-11-02 14:06:59 +00:00
|
|
|
char *bridgeaddr = virSocketAddrFormat(&ipdef->address);
|
2011-03-11 17:07:09 +00:00
|
|
|
if (!bridgeaddr)
|
|
|
|
goto cleanup;
|
|
|
|
virCommandAddArg(cmd, "--dhcp-range");
|
|
|
|
virCommandAddArgFormat(cmd, "%s,static", bridgeaddr);
|
|
|
|
VIR_FREE(bridgeaddr);
|
|
|
|
}
|
2010-09-09 14:00:08 +00:00
|
|
|
|
2011-03-11 17:07:09 +00:00
|
|
|
if (ipdef->nranges > 0) {
|
2011-03-11 18:20:48 +00:00
|
|
|
char *leasefile = networkDnsmasqLeaseFileName(network->def->name);
|
|
|
|
if (!leasefile)
|
|
|
|
goto cleanup;
|
|
|
|
virCommandAddArgFormat(cmd, "--dhcp-leasefile=%s", leasefile);
|
|
|
|
VIR_FREE(leasefile);
|
2011-03-11 17:07:09 +00:00
|
|
|
virCommandAddArgFormat(cmd, "--dhcp-lease-max=%d", nbleases);
|
|
|
|
}
|
2008-10-10 13:57:13 +00:00
|
|
|
|
2011-03-11 17:07:09 +00:00
|
|
|
if (ipdef->nranges || ipdef->nhosts)
|
|
|
|
virCommandAddArg(cmd, "--dhcp-no-override");
|
2010-09-09 14:00:08 +00:00
|
|
|
|
2011-06-25 05:14:38 +00:00
|
|
|
/* add domain to any non-qualified hostnames in /etc/hosts or addn-hosts */
|
|
|
|
if (network->def->domain)
|
|
|
|
virCommandAddArg(cmd, "--expand-hosts");
|
|
|
|
|
2011-06-28 12:07:46 +00:00
|
|
|
if (networkBuildDnsmasqHostsfile(dctx, ipdef, network->def->dns) < 0)
|
|
|
|
goto cleanup;
|
|
|
|
|
|
|
|
if (dctx->hostsfile->nhosts)
|
|
|
|
virCommandAddArgPair(cmd, "--dhcp-hostsfile",
|
|
|
|
dctx->hostsfile->path);
|
|
|
|
if (dctx->addnhostsfile->nhosts)
|
|
|
|
virCommandAddArgPair(cmd, "--addn-hosts",
|
|
|
|
dctx->addnhostsfile->path);
|
2008-10-10 13:57:13 +00:00
|
|
|
|
2011-03-11 17:07:09 +00:00
|
|
|
if (ipdef->tftproot) {
|
|
|
|
virCommandAddArgList(cmd, "--enable-tftp",
|
|
|
|
"--tftp-root", ipdef->tftproot,
|
|
|
|
NULL);
|
|
|
|
}
|
|
|
|
if (ipdef->bootfile) {
|
|
|
|
virCommandAddArg(cmd, "--dhcp-boot");
|
Santize naming of socket address APIs
The socket address APIs in src/util/network.h either take the
form virSocketAddrXXX, virSocketXXX or virSocketXXXAddr.
Sanitize this so everything is virSocketAddrXXXX, and ensure
that the virSocketAddr parameter is always the first one.
* src/util/network.c, src/util/network.h: Santize socket
address API naming
* src/conf/domain_conf.c, src/conf/network_conf.c,
src/conf/nwfilter_conf.c, src/network/bridge_driver.c,
src/nwfilter/nwfilter_ebiptables_driver.c,
src/nwfilter/nwfilter_learnipaddr.c,
src/qemu/qemu_command.c, src/rpc/virnetsocket.c,
src/util/dnsmasq.c, src/util/iptables.c,
src/util/virnetdev.c, src/vbox/vbox_tmpl.c: Update for
API renaming
2011-11-02 14:06:59 +00:00
|
|
|
if (VIR_SOCKET_ADDR_VALID(&ipdef->bootserver)) {
|
|
|
|
char *bootserver = virSocketAddrFormat(&ipdef->bootserver);
|
2010-12-10 18:54:48 +00:00
|
|
|
|
2011-03-11 17:07:09 +00:00
|
|
|
if (!bootserver)
|
|
|
|
goto cleanup;
|
|
|
|
virCommandAddArgFormat(cmd, "%s%s%s",
|
|
|
|
ipdef->bootfile, ",,", bootserver);
|
|
|
|
VIR_FREE(bootserver);
|
|
|
|
} else {
|
|
|
|
virCommandAddArg(cmd, ipdef->bootfile);
|
|
|
|
}
|
Convert virNetwork to use virSocketAddr everywhere
Instead of storing the IP address string in virNetwork related
structs, store the parsed virSocketAddr. This will make it
easier to add IPv6 support in the future, by letting driver
code directly check what address family is present
* src/conf/network_conf.c, src/conf/network_conf.h,
src/network/bridge_driver.c: Convert to use virSocketAddr
in virNetwork, instead of char *.
* src/util/bridge.c, src/util/bridge.h,
src/util/dnsmasq.c, src/util/dnsmasq.h,
src/util/iptables.c, src/util/iptables.h: Convert to
take a virSocketAddr instead of char * for any IP
address parameters
* src/util/network.h: Add macros to determine if an address
is set, and what address family is set.
2010-10-21 12:14:33 +00:00
|
|
|
}
|
2009-09-21 20:50:25 +00:00
|
|
|
}
|
|
|
|
|
2010-12-10 18:54:48 +00:00
|
|
|
ret = 0;
|
|
|
|
cleanup:
|
2012-02-01 09:22:21 +00:00
|
|
|
VIR_FREE(record);
|
|
|
|
VIR_FREE(recordPort);
|
|
|
|
VIR_FREE(recordWeight);
|
|
|
|
VIR_FREE(recordPriority);
|
2010-12-10 18:54:48 +00:00
|
|
|
return ret;
|
2008-10-10 13:57:13 +00:00
|
|
|
}
|
|
|
|
|
2011-06-24 10:04:38 +00:00
|
|
|
int
|
|
|
|
networkBuildDhcpDaemonCommandLine(virNetworkObjPtr network, virCommandPtr *cmdout,
|
network: Fix dnsmasq hostsfile creation logic and related tests
networkSaveDnsmasqHostsfile was added in 8fa9c2214247 (Apr 2010).
It has a force flag. If the dnsmasq hostsfile already exists force
needs to be true to overwrite it. networkBuildDnsmasqArgv sets force
to false, networkDefine sets it to true. This results in the
hostsfile being written only in networkDefine in the common case.
If no error occurred networkSaveDnsmasqHostsfile returns true and
networkBuildDnsmasqArgv adds the --dhcp-hostsfile to the dnsmasq
command line.
networkSaveDnsmasqHostsfile was changed in 89ae9849f744 (24 Jun 2011)
to return a new dnsmasqContext instead of reusing one. This change broke
the logic of the force flag as now networkSaveDnsmasqHostsfile returns
NULL on error, but the early return -- if force was not set and the
hostsfile exists -- returns 0. This turned the early return in an error
case and networkBuildDnsmasqArgv didn't add the --dhcp-hostsfile option
anymore if the hostsfile already exists. It did because networkDefine
created the hostsfile already.
Then 9d4e2845d498 fixed the return 0 case in networkSaveDnsmasqHostsfile
but didn't apply the force option correctly to the new addnhosts file.
Now force doesn't control an early return anymore, but influences the
handling of the hostsfile context creation and dnsmasqSave is always
called now. This commit also added test cases that reveal several
problems. First, the tests now calls functions that try to write the
dnsmasq config files to disk. If someone runs this tests as root this
might overwrite actively used dnsmasq config files, this is a no-go. Also
the tests depend on configure --localstatedir, this needs to be fixed as
well, because it makes the tests fail when localstatedir is different
from /var.
This patch does several things to fix this:
1) Move dnsmasqContext creation and saving out of networkBuildDnsmasqArgv
to the caller to separate the command line generation from the config
file writing. This makes the command line generation testable without the
risk of interfering with system files, because the tests just don't call
dnsmasqSave.
2) This refactoring of networkSaveDnsmasqHostsfile makes the force flag
useless as the saving happens somewhere else now. This fixes the wrong
usage of the force flag in combination with then newly added addnhosts
file by removing the force flag.
3) Adapt the wrong test cases to the correct behavior, by adding the
missing --dhcp-hostsfile option. Both affected tests contain DHCP host
elements but missed the necessary --dhcp-hostsfile option.
4) Rename networkSaveDnsmasqHostsfile to networkBuildDnsmasqHostsfile,
because it doesn't save the dnsmasqContext anymore.
5) Move all directory creations in dnsmasq context handling code from
the *New functions to dnsmasqSave to avoid directory creations in system
paths in the test cases.
6) Now that networkBuildDnsmasqArgv doesn't create the dnsmasqContext
anymore the test case can create one with the localstatedir that is
expected by the tests instead of the configure --localstatedir given one.
2011-06-28 11:07:59 +00:00
|
|
|
char *pidfile, dnsmasqContext *dctx)
|
2008-10-10 13:57:13 +00:00
|
|
|
{
|
2010-12-10 18:54:48 +00:00
|
|
|
virCommandPtr cmd = NULL;
|
2011-06-24 10:04:38 +00:00
|
|
|
int ret = -1, ii;
|
2010-12-10 21:04:37 +00:00
|
|
|
virNetworkIpDefPtr ipdef;
|
2009-01-20 22:36:10 +00:00
|
|
|
|
|
|
|
network->dnsmasqPid = -1;
|
2008-10-10 13:57:13 +00:00
|
|
|
|
2010-12-10 21:04:37 +00:00
|
|
|
/* Look for first IPv4 address that has dhcp defined. */
|
|
|
|
/* We support dhcp config on 1 IPv4 interface only. */
|
|
|
|
for (ii = 0;
|
|
|
|
(ipdef = virNetworkDefGetIpByIndex(network->def, AF_INET, ii));
|
|
|
|
ii++) {
|
|
|
|
if (ipdef->nranges || ipdef->nhosts)
|
|
|
|
break;
|
2008-10-10 13:57:13 +00:00
|
|
|
}
|
network driver: Start dnsmasq even if no dhcp ranges/hosts are specified.
This fixes a regression introduced in commit ad48df, and reported on
the libvirt-users list:
https://www.redhat.com/archives/libvirt-users/2011-March/msg00018.html
The problem in that commit was that we began searching a list of ip
address definitions (rather than just having one) to look for a dhcp
range or static host; when we didn't find any, our pointer (ipdef) was
left at NULL, and when ipdef was NULL, we returned without starting up
dnsmasq.
Previously dnsmasq was started even without any dhcp ranges or static
entries, because it's still useful for DNS services.
Another problem I noticed while investigating was that, if there are
IPv6 addresses, but no IPv4 addresses of any kind, we would jump out
at an ever higher level in the call chain.
This patch does the following:
1) networkBuildDnsmasqArgv() = all uses of ipdef are protected from
NULL dereference. (this patch doesn't change indentation, to make
review easier. The next patch will change just the
indentation). ipdef is intended to point to the first IPv4 address
with DHCP info (or the first IPv4 address if none of them have any
dhcp info).
2) networkStartDhcpDaemon() = if the loop looking for an ipdef with
DHCP info comes up empty, we then grab the first IPv4 def from the
list. Also, instead of returning if there are no IPv4 defs, we just
return if there are no IP defs at all (either v4 or v6). This way a
network that is IPv6-only will still get dnsmasq listening for DNS
queries.
3) in networkStartNetworkDaemon() - we will startup dhcp not just if there
are any IPv4 addresses, but also if there are any IPv6 addresses.
2011-03-11 16:47:58 +00:00
|
|
|
/* If no IPv4 addresses had dhcp info, pick the first (if there were any). */
|
2010-12-10 21:04:37 +00:00
|
|
|
if (!ipdef)
|
network driver: Start dnsmasq even if no dhcp ranges/hosts are specified.
This fixes a regression introduced in commit ad48df, and reported on
the libvirt-users list:
https://www.redhat.com/archives/libvirt-users/2011-March/msg00018.html
The problem in that commit was that we began searching a list of ip
address definitions (rather than just having one) to look for a dhcp
range or static host; when we didn't find any, our pointer (ipdef) was
left at NULL, and when ipdef was NULL, we returned without starting up
dnsmasq.
Previously dnsmasq was started even without any dhcp ranges or static
entries, because it's still useful for DNS services.
Another problem I noticed while investigating was that, if there are
IPv6 addresses, but no IPv4 addresses of any kind, we would jump out
at an ever higher level in the call chain.
This patch does the following:
1) networkBuildDnsmasqArgv() = all uses of ipdef are protected from
NULL dereference. (this patch doesn't change indentation, to make
review easier. The next patch will change just the
indentation). ipdef is intended to point to the first IPv4 address
with DHCP info (or the first IPv4 address if none of them have any
dhcp info).
2) networkStartDhcpDaemon() = if the loop looking for an ipdef with
DHCP info comes up empty, we then grab the first IPv4 def from the
list. Also, instead of returning if there are no IPv4 defs, we just
return if there are no IP defs at all (either v4 or v6). This way a
network that is IPv6-only will still get dnsmasq listening for DNS
queries.
3) in networkStartNetworkDaemon() - we will startup dhcp not just if there
are any IPv4 addresses, but also if there are any IPv6 addresses.
2011-03-11 16:47:58 +00:00
|
|
|
ipdef = virNetworkDefGetIpByIndex(network->def, AF_INET, 0);
|
|
|
|
|
|
|
|
/* If there are no IP addresses at all (v4 or v6), return now, since
|
|
|
|
* there won't be any address for dnsmasq to listen on anyway.
|
|
|
|
* If there are any addresses, even if no dhcp ranges or static entries,
|
|
|
|
* we should continue and run dnsmasq, just for the DNS capabilities.
|
|
|
|
*/
|
|
|
|
if (!virNetworkDefGetIpByIndex(network->def, AF_UNSPEC, 0))
|
2010-12-10 21:04:37 +00:00
|
|
|
return 0;
|
2008-10-10 13:57:13 +00:00
|
|
|
|
2011-06-24 10:04:38 +00:00
|
|
|
cmd = virCommandNew(DNSMASQ);
|
network: Fix dnsmasq hostsfile creation logic and related tests
networkSaveDnsmasqHostsfile was added in 8fa9c2214247 (Apr 2010).
It has a force flag. If the dnsmasq hostsfile already exists force
needs to be true to overwrite it. networkBuildDnsmasqArgv sets force
to false, networkDefine sets it to true. This results in the
hostsfile being written only in networkDefine in the common case.
If no error occurred networkSaveDnsmasqHostsfile returns true and
networkBuildDnsmasqArgv adds the --dhcp-hostsfile to the dnsmasq
command line.
networkSaveDnsmasqHostsfile was changed in 89ae9849f744 (24 Jun 2011)
to return a new dnsmasqContext instead of reusing one. This change broke
the logic of the force flag as now networkSaveDnsmasqHostsfile returns
NULL on error, but the early return -- if force was not set and the
hostsfile exists -- returns 0. This turned the early return in an error
case and networkBuildDnsmasqArgv didn't add the --dhcp-hostsfile option
anymore if the hostsfile already exists. It did because networkDefine
created the hostsfile already.
Then 9d4e2845d498 fixed the return 0 case in networkSaveDnsmasqHostsfile
but didn't apply the force option correctly to the new addnhosts file.
Now force doesn't control an early return anymore, but influences the
handling of the hostsfile context creation and dnsmasqSave is always
called now. This commit also added test cases that reveal several
problems. First, the tests now calls functions that try to write the
dnsmasq config files to disk. If someone runs this tests as root this
might overwrite actively used dnsmasq config files, this is a no-go. Also
the tests depend on configure --localstatedir, this needs to be fixed as
well, because it makes the tests fail when localstatedir is different
from /var.
This patch does several things to fix this:
1) Move dnsmasqContext creation and saving out of networkBuildDnsmasqArgv
to the caller to separate the command line generation from the config
file writing. This makes the command line generation testable without the
risk of interfering with system files, because the tests just don't call
dnsmasqSave.
2) This refactoring of networkSaveDnsmasqHostsfile makes the force flag
useless as the saving happens somewhere else now. This fixes the wrong
usage of the force flag in combination with then newly added addnhosts
file by removing the force flag.
3) Adapt the wrong test cases to the correct behavior, by adding the
missing --dhcp-hostsfile option. Both affected tests contain DHCP host
elements but missed the necessary --dhcp-hostsfile option.
4) Rename networkSaveDnsmasqHostsfile to networkBuildDnsmasqHostsfile,
because it doesn't save the dnsmasqContext anymore.
5) Move all directory creations in dnsmasq context handling code from
the *New functions to dnsmasqSave to avoid directory creations in system
paths in the test cases.
6) Now that networkBuildDnsmasqArgv doesn't create the dnsmasqContext
anymore the test case can create one with the localstatedir that is
expected by the tests instead of the configure --localstatedir given one.
2011-06-28 11:07:59 +00:00
|
|
|
if (networkBuildDnsmasqArgv(network, ipdef, pidfile, cmd, dctx) < 0) {
|
2011-06-24 10:04:38 +00:00
|
|
|
goto cleanup;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (cmdout)
|
|
|
|
*cmdout = cmd;
|
|
|
|
ret = 0;
|
|
|
|
cleanup:
|
|
|
|
if (ret < 0)
|
|
|
|
virCommandFree(cmd);
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int
|
|
|
|
networkStartDhcpDaemon(virNetworkObjPtr network)
|
|
|
|
{
|
|
|
|
virCommandPtr cmd = NULL;
|
|
|
|
char *pidfile = NULL;
|
|
|
|
int ret = -1;
|
network: Fix dnsmasq hostsfile creation logic and related tests
networkSaveDnsmasqHostsfile was added in 8fa9c2214247 (Apr 2010).
It has a force flag. If the dnsmasq hostsfile already exists force
needs to be true to overwrite it. networkBuildDnsmasqArgv sets force
to false, networkDefine sets it to true. This results in the
hostsfile being written only in networkDefine in the common case.
If no error occurred networkSaveDnsmasqHostsfile returns true and
networkBuildDnsmasqArgv adds the --dhcp-hostsfile to the dnsmasq
command line.
networkSaveDnsmasqHostsfile was changed in 89ae9849f744 (24 Jun 2011)
to return a new dnsmasqContext instead of reusing one. This change broke
the logic of the force flag as now networkSaveDnsmasqHostsfile returns
NULL on error, but the early return -- if force was not set and the
hostsfile exists -- returns 0. This turned the early return in an error
case and networkBuildDnsmasqArgv didn't add the --dhcp-hostsfile option
anymore if the hostsfile already exists. It did because networkDefine
created the hostsfile already.
Then 9d4e2845d498 fixed the return 0 case in networkSaveDnsmasqHostsfile
but didn't apply the force option correctly to the new addnhosts file.
Now force doesn't control an early return anymore, but influences the
handling of the hostsfile context creation and dnsmasqSave is always
called now. This commit also added test cases that reveal several
problems. First, the tests now calls functions that try to write the
dnsmasq config files to disk. If someone runs this tests as root this
might overwrite actively used dnsmasq config files, this is a no-go. Also
the tests depend on configure --localstatedir, this needs to be fixed as
well, because it makes the tests fail when localstatedir is different
from /var.
This patch does several things to fix this:
1) Move dnsmasqContext creation and saving out of networkBuildDnsmasqArgv
to the caller to separate the command line generation from the config
file writing. This makes the command line generation testable without the
risk of interfering with system files, because the tests just don't call
dnsmasqSave.
2) This refactoring of networkSaveDnsmasqHostsfile makes the force flag
useless as the saving happens somewhere else now. This fixes the wrong
usage of the force flag in combination with then newly added addnhosts
file by removing the force flag.
3) Adapt the wrong test cases to the correct behavior, by adding the
missing --dhcp-hostsfile option. Both affected tests contain DHCP host
elements but missed the necessary --dhcp-hostsfile option.
4) Rename networkSaveDnsmasqHostsfile to networkBuildDnsmasqHostsfile,
because it doesn't save the dnsmasqContext anymore.
5) Move all directory creations in dnsmasq context handling code from
the *New functions to dnsmasqSave to avoid directory creations in system
paths in the test cases.
6) Now that networkBuildDnsmasqArgv doesn't create the dnsmasqContext
anymore the test case can create one with the localstatedir that is
expected by the tests instead of the configure --localstatedir given one.
2011-06-28 11:07:59 +00:00
|
|
|
dnsmasqContext *dctx = NULL;
|
2011-06-24 10:04:38 +00:00
|
|
|
|
2011-07-05 21:02:53 +00:00
|
|
|
if (virFileMakePath(NETWORK_PID_DIR) < 0) {
|
|
|
|
virReportSystemError(errno,
|
2009-01-20 22:36:10 +00:00
|
|
|
_("cannot create directory %s"),
|
|
|
|
NETWORK_PID_DIR);
|
2010-12-10 18:54:48 +00:00
|
|
|
goto cleanup;
|
2009-01-20 22:36:10 +00:00
|
|
|
}
|
2011-07-05 21:02:53 +00:00
|
|
|
if (virFileMakePath(NETWORK_STATE_DIR) < 0) {
|
|
|
|
virReportSystemError(errno,
|
2009-01-20 22:36:10 +00:00
|
|
|
_("cannot create directory %s"),
|
|
|
|
NETWORK_STATE_DIR);
|
2010-12-10 18:54:48 +00:00
|
|
|
goto cleanup;
|
2009-01-20 22:36:10 +00:00
|
|
|
}
|
|
|
|
|
2011-08-05 13:13:12 +00:00
|
|
|
if (!(pidfile = virPidFileBuildPath(NETWORK_PID_DIR, network->def->name))) {
|
2010-02-04 18:19:08 +00:00
|
|
|
virReportOOMError();
|
2010-12-10 18:54:48 +00:00
|
|
|
goto cleanup;
|
2009-01-20 22:36:10 +00:00
|
|
|
}
|
|
|
|
|
2011-07-05 21:02:53 +00:00
|
|
|
if (virFileMakePath(DNSMASQ_STATE_DIR) < 0) {
|
|
|
|
virReportSystemError(errno,
|
2011-04-23 12:28:44 +00:00
|
|
|
_("cannot create directory %s"),
|
|
|
|
DNSMASQ_STATE_DIR);
|
|
|
|
goto cleanup;
|
|
|
|
}
|
|
|
|
|
network: Fix dnsmasq hostsfile creation logic and related tests
networkSaveDnsmasqHostsfile was added in 8fa9c2214247 (Apr 2010).
It has a force flag. If the dnsmasq hostsfile already exists force
needs to be true to overwrite it. networkBuildDnsmasqArgv sets force
to false, networkDefine sets it to true. This results in the
hostsfile being written only in networkDefine in the common case.
If no error occurred networkSaveDnsmasqHostsfile returns true and
networkBuildDnsmasqArgv adds the --dhcp-hostsfile to the dnsmasq
command line.
networkSaveDnsmasqHostsfile was changed in 89ae9849f744 (24 Jun 2011)
to return a new dnsmasqContext instead of reusing one. This change broke
the logic of the force flag as now networkSaveDnsmasqHostsfile returns
NULL on error, but the early return -- if force was not set and the
hostsfile exists -- returns 0. This turned the early return in an error
case and networkBuildDnsmasqArgv didn't add the --dhcp-hostsfile option
anymore if the hostsfile already exists. It did because networkDefine
created the hostsfile already.
Then 9d4e2845d498 fixed the return 0 case in networkSaveDnsmasqHostsfile
but didn't apply the force option correctly to the new addnhosts file.
Now force doesn't control an early return anymore, but influences the
handling of the hostsfile context creation and dnsmasqSave is always
called now. This commit also added test cases that reveal several
problems. First, the tests now calls functions that try to write the
dnsmasq config files to disk. If someone runs this tests as root this
might overwrite actively used dnsmasq config files, this is a no-go. Also
the tests depend on configure --localstatedir, this needs to be fixed as
well, because it makes the tests fail when localstatedir is different
from /var.
This patch does several things to fix this:
1) Move dnsmasqContext creation and saving out of networkBuildDnsmasqArgv
to the caller to separate the command line generation from the config
file writing. This makes the command line generation testable without the
risk of interfering with system files, because the tests just don't call
dnsmasqSave.
2) This refactoring of networkSaveDnsmasqHostsfile makes the force flag
useless as the saving happens somewhere else now. This fixes the wrong
usage of the force flag in combination with then newly added addnhosts
file by removing the force flag.
3) Adapt the wrong test cases to the correct behavior, by adding the
missing --dhcp-hostsfile option. Both affected tests contain DHCP host
elements but missed the necessary --dhcp-hostsfile option.
4) Rename networkSaveDnsmasqHostsfile to networkBuildDnsmasqHostsfile,
because it doesn't save the dnsmasqContext anymore.
5) Move all directory creations in dnsmasq context handling code from
the *New functions to dnsmasqSave to avoid directory creations in system
paths in the test cases.
6) Now that networkBuildDnsmasqArgv doesn't create the dnsmasqContext
anymore the test case can create one with the localstatedir that is
expected by the tests instead of the configure --localstatedir given one.
2011-06-28 11:07:59 +00:00
|
|
|
dctx = dnsmasqContextNew(network->def->name, DNSMASQ_STATE_DIR);
|
|
|
|
if (dctx == NULL)
|
|
|
|
goto cleanup;
|
|
|
|
|
|
|
|
ret = networkBuildDhcpDaemonCommandLine(network, &cmd, pidfile, dctx);
|
|
|
|
if (ret < 0)
|
|
|
|
goto cleanup;
|
|
|
|
|
|
|
|
ret = dnsmasqSave(dctx);
|
|
|
|
if (ret < 0)
|
2010-12-10 18:54:48 +00:00
|
|
|
goto cleanup;
|
2009-01-20 22:36:10 +00:00
|
|
|
|
2011-07-23 21:24:21 +00:00
|
|
|
ret = virCommandRun(cmd, NULL);
|
|
|
|
if (ret < 0) {
|
2009-01-20 22:36:10 +00:00
|
|
|
goto cleanup;
|
2011-07-23 21:24:21 +00:00
|
|
|
}
|
2009-01-20 22:36:10 +00:00
|
|
|
|
|
|
|
/*
|
2010-12-10 18:54:48 +00:00
|
|
|
* There really is no race here - when dnsmasq daemonizes, its
|
|
|
|
* leader process stays around until its child has actually
|
|
|
|
* written its pidfile. So by time virCommandRun exits it has
|
|
|
|
* waitpid'd and guaranteed the proess has started and written a
|
|
|
|
* pid
|
2009-01-20 22:36:10 +00:00
|
|
|
*/
|
|
|
|
|
2011-08-05 13:13:12 +00:00
|
|
|
ret = virPidFileRead(NETWORK_PID_DIR, network->def->name,
|
2011-07-25 18:11:38 +00:00
|
|
|
&network->dnsmasqPid);
|
|
|
|
if (ret < 0)
|
2009-01-20 22:36:10 +00:00
|
|
|
goto cleanup;
|
2008-10-10 13:57:13 +00:00
|
|
|
|
2009-01-20 22:36:10 +00:00
|
|
|
ret = 0;
|
|
|
|
cleanup:
|
|
|
|
VIR_FREE(pidfile);
|
2010-12-10 18:54:48 +00:00
|
|
|
virCommandFree(cmd);
|
network: Fix dnsmasq hostsfile creation logic and related tests
networkSaveDnsmasqHostsfile was added in 8fa9c2214247 (Apr 2010).
It has a force flag. If the dnsmasq hostsfile already exists force
needs to be true to overwrite it. networkBuildDnsmasqArgv sets force
to false, networkDefine sets it to true. This results in the
hostsfile being written only in networkDefine in the common case.
If no error occurred networkSaveDnsmasqHostsfile returns true and
networkBuildDnsmasqArgv adds the --dhcp-hostsfile to the dnsmasq
command line.
networkSaveDnsmasqHostsfile was changed in 89ae9849f744 (24 Jun 2011)
to return a new dnsmasqContext instead of reusing one. This change broke
the logic of the force flag as now networkSaveDnsmasqHostsfile returns
NULL on error, but the early return -- if force was not set and the
hostsfile exists -- returns 0. This turned the early return in an error
case and networkBuildDnsmasqArgv didn't add the --dhcp-hostsfile option
anymore if the hostsfile already exists. It did because networkDefine
created the hostsfile already.
Then 9d4e2845d498 fixed the return 0 case in networkSaveDnsmasqHostsfile
but didn't apply the force option correctly to the new addnhosts file.
Now force doesn't control an early return anymore, but influences the
handling of the hostsfile context creation and dnsmasqSave is always
called now. This commit also added test cases that reveal several
problems. First, the tests now calls functions that try to write the
dnsmasq config files to disk. If someone runs this tests as root this
might overwrite actively used dnsmasq config files, this is a no-go. Also
the tests depend on configure --localstatedir, this needs to be fixed as
well, because it makes the tests fail when localstatedir is different
from /var.
This patch does several things to fix this:
1) Move dnsmasqContext creation and saving out of networkBuildDnsmasqArgv
to the caller to separate the command line generation from the config
file writing. This makes the command line generation testable without the
risk of interfering with system files, because the tests just don't call
dnsmasqSave.
2) This refactoring of networkSaveDnsmasqHostsfile makes the force flag
useless as the saving happens somewhere else now. This fixes the wrong
usage of the force flag in combination with then newly added addnhosts
file by removing the force flag.
3) Adapt the wrong test cases to the correct behavior, by adding the
missing --dhcp-hostsfile option. Both affected tests contain DHCP host
elements but missed the necessary --dhcp-hostsfile option.
4) Rename networkSaveDnsmasqHostsfile to networkBuildDnsmasqHostsfile,
because it doesn't save the dnsmasqContext anymore.
5) Move all directory creations in dnsmasq context handling code from
the *New functions to dnsmasqSave to avoid directory creations in system
paths in the test cases.
6) Now that networkBuildDnsmasqArgv doesn't create the dnsmasqContext
anymore the test case can create one with the localstatedir that is
expected by the tests instead of the configure --localstatedir given one.
2011-06-28 11:07:59 +00:00
|
|
|
dnsmasqContextFree(dctx);
|
2008-10-10 13:57:13 +00:00
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2010-12-20 06:14:11 +00:00
|
|
|
static int
|
|
|
|
networkStartRadvd(virNetworkObjPtr network)
|
|
|
|
{
|
|
|
|
char *pidfile = NULL;
|
|
|
|
char *radvdpidbase = NULL;
|
|
|
|
virBuffer configbuf = VIR_BUFFER_INITIALIZER;;
|
|
|
|
char *configstr = NULL;
|
|
|
|
char *configfile = NULL;
|
|
|
|
virCommandPtr cmd = NULL;
|
2011-07-05 21:02:53 +00:00
|
|
|
int ret = -1, ii;
|
2010-12-20 06:14:11 +00:00
|
|
|
virNetworkIpDefPtr ipdef;
|
|
|
|
|
|
|
|
network->radvdPid = -1;
|
|
|
|
|
2011-03-18 20:41:13 +00:00
|
|
|
if (!virFileIsExecutable(RADVD)) {
|
2011-03-18 17:05:08 +00:00
|
|
|
virReportSystemError(errno,
|
|
|
|
_("Cannot find %s - "
|
|
|
|
"Possibly the package isn't installed"),
|
|
|
|
RADVD);
|
|
|
|
goto cleanup;
|
|
|
|
}
|
|
|
|
|
2011-07-05 21:02:53 +00:00
|
|
|
if (virFileMakePath(NETWORK_PID_DIR) < 0) {
|
|
|
|
virReportSystemError(errno,
|
2010-12-20 06:14:11 +00:00
|
|
|
_("cannot create directory %s"),
|
|
|
|
NETWORK_PID_DIR);
|
|
|
|
goto cleanup;
|
|
|
|
}
|
2011-07-05 21:02:53 +00:00
|
|
|
if (virFileMakePath(RADVD_STATE_DIR) < 0) {
|
|
|
|
virReportSystemError(errno,
|
2010-12-20 06:14:11 +00:00
|
|
|
_("cannot create directory %s"),
|
|
|
|
RADVD_STATE_DIR);
|
|
|
|
goto cleanup;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* construct pidfile name */
|
|
|
|
if (!(radvdpidbase = networkRadvdPidfileBasename(network->def->name))) {
|
|
|
|
virReportOOMError();
|
|
|
|
goto cleanup;
|
|
|
|
}
|
2011-08-05 13:13:12 +00:00
|
|
|
if (!(pidfile = virPidFileBuildPath(NETWORK_PID_DIR, radvdpidbase))) {
|
2010-12-20 06:14:11 +00:00
|
|
|
virReportOOMError();
|
|
|
|
goto cleanup;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* create radvd config file appropriate for this network */
|
2011-04-30 16:34:49 +00:00
|
|
|
virBufferAsprintf(&configbuf, "interface %s\n"
|
2010-12-20 06:14:11 +00:00
|
|
|
"{\n"
|
|
|
|
" AdvSendAdvert on;\n"
|
|
|
|
" AdvManagedFlag off;\n"
|
|
|
|
" AdvOtherConfigFlag off;\n"
|
|
|
|
"\n",
|
|
|
|
network->def->bridge);
|
|
|
|
for (ii = 0;
|
|
|
|
(ipdef = virNetworkDefGetIpByIndex(network->def, AF_INET6, ii));
|
|
|
|
ii++) {
|
|
|
|
int prefix;
|
|
|
|
char *netaddr;
|
|
|
|
|
|
|
|
prefix = virNetworkIpDefPrefix(ipdef);
|
|
|
|
if (prefix < 0) {
|
2012-07-18 11:50:10 +00:00
|
|
|
virReportError(VIR_ERR_INTERNAL_ERROR,
|
|
|
|
_("bridge '%s' has an invalid prefix"),
|
|
|
|
network->def->bridge);
|
2010-12-20 06:14:11 +00:00
|
|
|
goto cleanup;
|
|
|
|
}
|
Santize naming of socket address APIs
The socket address APIs in src/util/network.h either take the
form virSocketAddrXXX, virSocketXXX or virSocketXXXAddr.
Sanitize this so everything is virSocketAddrXXXX, and ensure
that the virSocketAddr parameter is always the first one.
* src/util/network.c, src/util/network.h: Santize socket
address API naming
* src/conf/domain_conf.c, src/conf/network_conf.c,
src/conf/nwfilter_conf.c, src/network/bridge_driver.c,
src/nwfilter/nwfilter_ebiptables_driver.c,
src/nwfilter/nwfilter_learnipaddr.c,
src/qemu/qemu_command.c, src/rpc/virnetsocket.c,
src/util/dnsmasq.c, src/util/iptables.c,
src/util/virnetdev.c, src/vbox/vbox_tmpl.c: Update for
API renaming
2011-11-02 14:06:59 +00:00
|
|
|
if (!(netaddr = virSocketAddrFormat(&ipdef->address)))
|
2010-12-20 06:14:11 +00:00
|
|
|
goto cleanup;
|
2011-04-30 16:34:49 +00:00
|
|
|
virBufferAsprintf(&configbuf,
|
2010-12-20 06:14:11 +00:00
|
|
|
" prefix %s/%d\n"
|
|
|
|
" {\n"
|
|
|
|
" AdvOnLink on;\n"
|
|
|
|
" AdvAutonomous on;\n"
|
|
|
|
" AdvRouterAddr off;\n"
|
|
|
|
" };\n",
|
|
|
|
netaddr, prefix);
|
|
|
|
VIR_FREE(netaddr);
|
|
|
|
}
|
|
|
|
|
|
|
|
virBufferAddLit(&configbuf, "};\n");
|
|
|
|
|
|
|
|
if (virBufferError(&configbuf)) {
|
|
|
|
virReportOOMError();
|
|
|
|
goto cleanup;
|
|
|
|
}
|
|
|
|
if (!(configstr = virBufferContentAndReset(&configbuf))) {
|
|
|
|
virReportOOMError();
|
|
|
|
goto cleanup;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* construct the filename */
|
|
|
|
if (!(configfile = networkRadvdConfigFileName(network->def->name))) {
|
|
|
|
virReportOOMError();
|
|
|
|
goto cleanup;
|
|
|
|
}
|
|
|
|
/* write the file */
|
|
|
|
if (virFileWriteStr(configfile, configstr, 0600) < 0) {
|
|
|
|
virReportSystemError(errno,
|
|
|
|
_("couldn't write radvd config file '%s'"),
|
|
|
|
configfile);
|
|
|
|
goto cleanup;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* prevent radvd from daemonizing itself with "--debug 1", and use
|
|
|
|
* a dummy pidfile name - virCommand will create the pidfile we
|
|
|
|
* want to use (this is necessary because radvd's internal
|
|
|
|
* daemonization and pidfile creation causes a race, and the
|
2011-08-05 13:13:12 +00:00
|
|
|
* virPidFileRead() below will fail if we use them).
|
2010-12-20 06:14:11 +00:00
|
|
|
* Unfortunately, it isn't possible to tell radvd to not create
|
|
|
|
* its own pidfile, so we just let it do so, with a slightly
|
|
|
|
* different name. Unused, but harmless.
|
|
|
|
*/
|
|
|
|
cmd = virCommandNewArgList(RADVD, "--debug", "1",
|
|
|
|
"--config", configfile,
|
|
|
|
"--pidfile", NULL);
|
|
|
|
virCommandAddArgFormat(cmd, "%s-bin", pidfile);
|
|
|
|
|
|
|
|
virCommandSetPidFile(cmd, pidfile);
|
|
|
|
virCommandDaemonize(cmd);
|
|
|
|
|
|
|
|
if (virCommandRun(cmd, NULL) < 0)
|
|
|
|
goto cleanup;
|
|
|
|
|
2011-08-05 13:13:12 +00:00
|
|
|
if (virPidFileRead(NETWORK_PID_DIR, radvdpidbase,
|
2010-12-20 06:14:11 +00:00
|
|
|
&network->radvdPid) < 0)
|
|
|
|
goto cleanup;
|
|
|
|
|
|
|
|
ret = 0;
|
|
|
|
cleanup:
|
|
|
|
virCommandFree(cmd);
|
|
|
|
VIR_FREE(configfile);
|
|
|
|
VIR_FREE(configstr);
|
|
|
|
virBufferFreeAndReset(&configbuf);
|
|
|
|
VIR_FREE(radvdpidbase);
|
|
|
|
VIR_FREE(pidfile);
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2008-10-10 13:57:13 +00:00
|
|
|
static int
|
2010-02-04 20:02:58 +00:00
|
|
|
networkAddMasqueradingIptablesRules(struct network_driver *driver,
|
2010-12-10 21:04:37 +00:00
|
|
|
virNetworkObjPtr network,
|
|
|
|
virNetworkIpDefPtr ipdef)
|
2010-11-17 18:36:19 +00:00
|
|
|
{
|
|
|
|
int prefix = virNetworkIpDefPrefix(ipdef);
|
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
|
|
|
const char *forwardIf = virNetworkDefForwardIf(network->def, 0);
|
2010-11-30 19:35:58 +00:00
|
|
|
|
|
|
|
if (prefix < 0) {
|
2012-07-18 11:50:10 +00:00
|
|
|
virReportError(VIR_ERR_INTERNAL_ERROR,
|
|
|
|
_("Invalid prefix or netmask for '%s'"),
|
|
|
|
network->def->bridge);
|
2010-11-30 19:35:58 +00:00
|
|
|
goto masqerr1;
|
|
|
|
}
|
2010-12-14 20:01:10 +00:00
|
|
|
|
2008-10-10 13:57:13 +00:00
|
|
|
/* allow forwarding packets from the bridge interface */
|
2010-12-14 20:01:10 +00:00
|
|
|
if (iptablesAddForwardAllowOut(driver->iptables,
|
2010-11-17 18:36:19 +00:00
|
|
|
&ipdef->address,
|
2010-11-30 19:35:58 +00:00
|
|
|
prefix,
|
2010-12-14 20:01:10 +00:00
|
|
|
network->def->bridge,
|
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
|
|
|
forwardIf) < 0) {
|
2012-07-18 11:50:10 +00:00
|
|
|
virReportError(VIR_ERR_SYSTEM_ERROR,
|
|
|
|
_("failed to add iptables rule to allow forwarding from '%s'"),
|
|
|
|
network->def->bridge);
|
2008-10-10 13:57:13 +00:00
|
|
|
goto masqerr1;
|
|
|
|
}
|
|
|
|
|
2010-12-10 21:04:37 +00:00
|
|
|
/* allow forwarding packets to the bridge interface if they are
|
|
|
|
* part of an existing connection
|
|
|
|
*/
|
2010-12-14 20:01:10 +00:00
|
|
|
if (iptablesAddForwardAllowRelatedIn(driver->iptables,
|
2010-11-17 18:36:19 +00:00
|
|
|
&ipdef->address,
|
2010-11-30 19:35:58 +00:00
|
|
|
prefix,
|
2010-12-14 20:01:10 +00:00
|
|
|
network->def->bridge,
|
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
|
|
|
forwardIf) < 0) {
|
2012-07-18 11:50:10 +00:00
|
|
|
virReportError(VIR_ERR_SYSTEM_ERROR,
|
|
|
|
_("failed to add iptables rule to allow forwarding to '%s'"),
|
|
|
|
network->def->bridge);
|
2008-10-10 13:57:13 +00:00
|
|
|
goto masqerr2;
|
|
|
|
}
|
|
|
|
|
2010-06-10 16:50:38 +00:00
|
|
|
/*
|
|
|
|
* Enable masquerading.
|
|
|
|
*
|
|
|
|
* We need to end up with 3 rules in the table in this order
|
|
|
|
*
|
2010-07-28 14:05:55 +00:00
|
|
|
* 1. protocol=tcp with sport mapping restriction
|
|
|
|
* 2. protocol=udp with sport mapping restriction
|
2010-06-10 16:50:38 +00:00
|
|
|
* 3. generic any protocol
|
|
|
|
*
|
|
|
|
* The sport mappings are required, because default IPtables
|
2010-07-28 14:05:55 +00:00
|
|
|
* MASQUERADE maintain port numbers unchanged where possible.
|
2010-06-10 16:50:38 +00:00
|
|
|
*
|
|
|
|
* NFS can be configured to only "trust" port numbers < 1023.
|
|
|
|
*
|
|
|
|
* Guests using NAT thus need to be prevented from having port
|
|
|
|
* numbers < 1023, otherwise they can bypass the NFS "security"
|
|
|
|
* check on the source port number.
|
|
|
|
*
|
|
|
|
* Since we use '--insert' to add rules to the header of the
|
|
|
|
* chain, we actually need to add them in the reverse of the
|
|
|
|
* order just mentioned !
|
|
|
|
*/
|
|
|
|
|
|
|
|
/* First the generic masquerade rule for other protocols */
|
2010-12-14 20:01:10 +00:00
|
|
|
if (iptablesAddForwardMasquerade(driver->iptables,
|
2010-11-17 18:36:19 +00:00
|
|
|
&ipdef->address,
|
2010-11-30 19:35:58 +00:00
|
|
|
prefix,
|
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
|
|
|
forwardIf,
|
2010-12-14 20:01:10 +00:00
|
|
|
NULL) < 0) {
|
2012-07-18 11:50:10 +00:00
|
|
|
virReportError(VIR_ERR_SYSTEM_ERROR,
|
|
|
|
forwardIf ?
|
|
|
|
_("failed to add iptables rule to enable masquerading to %s") :
|
|
|
|
_("failed to add iptables rule to enable masquerading"),
|
|
|
|
forwardIf);
|
2008-10-10 13:57:13 +00:00
|
|
|
goto masqerr3;
|
|
|
|
}
|
|
|
|
|
2010-06-10 16:50:38 +00:00
|
|
|
/* UDP with a source port restriction */
|
2010-12-14 20:01:10 +00:00
|
|
|
if (iptablesAddForwardMasquerade(driver->iptables,
|
2010-11-17 18:36:19 +00:00
|
|
|
&ipdef->address,
|
2010-11-30 19:35:58 +00:00
|
|
|
prefix,
|
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
|
|
|
forwardIf,
|
2010-12-14 20:01:10 +00:00
|
|
|
"udp") < 0) {
|
2012-07-18 11:50:10 +00:00
|
|
|
virReportError(VIR_ERR_SYSTEM_ERROR,
|
|
|
|
forwardIf ?
|
|
|
|
_("failed to add iptables rule to enable UDP masquerading to %s") :
|
|
|
|
_("failed to add iptables rule to enable UDP masquerading"),
|
|
|
|
forwardIf);
|
2010-06-10 16:50:38 +00:00
|
|
|
goto masqerr4;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* TCP with a source port restriction */
|
2010-12-14 20:01:10 +00:00
|
|
|
if (iptablesAddForwardMasquerade(driver->iptables,
|
2010-11-17 18:36:19 +00:00
|
|
|
&ipdef->address,
|
2010-11-30 19:35:58 +00:00
|
|
|
prefix,
|
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
|
|
|
forwardIf,
|
2010-12-14 20:01:10 +00:00
|
|
|
"tcp") < 0) {
|
2012-07-18 11:50:10 +00:00
|
|
|
virReportError(VIR_ERR_SYSTEM_ERROR,
|
|
|
|
forwardIf ?
|
|
|
|
_("failed to add iptables rule to enable TCP masquerading to %s") :
|
|
|
|
_("failed to add iptables rule to enable TCP masquerading"),
|
|
|
|
forwardIf);
|
2010-06-10 16:50:38 +00:00
|
|
|
goto masqerr5;
|
|
|
|
}
|
|
|
|
|
2010-12-15 06:49:29 +00:00
|
|
|
return 0;
|
2008-10-10 13:57:13 +00:00
|
|
|
|
2010-06-10 16:50:38 +00:00
|
|
|
masqerr5:
|
|
|
|
iptablesRemoveForwardMasquerade(driver->iptables,
|
2010-11-17 18:36:19 +00:00
|
|
|
&ipdef->address,
|
2010-11-30 19:35:58 +00:00
|
|
|
prefix,
|
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
|
|
|
forwardIf,
|
2010-06-10 16:50:38 +00:00
|
|
|
"udp");
|
|
|
|
masqerr4:
|
|
|
|
iptablesRemoveForwardMasquerade(driver->iptables,
|
2010-11-17 18:36:19 +00:00
|
|
|
&ipdef->address,
|
2010-11-30 19:35:58 +00:00
|
|
|
prefix,
|
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
|
|
|
forwardIf,
|
2010-06-10 16:50:38 +00:00
|
|
|
NULL);
|
2008-10-10 13:57:13 +00:00
|
|
|
masqerr3:
|
|
|
|
iptablesRemoveForwardAllowRelatedIn(driver->iptables,
|
2010-11-17 18:36:19 +00:00
|
|
|
&ipdef->address,
|
2010-11-30 19:35:58 +00:00
|
|
|
prefix,
|
2010-10-25 14:10:33 +00:00
|
|
|
network->def->bridge,
|
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
|
|
|
forwardIf);
|
2008-10-10 13:57:13 +00:00
|
|
|
masqerr2:
|
|
|
|
iptablesRemoveForwardAllowOut(driver->iptables,
|
2010-11-17 18:36:19 +00:00
|
|
|
&ipdef->address,
|
2010-11-30 19:35:58 +00:00
|
|
|
prefix,
|
2008-10-10 13:57:13 +00:00
|
|
|
network->def->bridge,
|
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
|
|
|
forwardIf);
|
2008-10-10 13:57:13 +00:00
|
|
|
masqerr1:
|
2010-12-15 06:49:29 +00:00
|
|
|
return -1;
|
2008-10-10 13:57:13 +00:00
|
|
|
}
|
|
|
|
|
2010-12-10 21:04:37 +00:00
|
|
|
static void
|
|
|
|
networkRemoveMasqueradingIptablesRules(struct network_driver *driver,
|
|
|
|
virNetworkObjPtr network,
|
|
|
|
virNetworkIpDefPtr ipdef)
|
|
|
|
{
|
|
|
|
int prefix = virNetworkIpDefPrefix(ipdef);
|
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
|
|
|
const char *forwardIf = virNetworkDefForwardIf(network->def, 0);
|
2010-12-10 21:04:37 +00:00
|
|
|
|
|
|
|
if (prefix >= 0) {
|
|
|
|
iptablesRemoveForwardMasquerade(driver->iptables,
|
|
|
|
&ipdef->address,
|
|
|
|
prefix,
|
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
|
|
|
forwardIf,
|
2010-12-10 21:04:37 +00:00
|
|
|
"tcp");
|
|
|
|
iptablesRemoveForwardMasquerade(driver->iptables,
|
|
|
|
&ipdef->address,
|
|
|
|
prefix,
|
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
|
|
|
forwardIf,
|
2010-12-10 21:04:37 +00:00
|
|
|
"udp");
|
|
|
|
iptablesRemoveForwardMasquerade(driver->iptables,
|
|
|
|
&ipdef->address,
|
|
|
|
prefix,
|
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
|
|
|
forwardIf,
|
2010-12-10 21:04:37 +00:00
|
|
|
NULL);
|
|
|
|
|
|
|
|
iptablesRemoveForwardAllowRelatedIn(driver->iptables,
|
|
|
|
&ipdef->address,
|
|
|
|
prefix,
|
|
|
|
network->def->bridge,
|
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
|
|
|
forwardIf);
|
2010-12-10 21:04:37 +00:00
|
|
|
iptablesRemoveForwardAllowOut(driver->iptables,
|
|
|
|
&ipdef->address,
|
|
|
|
prefix,
|
|
|
|
network->def->bridge,
|
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
|
|
|
forwardIf);
|
2010-12-10 21:04:37 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2008-10-10 13:57:13 +00:00
|
|
|
static int
|
2010-02-04 20:02:58 +00:00
|
|
|
networkAddRoutingIptablesRules(struct network_driver *driver,
|
2010-11-17 18:36:19 +00:00
|
|
|
virNetworkObjPtr network,
|
2010-12-10 21:04:37 +00:00
|
|
|
virNetworkIpDefPtr ipdef)
|
|
|
|
{
|
2010-11-17 18:36:19 +00:00
|
|
|
int prefix = virNetworkIpDefPrefix(ipdef);
|
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
|
|
|
const char *forwardIf = virNetworkDefForwardIf(network->def, 0);
|
2010-11-30 19:35:58 +00:00
|
|
|
|
|
|
|
if (prefix < 0) {
|
2012-07-18 11:50:10 +00:00
|
|
|
virReportError(VIR_ERR_INTERNAL_ERROR,
|
|
|
|
_("Invalid prefix or netmask for '%s'"),
|
|
|
|
network->def->bridge);
|
2010-11-30 19:35:58 +00:00
|
|
|
goto routeerr1;
|
|
|
|
}
|
2010-12-14 20:01:10 +00:00
|
|
|
|
2008-10-10 13:57:13 +00:00
|
|
|
/* allow routing packets from the bridge interface */
|
2010-12-14 20:01:10 +00:00
|
|
|
if (iptablesAddForwardAllowOut(driver->iptables,
|
2010-11-17 18:36:19 +00:00
|
|
|
&ipdef->address,
|
2010-11-30 19:35:58 +00:00
|
|
|
prefix,
|
2010-12-14 20:01:10 +00:00
|
|
|
network->def->bridge,
|
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
|
|
|
forwardIf) < 0) {
|
2012-07-18 11:50:10 +00:00
|
|
|
virReportError(VIR_ERR_SYSTEM_ERROR,
|
|
|
|
_("failed to add iptables rule to allow routing from '%s'"),
|
|
|
|
network->def->bridge);
|
2008-10-10 13:57:13 +00:00
|
|
|
goto routeerr1;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* allow routing packets to the bridge interface */
|
2010-12-14 20:01:10 +00:00
|
|
|
if (iptablesAddForwardAllowIn(driver->iptables,
|
2010-11-17 18:36:19 +00:00
|
|
|
&ipdef->address,
|
2010-11-30 19:35:58 +00:00
|
|
|
prefix,
|
2010-12-14 20:01:10 +00:00
|
|
|
network->def->bridge,
|
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
|
|
|
forwardIf) < 0) {
|
2012-07-18 11:50:10 +00:00
|
|
|
virReportError(VIR_ERR_SYSTEM_ERROR,
|
|
|
|
_("failed to add iptables rule to allow routing to '%s'"),
|
|
|
|
network->def->bridge);
|
2008-10-10 13:57:13 +00:00
|
|
|
goto routeerr2;
|
|
|
|
}
|
|
|
|
|
2010-12-15 06:49:29 +00:00
|
|
|
return 0;
|
2008-10-10 13:57:13 +00:00
|
|
|
|
2010-12-10 21:04:37 +00:00
|
|
|
routeerr2:
|
2008-10-10 13:57:13 +00:00
|
|
|
iptablesRemoveForwardAllowOut(driver->iptables,
|
2010-11-17 18:36:19 +00:00
|
|
|
&ipdef->address,
|
2010-11-30 19:35:58 +00:00
|
|
|
prefix,
|
2008-10-10 13:57:13 +00:00
|
|
|
network->def->bridge,
|
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
|
|
|
forwardIf);
|
2010-12-10 21:04:37 +00:00
|
|
|
routeerr1:
|
2010-12-15 06:49:29 +00:00
|
|
|
return -1;
|
2008-10-10 13:57:13 +00:00
|
|
|
}
|
|
|
|
|
2010-12-10 21:04:37 +00:00
|
|
|
static void
|
|
|
|
networkRemoveRoutingIptablesRules(struct network_driver *driver,
|
|
|
|
virNetworkObjPtr network,
|
|
|
|
virNetworkIpDefPtr ipdef)
|
|
|
|
{
|
|
|
|
int prefix = virNetworkIpDefPrefix(ipdef);
|
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
|
|
|
const char *forwardIf = virNetworkDefForwardIf(network->def, 0);
|
2010-12-10 21:04:37 +00:00
|
|
|
|
|
|
|
if (prefix >= 0) {
|
|
|
|
iptablesRemoveForwardAllowIn(driver->iptables,
|
|
|
|
&ipdef->address,
|
|
|
|
prefix,
|
|
|
|
network->def->bridge,
|
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
|
|
|
forwardIf);
|
2010-12-10 21:04:37 +00:00
|
|
|
|
|
|
|
iptablesRemoveForwardAllowOut(driver->iptables,
|
|
|
|
&ipdef->address,
|
|
|
|
prefix,
|
|
|
|
network->def->bridge,
|
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
|
|
|
forwardIf);
|
2010-12-10 21:04:37 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2010-12-16 20:50:01 +00:00
|
|
|
/* Add all once/network rules required for IPv6 (if any IPv6 addresses are defined) */
|
|
|
|
static int
|
|
|
|
networkAddGeneralIp6tablesRules(struct network_driver *driver,
|
|
|
|
virNetworkObjPtr network)
|
|
|
|
{
|
|
|
|
|
|
|
|
if (!virNetworkDefGetIpByIndex(network->def, AF_INET6, 0))
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
/* Catch all rules to block forwarding to/from bridges */
|
|
|
|
|
|
|
|
if (iptablesAddForwardRejectOut(driver->iptables, AF_INET6,
|
|
|
|
network->def->bridge) < 0) {
|
2012-07-18 11:50:10 +00:00
|
|
|
virReportError(VIR_ERR_SYSTEM_ERROR,
|
|
|
|
_("failed to add ip6tables rule to block outbound traffic from '%s'"),
|
|
|
|
network->def->bridge);
|
2010-12-16 20:50:01 +00:00
|
|
|
goto err1;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (iptablesAddForwardRejectIn(driver->iptables, AF_INET6,
|
|
|
|
network->def->bridge) < 0) {
|
2012-07-18 11:50:10 +00:00
|
|
|
virReportError(VIR_ERR_SYSTEM_ERROR,
|
|
|
|
_("failed to add ip6tables rule to block inbound traffic to '%s'"),
|
|
|
|
network->def->bridge);
|
2010-12-16 20:50:01 +00:00
|
|
|
goto err2;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Allow traffic between guests on the same bridge */
|
|
|
|
if (iptablesAddForwardAllowCross(driver->iptables, AF_INET6,
|
|
|
|
network->def->bridge) < 0) {
|
2012-07-18 11:50:10 +00:00
|
|
|
virReportError(VIR_ERR_SYSTEM_ERROR,
|
|
|
|
_("failed to add ip6tables rule to allow cross bridge traffic on '%s'"),
|
|
|
|
network->def->bridge);
|
2010-12-16 20:50:01 +00:00
|
|
|
goto err3;
|
|
|
|
}
|
|
|
|
|
2011-01-31 20:31:57 +00:00
|
|
|
/* allow DNS over IPv6 */
|
|
|
|
if (iptablesAddTcpInput(driver->iptables, AF_INET6,
|
|
|
|
network->def->bridge, 53) < 0) {
|
2012-07-18 11:50:10 +00:00
|
|
|
virReportError(VIR_ERR_SYSTEM_ERROR,
|
|
|
|
_("failed to add ip6tables rule to allow DNS requests from '%s'"),
|
|
|
|
network->def->bridge);
|
2011-01-31 20:31:57 +00:00
|
|
|
goto err4;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (iptablesAddUdpInput(driver->iptables, AF_INET6,
|
|
|
|
network->def->bridge, 53) < 0) {
|
2012-07-18 11:50:10 +00:00
|
|
|
virReportError(VIR_ERR_SYSTEM_ERROR,
|
|
|
|
_("failed to add ip6tables rule to allow DNS requests from '%s'"),
|
|
|
|
network->def->bridge);
|
2011-01-31 20:31:57 +00:00
|
|
|
goto err5;
|
|
|
|
}
|
|
|
|
|
2010-12-16 20:50:01 +00:00
|
|
|
return 0;
|
|
|
|
|
|
|
|
/* unwind in reverse order from the point of failure */
|
2011-01-31 20:31:57 +00:00
|
|
|
err5:
|
|
|
|
iptablesRemoveTcpInput(driver->iptables, AF_INET6, network->def->bridge, 53);
|
|
|
|
err4:
|
|
|
|
iptablesRemoveForwardAllowCross(driver->iptables, AF_INET6, network->def->bridge);
|
2010-12-16 20:50:01 +00:00
|
|
|
err3:
|
|
|
|
iptablesRemoveForwardRejectIn(driver->iptables, AF_INET6, network->def->bridge);
|
|
|
|
err2:
|
|
|
|
iptablesRemoveForwardRejectOut(driver->iptables, AF_INET6, network->def->bridge);
|
|
|
|
err1:
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
|
|
|
networkRemoveGeneralIp6tablesRules(struct network_driver *driver,
|
|
|
|
virNetworkObjPtr network)
|
|
|
|
{
|
|
|
|
if (!virNetworkDefGetIpByIndex(network->def, AF_INET6, 0))
|
|
|
|
return;
|
|
|
|
|
|
|
|
iptablesRemoveForwardAllowCross(driver->iptables, AF_INET6, network->def->bridge);
|
|
|
|
iptablesRemoveForwardRejectIn(driver->iptables, AF_INET6, network->def->bridge);
|
|
|
|
iptablesRemoveForwardRejectOut(driver->iptables, AF_INET6, network->def->bridge);
|
|
|
|
}
|
|
|
|
|
2008-10-10 13:57:13 +00:00
|
|
|
static int
|
2010-12-10 21:04:37 +00:00
|
|
|
networkAddGeneralIptablesRules(struct network_driver *driver,
|
|
|
|
virNetworkObjPtr network)
|
|
|
|
{
|
|
|
|
int ii;
|
|
|
|
virNetworkIpDefPtr ipv4def;
|
|
|
|
|
|
|
|
/* First look for first IPv4 address that has dhcp or tftpboot defined. */
|
|
|
|
/* We support dhcp config on 1 IPv4 interface only. */
|
|
|
|
for (ii = 0;
|
|
|
|
(ipv4def = virNetworkDefGetIpByIndex(network->def, AF_INET, ii));
|
|
|
|
ii++) {
|
|
|
|
if (ipv4def->nranges || ipv4def->nhosts || ipv4def->tftproot)
|
|
|
|
break;
|
|
|
|
}
|
2008-10-10 13:57:13 +00:00
|
|
|
|
|
|
|
/* allow DHCP requests through to dnsmasq */
|
2010-12-10 21:04:37 +00:00
|
|
|
|
2010-12-08 19:09:25 +00:00
|
|
|
if (iptablesAddTcpInput(driver->iptables, AF_INET,
|
|
|
|
network->def->bridge, 67) < 0) {
|
2012-07-18 11:50:10 +00:00
|
|
|
virReportError(VIR_ERR_SYSTEM_ERROR,
|
|
|
|
_("failed to add iptables rule to allow DHCP requests from '%s'"),
|
|
|
|
network->def->bridge);
|
2008-10-10 13:57:13 +00:00
|
|
|
goto err1;
|
|
|
|
}
|
|
|
|
|
2010-12-08 19:09:25 +00:00
|
|
|
if (iptablesAddUdpInput(driver->iptables, AF_INET,
|
|
|
|
network->def->bridge, 67) < 0) {
|
2012-07-18 11:50:10 +00:00
|
|
|
virReportError(VIR_ERR_SYSTEM_ERROR,
|
|
|
|
_("failed to add iptables rule to allow DHCP requests from '%s'"),
|
|
|
|
network->def->bridge);
|
2008-10-10 13:57:13 +00:00
|
|
|
goto err2;
|
|
|
|
}
|
|
|
|
|
2010-12-10 21:04:37 +00:00
|
|
|
/* If we are doing local DHCP service on this network, attempt to
|
|
|
|
* add a rule that will fixup the checksum of DHCP response
|
|
|
|
* packets back to the guests (but report failure without
|
|
|
|
* aborting, since not all iptables implementations support it).
|
|
|
|
*/
|
|
|
|
|
|
|
|
if (ipv4def && (ipv4def->nranges || ipv4def->nhosts) &&
|
|
|
|
(iptablesAddOutputFixUdpChecksum(driver->iptables,
|
|
|
|
network->def->bridge, 68) < 0)) {
|
|
|
|
VIR_WARN("Could not add rule to fixup DHCP response checksums "
|
|
|
|
"on network '%s'.", network->def->name);
|
2011-05-09 09:24:09 +00:00
|
|
|
VIR_WARN("May need to update iptables package & kernel to support CHECKSUM rule.");
|
2010-12-10 21:04:37 +00:00
|
|
|
}
|
|
|
|
|
2008-10-10 13:57:13 +00:00
|
|
|
/* allow DNS requests through to dnsmasq */
|
2010-12-08 19:09:25 +00:00
|
|
|
if (iptablesAddTcpInput(driver->iptables, AF_INET,
|
|
|
|
network->def->bridge, 53) < 0) {
|
2012-07-18 11:50:10 +00:00
|
|
|
virReportError(VIR_ERR_SYSTEM_ERROR,
|
|
|
|
_("failed to add iptables rule to allow DNS requests from '%s'"),
|
|
|
|
network->def->bridge);
|
2008-10-10 13:57:13 +00:00
|
|
|
goto err3;
|
|
|
|
}
|
|
|
|
|
2010-12-08 19:09:25 +00:00
|
|
|
if (iptablesAddUdpInput(driver->iptables, AF_INET,
|
|
|
|
network->def->bridge, 53) < 0) {
|
2012-07-18 11:50:10 +00:00
|
|
|
virReportError(VIR_ERR_SYSTEM_ERROR,
|
|
|
|
_("failed to add iptables rule to allow DNS requests from '%s'"),
|
|
|
|
network->def->bridge);
|
2008-10-10 13:57:13 +00:00
|
|
|
goto err4;
|
|
|
|
}
|
|
|
|
|
2010-12-10 21:04:37 +00:00
|
|
|
/* allow TFTP requests through to dnsmasq if necessary */
|
|
|
|
if (ipv4def && ipv4def->tftproot &&
|
2010-12-08 19:09:25 +00:00
|
|
|
iptablesAddUdpInput(driver->iptables, AF_INET,
|
|
|
|
network->def->bridge, 69) < 0) {
|
2012-07-18 11:50:10 +00:00
|
|
|
virReportError(VIR_ERR_SYSTEM_ERROR,
|
|
|
|
_("failed to add iptables rule to allow TFTP requests from '%s'"),
|
|
|
|
network->def->bridge);
|
2010-12-10 21:04:37 +00:00
|
|
|
goto err5;
|
2010-06-19 18:08:26 +00:00
|
|
|
}
|
|
|
|
|
2008-10-10 13:57:13 +00:00
|
|
|
/* Catch all rules to block forwarding to/from bridges */
|
|
|
|
|
2010-12-08 19:09:25 +00:00
|
|
|
if (iptablesAddForwardRejectOut(driver->iptables, AF_INET,
|
|
|
|
network->def->bridge) < 0) {
|
2012-07-18 11:50:10 +00:00
|
|
|
virReportError(VIR_ERR_SYSTEM_ERROR,
|
|
|
|
_("failed to add iptables rule to block outbound traffic from '%s'"),
|
|
|
|
network->def->bridge);
|
2010-12-10 21:04:37 +00:00
|
|
|
goto err6;
|
2008-10-10 13:57:13 +00:00
|
|
|
}
|
|
|
|
|
2010-12-08 19:09:25 +00:00
|
|
|
if (iptablesAddForwardRejectIn(driver->iptables, AF_INET,
|
|
|
|
network->def->bridge) < 0) {
|
2012-07-18 11:50:10 +00:00
|
|
|
virReportError(VIR_ERR_SYSTEM_ERROR,
|
|
|
|
_("failed to add iptables rule to block inbound traffic to '%s'"),
|
|
|
|
network->def->bridge);
|
2010-12-10 21:04:37 +00:00
|
|
|
goto err7;
|
2008-10-10 13:57:13 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/* Allow traffic between guests on the same bridge */
|
2010-12-08 19:09:25 +00:00
|
|
|
if (iptablesAddForwardAllowCross(driver->iptables, AF_INET,
|
|
|
|
network->def->bridge) < 0) {
|
2012-07-18 11:50:10 +00:00
|
|
|
virReportError(VIR_ERR_SYSTEM_ERROR,
|
|
|
|
_("failed to add iptables rule to allow cross bridge traffic on '%s'"),
|
|
|
|
network->def->bridge);
|
2010-12-10 21:04:37 +00:00
|
|
|
goto err8;
|
2010-07-13 02:59:58 +00:00
|
|
|
}
|
|
|
|
|
2010-12-16 20:50:01 +00:00
|
|
|
/* add IPv6 general rules, if needed */
|
|
|
|
if (networkAddGeneralIp6tablesRules(driver, network) < 0) {
|
|
|
|
goto err9;
|
|
|
|
}
|
|
|
|
|
2010-12-15 06:49:29 +00:00
|
|
|
return 0;
|
2008-10-10 13:57:13 +00:00
|
|
|
|
2010-12-10 21:04:37 +00:00
|
|
|
/* unwind in reverse order from the point of failure */
|
2010-12-16 20:50:01 +00:00
|
|
|
err9:
|
|
|
|
iptablesRemoveForwardAllowCross(driver->iptables, AF_INET, network->def->bridge);
|
2010-12-10 21:04:37 +00:00
|
|
|
err8:
|
2010-12-08 19:09:25 +00:00
|
|
|
iptablesRemoveForwardRejectIn(driver->iptables, AF_INET, network->def->bridge);
|
2010-12-10 21:04:37 +00:00
|
|
|
err7:
|
2010-12-08 19:09:25 +00:00
|
|
|
iptablesRemoveForwardRejectOut(driver->iptables, AF_INET, network->def->bridge);
|
2010-12-10 21:04:37 +00:00
|
|
|
err6:
|
|
|
|
if (ipv4def && ipv4def->tftproot) {
|
2010-12-08 19:09:25 +00:00
|
|
|
iptablesRemoveUdpInput(driver->iptables, AF_INET, network->def->bridge, 69);
|
2010-06-19 18:08:26 +00:00
|
|
|
}
|
2010-12-10 21:04:37 +00:00
|
|
|
err5:
|
2010-12-08 19:09:25 +00:00
|
|
|
iptablesRemoveUdpInput(driver->iptables, AF_INET, network->def->bridge, 53);
|
2010-12-10 21:04:37 +00:00
|
|
|
err4:
|
2010-12-08 19:09:25 +00:00
|
|
|
iptablesRemoveTcpInput(driver->iptables, AF_INET, network->def->bridge, 53);
|
2010-12-10 21:04:37 +00:00
|
|
|
err3:
|
2010-12-08 19:09:25 +00:00
|
|
|
iptablesRemoveUdpInput(driver->iptables, AF_INET, network->def->bridge, 67);
|
2010-12-10 21:04:37 +00:00
|
|
|
err2:
|
2010-12-08 19:09:25 +00:00
|
|
|
iptablesRemoveTcpInput(driver->iptables, AF_INET, network->def->bridge, 67);
|
2010-12-10 21:04:37 +00:00
|
|
|
err1:
|
2010-12-15 06:49:29 +00:00
|
|
|
return -1;
|
2008-10-10 13:57:13 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
2010-12-10 21:04:37 +00:00
|
|
|
networkRemoveGeneralIptablesRules(struct network_driver *driver,
|
|
|
|
virNetworkObjPtr network)
|
|
|
|
{
|
|
|
|
int ii;
|
|
|
|
virNetworkIpDefPtr ipv4def;
|
2010-11-17 18:36:19 +00:00
|
|
|
|
2010-12-16 20:50:01 +00:00
|
|
|
networkRemoveGeneralIp6tablesRules(driver, network);
|
|
|
|
|
2010-12-10 21:04:37 +00:00
|
|
|
for (ii = 0;
|
|
|
|
(ipv4def = virNetworkDefGetIpByIndex(network->def, AF_INET, ii));
|
|
|
|
ii++) {
|
|
|
|
if (ipv4def->nranges || ipv4def->nhosts || ipv4def->tftproot)
|
|
|
|
break;
|
2010-07-13 02:59:58 +00:00
|
|
|
}
|
2010-11-30 19:35:58 +00:00
|
|
|
|
2010-12-08 19:09:25 +00:00
|
|
|
iptablesRemoveForwardAllowCross(driver->iptables, AF_INET, network->def->bridge);
|
|
|
|
iptablesRemoveForwardRejectIn(driver->iptables, AF_INET, network->def->bridge);
|
|
|
|
iptablesRemoveForwardRejectOut(driver->iptables, AF_INET, network->def->bridge);
|
2010-12-10 21:04:37 +00:00
|
|
|
if (ipv4def && ipv4def->tftproot) {
|
2010-12-08 19:09:25 +00:00
|
|
|
iptablesRemoveUdpInput(driver->iptables, AF_INET, network->def->bridge, 69);
|
2010-12-10 21:04:37 +00:00
|
|
|
}
|
2010-12-08 19:09:25 +00:00
|
|
|
iptablesRemoveUdpInput(driver->iptables, AF_INET, network->def->bridge, 53);
|
|
|
|
iptablesRemoveTcpInput(driver->iptables, AF_INET, network->def->bridge, 53);
|
2010-12-10 21:04:37 +00:00
|
|
|
if (ipv4def && (ipv4def->nranges || ipv4def->nhosts)) {
|
|
|
|
iptablesRemoveOutputFixUdpChecksum(driver->iptables,
|
|
|
|
network->def->bridge, 68);
|
|
|
|
}
|
2010-12-08 19:09:25 +00:00
|
|
|
iptablesRemoveUdpInput(driver->iptables, AF_INET, network->def->bridge, 67);
|
|
|
|
iptablesRemoveTcpInput(driver->iptables, AF_INET, network->def->bridge, 67);
|
2008-10-10 13:57:13 +00:00
|
|
|
}
|
|
|
|
|
2010-12-10 21:04:37 +00:00
|
|
|
static int
|
|
|
|
networkAddIpSpecificIptablesRules(struct network_driver *driver,
|
|
|
|
virNetworkObjPtr network,
|
|
|
|
virNetworkIpDefPtr ipdef)
|
|
|
|
{
|
2010-12-16 20:50:01 +00:00
|
|
|
/* NB: in the case of IPv6, routing rules are added when the
|
|
|
|
* forward mode is NAT. This is because IPv6 has no NAT.
|
|
|
|
*/
|
2010-12-10 21:04:37 +00:00
|
|
|
|
2010-12-16 20:50:01 +00:00
|
|
|
if (network->def->forwardType == VIR_NETWORK_FORWARD_NAT) {
|
Santize naming of socket address APIs
The socket address APIs in src/util/network.h either take the
form virSocketAddrXXX, virSocketXXX or virSocketXXXAddr.
Sanitize this so everything is virSocketAddrXXXX, and ensure
that the virSocketAddr parameter is always the first one.
* src/util/network.c, src/util/network.h: Santize socket
address API naming
* src/conf/domain_conf.c, src/conf/network_conf.c,
src/conf/nwfilter_conf.c, src/network/bridge_driver.c,
src/nwfilter/nwfilter_ebiptables_driver.c,
src/nwfilter/nwfilter_learnipaddr.c,
src/qemu/qemu_command.c, src/rpc/virnetsocket.c,
src/util/dnsmasq.c, src/util/iptables.c,
src/util/virnetdev.c, src/vbox/vbox_tmpl.c: Update for
API renaming
2011-11-02 14:06:59 +00:00
|
|
|
if (VIR_SOCKET_ADDR_IS_FAMILY(&ipdef->address, AF_INET))
|
2010-12-16 20:50:01 +00:00
|
|
|
return networkAddMasqueradingIptablesRules(driver, network, ipdef);
|
Santize naming of socket address APIs
The socket address APIs in src/util/network.h either take the
form virSocketAddrXXX, virSocketXXX or virSocketXXXAddr.
Sanitize this so everything is virSocketAddrXXXX, and ensure
that the virSocketAddr parameter is always the first one.
* src/util/network.c, src/util/network.h: Santize socket
address API naming
* src/conf/domain_conf.c, src/conf/network_conf.c,
src/conf/nwfilter_conf.c, src/network/bridge_driver.c,
src/nwfilter/nwfilter_ebiptables_driver.c,
src/nwfilter/nwfilter_learnipaddr.c,
src/qemu/qemu_command.c, src/rpc/virnetsocket.c,
src/util/dnsmasq.c, src/util/iptables.c,
src/util/virnetdev.c, src/vbox/vbox_tmpl.c: Update for
API renaming
2011-11-02 14:06:59 +00:00
|
|
|
else if (VIR_SOCKET_ADDR_IS_FAMILY(&ipdef->address, AF_INET6))
|
2010-12-16 20:50:01 +00:00
|
|
|
return networkAddRoutingIptablesRules(driver, network, ipdef);
|
|
|
|
} else if (network->def->forwardType == VIR_NETWORK_FORWARD_ROUTE) {
|
|
|
|
return networkAddRoutingIptablesRules(driver, network, ipdef);
|
|
|
|
}
|
2010-12-10 21:04:37 +00:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
|
|
|
networkRemoveIpSpecificIptablesRules(struct network_driver *driver,
|
|
|
|
virNetworkObjPtr network,
|
|
|
|
virNetworkIpDefPtr ipdef)
|
|
|
|
{
|
2010-12-16 20:50:01 +00:00
|
|
|
if (network->def->forwardType == VIR_NETWORK_FORWARD_NAT) {
|
Santize naming of socket address APIs
The socket address APIs in src/util/network.h either take the
form virSocketAddrXXX, virSocketXXX or virSocketXXXAddr.
Sanitize this so everything is virSocketAddrXXXX, and ensure
that the virSocketAddr parameter is always the first one.
* src/util/network.c, src/util/network.h: Santize socket
address API naming
* src/conf/domain_conf.c, src/conf/network_conf.c,
src/conf/nwfilter_conf.c, src/network/bridge_driver.c,
src/nwfilter/nwfilter_ebiptables_driver.c,
src/nwfilter/nwfilter_learnipaddr.c,
src/qemu/qemu_command.c, src/rpc/virnetsocket.c,
src/util/dnsmasq.c, src/util/iptables.c,
src/util/virnetdev.c, src/vbox/vbox_tmpl.c: Update for
API renaming
2011-11-02 14:06:59 +00:00
|
|
|
if (VIR_SOCKET_ADDR_IS_FAMILY(&ipdef->address, AF_INET))
|
2010-12-16 20:50:01 +00:00
|
|
|
networkRemoveMasqueradingIptablesRules(driver, network, ipdef);
|
Santize naming of socket address APIs
The socket address APIs in src/util/network.h either take the
form virSocketAddrXXX, virSocketXXX or virSocketXXXAddr.
Sanitize this so everything is virSocketAddrXXXX, and ensure
that the virSocketAddr parameter is always the first one.
* src/util/network.c, src/util/network.h: Santize socket
address API naming
* src/conf/domain_conf.c, src/conf/network_conf.c,
src/conf/nwfilter_conf.c, src/network/bridge_driver.c,
src/nwfilter/nwfilter_ebiptables_driver.c,
src/nwfilter/nwfilter_learnipaddr.c,
src/qemu/qemu_command.c, src/rpc/virnetsocket.c,
src/util/dnsmasq.c, src/util/iptables.c,
src/util/virnetdev.c, src/vbox/vbox_tmpl.c: Update for
API renaming
2011-11-02 14:06:59 +00:00
|
|
|
else if (VIR_SOCKET_ADDR_IS_FAMILY(&ipdef->address, AF_INET6))
|
2010-12-16 20:50:01 +00:00
|
|
|
networkRemoveRoutingIptablesRules(driver, network, ipdef);
|
|
|
|
} else if (network->def->forwardType == VIR_NETWORK_FORWARD_ROUTE) {
|
2010-12-10 21:04:37 +00:00
|
|
|
networkRemoveRoutingIptablesRules(driver, network, ipdef);
|
2010-12-16 20:50:01 +00:00
|
|
|
}
|
2010-12-10 21:04:37 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/* Add all rules for all ip addresses (and general rules) on a network */
|
|
|
|
static int
|
|
|
|
networkAddIptablesRules(struct network_driver *driver,
|
|
|
|
virNetworkObjPtr network)
|
|
|
|
{
|
|
|
|
int ii;
|
|
|
|
virNetworkIpDefPtr ipdef;
|
|
|
|
|
|
|
|
/* Add "once per network" rules */
|
|
|
|
if (networkAddGeneralIptablesRules(driver, network) < 0)
|
|
|
|
return -1;
|
|
|
|
|
|
|
|
for (ii = 0;
|
|
|
|
(ipdef = virNetworkDefGetIpByIndex(network->def, AF_UNSPEC, ii));
|
|
|
|
ii++) {
|
|
|
|
/* Add address-specific iptables rules */
|
|
|
|
if (networkAddIpSpecificIptablesRules(driver, network, ipdef) < 0) {
|
|
|
|
goto err;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
err:
|
|
|
|
/* The final failed call to networkAddIpSpecificIptablesRules will
|
|
|
|
* have removed any rules it created, but we need to remove those
|
|
|
|
* added for previous IP addresses.
|
|
|
|
*/
|
|
|
|
while ((--ii >= 0) &&
|
|
|
|
(ipdef = virNetworkDefGetIpByIndex(network->def, AF_UNSPEC, ii))) {
|
|
|
|
networkRemoveIpSpecificIptablesRules(driver, network, ipdef);
|
|
|
|
}
|
|
|
|
networkRemoveGeneralIptablesRules(driver, network);
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Remove all rules for all ip addresses (and general rules) on a network */
|
|
|
|
static void
|
|
|
|
networkRemoveIptablesRules(struct network_driver *driver,
|
|
|
|
virNetworkObjPtr network)
|
|
|
|
{
|
|
|
|
int ii;
|
|
|
|
virNetworkIpDefPtr ipdef;
|
|
|
|
|
|
|
|
for (ii = 0;
|
|
|
|
(ipdef = virNetworkDefGetIpByIndex(network->def, AF_UNSPEC, ii));
|
|
|
|
ii++) {
|
|
|
|
networkRemoveIpSpecificIptablesRules(driver, network, ipdef);
|
|
|
|
}
|
|
|
|
networkRemoveGeneralIptablesRules(driver, network);
|
|
|
|
}
|
|
|
|
|
2009-12-10 11:27:17 +00:00
|
|
|
static void
|
|
|
|
networkReloadIptablesRules(struct network_driver *driver)
|
|
|
|
{
|
|
|
|
unsigned int i;
|
|
|
|
|
maint: omit translation for all VIR_INFO
We were 31/73 on whether to translate; since less than 50% translated
and since VIR_INFO is less than VIR_WARN which also doesn't translate,
this makes sense.
* cfg.mk (sc_prohibit_gettext_markup): Add VIR_INFO, since it
falls between WARN and DEBUG.
* daemon/libvirtd.c (qemudDispatchSignalEvent, remoteCheckAccess)
(qemudDispatchServer): Adjust offenders.
* daemon/remote.c (remoteDispatchAuthPolkit): Likewise.
* src/network/bridge_driver.c (networkReloadIptablesRules)
(networkStartNetworkDaemon, networkShutdownNetworkDaemon)
(networkCreate, networkDefine, networkUndefine): Likewise.
* src/qemu/qemu_driver.c (qemudDomainDefine)
(qemudDomainUndefine): Likewise.
* src/storage/storage_driver.c (storagePoolCreate)
(storagePoolDefine, storagePoolUndefine, storagePoolStart)
(storagePoolDestroy, storagePoolDelete, storageVolumeCreateXML)
(storageVolumeCreateXMLFrom, storageVolumeDelete): Likewise.
* src/util/bridge.c (brProbeVnetHdr): Likewise.
* po/POTFILES.in: Drop src/util/bridge.c.
2011-05-11 15:08:44 +00:00
|
|
|
VIR_INFO("Reloading iptables rules");
|
2009-12-10 11:27:17 +00:00
|
|
|
|
|
|
|
for (i = 0 ; i < driver->networks.count ; i++) {
|
2011-12-06 20:13:50 +00:00
|
|
|
virNetworkObjPtr network = driver->networks.objs[i];
|
|
|
|
|
|
|
|
virNetworkObjLock(network);
|
|
|
|
if (virNetworkObjIsActive(network) &&
|
|
|
|
((network->def->forwardType == VIR_NETWORK_FORWARD_NONE) ||
|
|
|
|
(network->def->forwardType == VIR_NETWORK_FORWARD_NAT) ||
|
|
|
|
(network->def->forwardType == VIR_NETWORK_FORWARD_ROUTE))) {
|
|
|
|
/* Only the three L3 network types that are configured by libvirt
|
|
|
|
* need to have iptables rules reloaded.
|
|
|
|
*/
|
|
|
|
networkRemoveIptablesRules(driver, network);
|
|
|
|
if (networkAddIptablesRules(driver, network) < 0) {
|
2010-12-10 21:04:37 +00:00
|
|
|
/* failed to add but already logged */
|
|
|
|
}
|
2009-12-10 11:27:17 +00:00
|
|
|
}
|
2011-12-06 20:13:50 +00:00
|
|
|
virNetworkObjUnlock(network);
|
2009-12-10 11:27:17 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2009-02-22 11:19:54 +00:00
|
|
|
/* Enable IP Forwarding. Return 0 for success, -1 for failure. */
|
2008-10-10 13:57:13 +00:00
|
|
|
static int
|
2010-12-20 06:14:11 +00:00
|
|
|
networkEnableIpForwarding(bool enableIPv4, bool enableIPv6)
|
2008-10-10 13:57:13 +00:00
|
|
|
{
|
2010-12-20 06:14:11 +00:00
|
|
|
int ret = 0;
|
|
|
|
if (enableIPv4)
|
|
|
|
ret = virFileWriteStr("/proc/sys/net/ipv4/ip_forward", "1\n", 0);
|
|
|
|
if (enableIPv6 && ret == 0)
|
|
|
|
ret = virFileWriteStr("/proc/sys/net/ipv6/conf/all/forwarding", "1\n", 0);
|
|
|
|
return ret;
|
2008-10-10 13:57:13 +00:00
|
|
|
}
|
|
|
|
|
2009-07-30 15:34:56 +00:00
|
|
|
#define SYSCTL_PATH "/proc/sys"
|
|
|
|
|
2010-12-16 20:50:01 +00:00
|
|
|
static int
|
|
|
|
networkSetIPv6Sysctls(virNetworkObjPtr network)
|
2009-07-30 15:34:56 +00:00
|
|
|
{
|
|
|
|
char *field = NULL;
|
|
|
|
int ret = -1;
|
|
|
|
|
2010-12-16 20:50:01 +00:00
|
|
|
if (!virNetworkDefGetIpByIndex(network->def, AF_INET6, 0)) {
|
|
|
|
/* Only set disable_ipv6 if there are no ipv6 addresses defined for
|
|
|
|
* the network.
|
|
|
|
*/
|
|
|
|
if (virAsprintf(&field, SYSCTL_PATH "/net/ipv6/conf/%s/disable_ipv6",
|
|
|
|
network->def->bridge) < 0) {
|
|
|
|
virReportOOMError();
|
|
|
|
goto cleanup;
|
|
|
|
}
|
2009-07-30 15:34:56 +00:00
|
|
|
|
2010-12-16 20:50:01 +00:00
|
|
|
if (access(field, W_OK) < 0 && errno == ENOENT) {
|
|
|
|
VIR_DEBUG("ipv6 appears to already be disabled on %s",
|
|
|
|
network->def->bridge);
|
|
|
|
ret = 0;
|
|
|
|
goto cleanup;
|
|
|
|
}
|
2009-08-10 10:16:37 +00:00
|
|
|
|
2010-12-16 20:50:01 +00:00
|
|
|
if (virFileWriteStr(field, "1", 0) < 0) {
|
|
|
|
virReportSystemError(errno,
|
|
|
|
_("cannot write to %s to disable IPv6 on bridge %s"),
|
|
|
|
field, network->def->bridge);
|
|
|
|
goto cleanup;
|
|
|
|
}
|
|
|
|
VIR_FREE(field);
|
2009-07-30 15:34:56 +00:00
|
|
|
}
|
|
|
|
|
2010-12-16 20:50:01 +00:00
|
|
|
/* The rest of the ipv6 sysctl tunables should always be set,
|
|
|
|
* whether or not we're using ipv6 on this bridge.
|
|
|
|
*/
|
|
|
|
|
|
|
|
/* Prevent guests from hijacking the host network by sending out
|
|
|
|
* their own router advertisements.
|
|
|
|
*/
|
|
|
|
if (virAsprintf(&field, SYSCTL_PATH "/net/ipv6/conf/%s/accept_ra",
|
|
|
|
network->def->bridge) < 0) {
|
2010-02-04 18:19:08 +00:00
|
|
|
virReportOOMError();
|
2009-07-30 15:34:56 +00:00
|
|
|
goto cleanup;
|
|
|
|
}
|
|
|
|
|
2010-12-03 09:47:08 +00:00
|
|
|
if (virFileWriteStr(field, "0", 0) < 0) {
|
2010-02-04 20:02:58 +00:00
|
|
|
virReportSystemError(errno,
|
2009-07-30 15:34:56 +00:00
|
|
|
_("cannot disable %s"), field);
|
|
|
|
goto cleanup;
|
|
|
|
}
|
|
|
|
VIR_FREE(field);
|
|
|
|
|
2010-12-16 20:50:01 +00:00
|
|
|
/* All interfaces used as a gateway (which is what this is, by
|
|
|
|
* definition), must always have autoconf=0.
|
|
|
|
*/
|
|
|
|
if (virAsprintf(&field, SYSCTL_PATH "/net/ipv6/conf/%s/autoconf",
|
|
|
|
network->def->bridge) < 0) {
|
2010-02-04 18:19:08 +00:00
|
|
|
virReportOOMError();
|
2009-07-30 15:34:56 +00:00
|
|
|
goto cleanup;
|
|
|
|
}
|
|
|
|
|
2011-10-03 09:58:55 +00:00
|
|
|
if (virFileWriteStr(field, "0", 0) < 0) {
|
2010-02-04 20:02:58 +00:00
|
|
|
virReportSystemError(errno,
|
2011-10-03 09:58:55 +00:00
|
|
|
_("cannot disable %s"), field);
|
2009-07-30 15:34:56 +00:00
|
|
|
goto cleanup;
|
|
|
|
}
|
|
|
|
|
|
|
|
ret = 0;
|
|
|
|
cleanup:
|
|
|
|
VIR_FREE(field);
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2010-05-20 23:31:16 +00:00
|
|
|
#define PROC_NET_ROUTE "/proc/net/route"
|
|
|
|
|
|
|
|
/* XXX: This function can be a lot more exhaustive, there are certainly
|
|
|
|
* other scenarios where we can ruin host network connectivity.
|
|
|
|
* XXX: Using a proper library is preferred over parsing /proc
|
|
|
|
*/
|
2010-12-10 21:04:37 +00:00
|
|
|
static int
|
|
|
|
networkCheckRouteCollision(virNetworkObjPtr network)
|
2010-05-20 23:31:16 +00:00
|
|
|
{
|
2010-12-10 21:04:37 +00:00
|
|
|
int ret = 0, len;
|
2010-05-20 23:31:16 +00:00
|
|
|
char *cur, *buf = NULL;
|
|
|
|
enum {MAX_ROUTE_SIZE = 1024*64};
|
|
|
|
|
|
|
|
/* Read whole routing table into memory */
|
|
|
|
if ((len = virFileReadAll(PROC_NET_ROUTE, MAX_ROUTE_SIZE, &buf)) < 0)
|
2010-12-10 21:04:37 +00:00
|
|
|
goto out;
|
2010-05-20 23:31:16 +00:00
|
|
|
|
|
|
|
/* Dropping the last character shouldn't hurt */
|
|
|
|
if (len > 0)
|
|
|
|
buf[len-1] = '\0';
|
|
|
|
|
|
|
|
VIR_DEBUG("%s output:\n%s", PROC_NET_ROUTE, buf);
|
|
|
|
|
|
|
|
if (!STRPREFIX (buf, "Iface"))
|
|
|
|
goto out;
|
|
|
|
|
|
|
|
/* First line is just headings, skip it */
|
|
|
|
cur = strchr(buf, '\n');
|
|
|
|
if (cur)
|
|
|
|
cur++;
|
|
|
|
|
|
|
|
while (cur) {
|
|
|
|
char iface[17], dest[128], mask[128];
|
|
|
|
unsigned int addr_val, mask_val;
|
2010-12-10 21:04:37 +00:00
|
|
|
virNetworkIpDefPtr ipdef;
|
|
|
|
int num, ii;
|
2010-05-20 23:31:16 +00:00
|
|
|
|
|
|
|
/* NUL-terminate the line, so sscanf doesn't go beyond a newline. */
|
|
|
|
char *nl = strchr(cur, '\n');
|
|
|
|
if (nl) {
|
|
|
|
*nl++ = '\0';
|
|
|
|
}
|
|
|
|
|
|
|
|
num = sscanf(cur, "%16s %127s %*s %*s %*s %*s %*s %127s",
|
|
|
|
iface, dest, mask);
|
|
|
|
cur = nl;
|
|
|
|
|
|
|
|
if (num != 3) {
|
|
|
|
VIR_DEBUG("Failed to parse %s", PROC_NET_ROUTE);
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (virStrToLong_ui(dest, NULL, 16, &addr_val) < 0) {
|
|
|
|
VIR_DEBUG("Failed to convert network address %s to uint", dest);
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (virStrToLong_ui(mask, NULL, 16, &mask_val) < 0) {
|
|
|
|
VIR_DEBUG("Failed to convert network mask %s to uint", mask);
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
|
|
|
addr_val &= mask_val;
|
|
|
|
|
2010-12-10 21:04:37 +00:00
|
|
|
for (ii = 0;
|
|
|
|
(ipdef = virNetworkDefGetIpByIndex(network->def, AF_INET, ii));
|
|
|
|
ii++) {
|
|
|
|
|
|
|
|
unsigned int net_dest;
|
|
|
|
virSocketAddr netmask;
|
|
|
|
|
|
|
|
if (virNetworkIpDefNetmask(ipdef, &netmask) < 0) {
|
|
|
|
VIR_WARN("Failed to get netmask of '%s'",
|
|
|
|
network->def->bridge);
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
|
|
|
net_dest = (ipdef->address.data.inet4.sin_addr.s_addr &
|
|
|
|
netmask.data.inet4.sin_addr.s_addr);
|
|
|
|
|
|
|
|
if ((net_dest == addr_val) &&
|
|
|
|
(netmask.data.inet4.sin_addr.s_addr == mask_val)) {
|
2012-07-18 11:50:10 +00:00
|
|
|
virReportError(VIR_ERR_INTERNAL_ERROR,
|
|
|
|
_("Network is already in use by interface %s"),
|
|
|
|
iface);
|
2010-12-10 21:04:37 +00:00
|
|
|
ret = -1;
|
|
|
|
goto out;
|
|
|
|
}
|
2010-05-20 23:31:16 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
out:
|
|
|
|
VIR_FREE(buf);
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2010-12-10 21:04:37 +00:00
|
|
|
static int
|
Remove 'brControl' object
The bridge management APIs in src/util/bridge.c require a brControl
object to be passed around. This holds the file descriptor for the
control socket. This extra object complicates use of the API for
only a minor efficiency gain, which is in turn entirely offset by
the need to fork/exec the brctl command for STP configuration.
This patch removes the 'brControl' object entirely, instead opening
the control socket & closing it again within the scope of each method.
The parameter names for the APIs are also made to consistently use
'brname' for bridge device name, and 'ifname' for an interface
device name. Finally annotations are added for non-NULL parameters
and return check validation
* src/util/bridge.c, src/util/bridge.h: Remove brControl object
and update API parameter names & annotations.
* src/lxc/lxc_driver.c, src/network/bridge_driver.c,
src/uml/uml_conf.h, src/uml/uml_conf.c, src/uml/uml_driver.c,
src/qemu/qemu_command.c, src/qemu/qemu_conf.h,
src/qemu/qemu_driver.c: Remove reference to 'brControl' object
2011-11-02 10:56:38 +00:00
|
|
|
networkAddAddrToBridge(virNetworkObjPtr network,
|
2010-12-10 21:04:37 +00:00
|
|
|
virNetworkIpDefPtr ipdef)
|
2010-02-10 10:22:52 +00:00
|
|
|
{
|
2010-12-10 21:04:37 +00:00
|
|
|
int prefix = virNetworkIpDefPrefix(ipdef);
|
|
|
|
|
|
|
|
if (prefix < 0) {
|
2012-07-18 11:50:10 +00:00
|
|
|
virReportError(VIR_ERR_INTERNAL_ERROR,
|
|
|
|
_("bridge '%s' has an invalid netmask or IP address"),
|
|
|
|
network->def->bridge);
|
2010-12-10 21:04:37 +00:00
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
|
2011-11-02 12:35:18 +00:00
|
|
|
if (virNetDevSetIPv4Address(network->def->bridge,
|
|
|
|
&ipdef->address, prefix) < 0)
|
2010-12-10 21:04:37 +00:00
|
|
|
return -1;
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int
|
network: separate Start/Shutdown functions for new network types
Previously all networks were composed of bridge devices created and
managed by libvirt, and the same operations needed to be done for all
of them when they were started and stopped (create and start the
bridge device, configure its MAC address and IP address, add iptables
rules). The new network types are (for now at least) managed outside
of libvirt, and the network object is used only to contain information
about the network, which is then used as each individual guest
connects itself.
This means that when starting/stopping one of these new networks, we
really want to do nothing, aside from marking the network as
active/inactive.
This has been setup as toplevel Start/Shutdown functions that do the
small bit of common stuff, then have a switch statement to execute
network type-specific start/shutdown code, then do a bit more common
code. The type-specific functions called for the new host bridge and
macvtap based types are currently empty.
In the future these functions may actually do something, and we will
surely add more functions that are similarly patterned. Once
everything has settled, we can make a table of "sub-driver" function
pointers for each network type, and store a pointer to that table in
the network object, then we can replace the switch statements with
calls to functions in the table.
The final step in this will be to add a new table (and corresponding
new functions) for new network types as they are added.
2011-06-30 21:05:07 +00:00
|
|
|
networkStartNetworkVirtual(struct network_driver *driver,
|
2010-12-10 21:04:37 +00:00
|
|
|
virNetworkObjPtr network)
|
|
|
|
{
|
2011-11-02 12:00:28 +00:00
|
|
|
int ii;
|
2010-12-16 20:50:01 +00:00
|
|
|
bool v4present = false, v6present = false;
|
2010-12-10 21:04:37 +00:00
|
|
|
virErrorPtr save_err = NULL;
|
|
|
|
virNetworkIpDefPtr ipdef;
|
2011-04-14 12:03:46 +00:00
|
|
|
char *macTapIfName = NULL;
|
2008-10-10 13:57:13 +00:00
|
|
|
|
2010-12-10 21:04:37 +00:00
|
|
|
/* Check to see if any network IP collides with an existing route */
|
|
|
|
if (networkCheckRouteCollision(network) < 0)
|
2010-05-20 23:31:16 +00:00
|
|
|
return -1;
|
|
|
|
|
2010-12-10 21:04:37 +00:00
|
|
|
/* Create and configure the bridge device */
|
2011-11-02 12:35:18 +00:00
|
|
|
if (virNetDevBridgeCreate(network->def->bridge) < 0)
|
2008-10-10 13:57:13 +00:00
|
|
|
return -1;
|
|
|
|
|
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
|
|
|
if (network->def->mac_specified) {
|
|
|
|
/* To set a mac for the bridge, we need to define a dummy tap
|
|
|
|
* device, set its mac, then attach it to the bridge. As long
|
|
|
|
* as its mac address is lower than any other interface that
|
|
|
|
* gets attached, the bridge will always maintain this mac
|
|
|
|
* address.
|
|
|
|
*/
|
|
|
|
macTapIfName = networkBridgeDummyNicName(network->def->bridge);
|
|
|
|
if (!macTapIfName) {
|
|
|
|
virReportOOMError();
|
|
|
|
goto err0;
|
|
|
|
}
|
2011-11-02 12:35:18 +00:00
|
|
|
if (virNetDevTapCreateInBridgePort(network->def->bridge,
|
2012-07-17 12:07:59 +00:00
|
|
|
&macTapIfName, &network->def->mac,
|
2012-03-07 07:15:36 +00:00
|
|
|
NULL, NULL, NULL,
|
2012-03-01 20:35:30 +00:00
|
|
|
VIR_NETDEV_TAP_CREATE_USE_MAC_FOR_BRIDGE) < 0) {
|
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
|
|
|
VIR_FREE(macTapIfName);
|
|
|
|
goto err0;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2010-12-10 21:04:37 +00:00
|
|
|
/* Set bridge options */
|
2011-11-02 12:35:18 +00:00
|
|
|
if (virNetDevBridgeSetSTPDelay(network->def->bridge,
|
2011-11-02 12:00:28 +00:00
|
|
|
network->def->delay) < 0)
|
2010-12-10 21:04:37 +00:00
|
|
|
goto err1;
|
2008-10-10 13:57:13 +00:00
|
|
|
|
2011-11-02 12:35:18 +00:00
|
|
|
if (virNetDevBridgeSetSTP(network->def->bridge,
|
2011-11-02 12:54:45 +00:00
|
|
|
network->def->stp ? true : false) < 0)
|
2010-12-10 21:04:37 +00:00
|
|
|
goto err1;
|
2010-11-30 19:35:58 +00:00
|
|
|
|
2010-12-16 20:50:01 +00:00
|
|
|
/* Disable IPv6 on the bridge if there are no IPv6 addresses
|
|
|
|
* defined, and set other IPv6 sysctl tunables appropriately.
|
|
|
|
*/
|
|
|
|
if (networkSetIPv6Sysctls(network) < 0)
|
2010-12-10 21:04:37 +00:00
|
|
|
goto err1;
|
2010-12-14 17:14:39 +00:00
|
|
|
|
2010-12-10 21:04:37 +00:00
|
|
|
/* Add "once per network" rules */
|
|
|
|
if (networkAddIptablesRules(driver, network) < 0)
|
|
|
|
goto err1;
|
|
|
|
|
|
|
|
for (ii = 0;
|
|
|
|
(ipdef = virNetworkDefGetIpByIndex(network->def, AF_UNSPEC, ii));
|
|
|
|
ii++) {
|
Santize naming of socket address APIs
The socket address APIs in src/util/network.h either take the
form virSocketAddrXXX, virSocketXXX or virSocketXXXAddr.
Sanitize this so everything is virSocketAddrXXXX, and ensure
that the virSocketAddr parameter is always the first one.
* src/util/network.c, src/util/network.h: Santize socket
address API naming
* src/conf/domain_conf.c, src/conf/network_conf.c,
src/conf/nwfilter_conf.c, src/network/bridge_driver.c,
src/nwfilter/nwfilter_ebiptables_driver.c,
src/nwfilter/nwfilter_learnipaddr.c,
src/qemu/qemu_command.c, src/rpc/virnetsocket.c,
src/util/dnsmasq.c, src/util/iptables.c,
src/util/virnetdev.c, src/vbox/vbox_tmpl.c: Update for
API renaming
2011-11-02 14:06:59 +00:00
|
|
|
if (VIR_SOCKET_ADDR_IS_FAMILY(&ipdef->address, AF_INET))
|
2010-12-10 21:04:37 +00:00
|
|
|
v4present = true;
|
Santize naming of socket address APIs
The socket address APIs in src/util/network.h either take the
form virSocketAddrXXX, virSocketXXX or virSocketXXXAddr.
Sanitize this so everything is virSocketAddrXXXX, and ensure
that the virSocketAddr parameter is always the first one.
* src/util/network.c, src/util/network.h: Santize socket
address API naming
* src/conf/domain_conf.c, src/conf/network_conf.c,
src/conf/nwfilter_conf.c, src/network/bridge_driver.c,
src/nwfilter/nwfilter_ebiptables_driver.c,
src/nwfilter/nwfilter_learnipaddr.c,
src/qemu/qemu_command.c, src/rpc/virnetsocket.c,
src/util/dnsmasq.c, src/util/iptables.c,
src/util/virnetdev.c, src/vbox/vbox_tmpl.c: Update for
API renaming
2011-11-02 14:06:59 +00:00
|
|
|
if (VIR_SOCKET_ADDR_IS_FAMILY(&ipdef->address, AF_INET6))
|
2010-12-16 20:50:01 +00:00
|
|
|
v6present = true;
|
2010-12-14 17:14:39 +00:00
|
|
|
|
2010-12-10 21:04:37 +00:00
|
|
|
/* Add the IP address/netmask to the bridge */
|
Remove 'brControl' object
The bridge management APIs in src/util/bridge.c require a brControl
object to be passed around. This holds the file descriptor for the
control socket. This extra object complicates use of the API for
only a minor efficiency gain, which is in turn entirely offset by
the need to fork/exec the brctl command for STP configuration.
This patch removes the 'brControl' object entirely, instead opening
the control socket & closing it again within the scope of each method.
The parameter names for the APIs are also made to consistently use
'brname' for bridge device name, and 'ifname' for an interface
device name. Finally annotations are added for non-NULL parameters
and return check validation
* src/util/bridge.c, src/util/bridge.h: Remove brControl object
and update API parameter names & annotations.
* src/lxc/lxc_driver.c, src/network/bridge_driver.c,
src/uml/uml_conf.h, src/uml/uml_conf.c, src/uml/uml_driver.c,
src/qemu/qemu_command.c, src/qemu/qemu_conf.h,
src/qemu/qemu_driver.c: Remove reference to 'brControl' object
2011-11-02 10:56:38 +00:00
|
|
|
if (networkAddAddrToBridge(network, ipdef) < 0) {
|
2010-12-10 21:04:37 +00:00
|
|
|
goto err2;
|
2010-12-14 17:14:39 +00:00
|
|
|
}
|
2008-10-10 13:57:13 +00:00
|
|
|
}
|
|
|
|
|
2010-12-10 21:04:37 +00:00
|
|
|
/* Bring up the bridge interface */
|
2011-11-02 12:35:18 +00:00
|
|
|
if (virNetDevSetOnline(network->def->bridge, 1) < 0)
|
2010-12-10 21:04:37 +00:00
|
|
|
goto err2;
|
2008-10-10 13:57:13 +00:00
|
|
|
|
2010-12-10 21:04:37 +00:00
|
|
|
/* If forwardType != NONE, turn on global IP forwarding */
|
2008-10-10 13:57:13 +00:00
|
|
|
if (network->def->forwardType != VIR_NETWORK_FORWARD_NONE &&
|
2010-12-20 06:14:11 +00:00
|
|
|
networkEnableIpForwarding(v4present, v6present) < 0) {
|
2010-02-04 20:02:58 +00:00
|
|
|
virReportSystemError(errno, "%s",
|
2009-01-20 17:13:33 +00:00
|
|
|
_("failed to enable IP forwarding"));
|
2010-12-10 21:04:37 +00:00
|
|
|
goto err3;
|
2008-10-10 13:57:13 +00:00
|
|
|
}
|
|
|
|
|
2010-12-10 21:04:37 +00:00
|
|
|
|
network driver: Start dnsmasq even if no dhcp ranges/hosts are specified.
This fixes a regression introduced in commit ad48df, and reported on
the libvirt-users list:
https://www.redhat.com/archives/libvirt-users/2011-March/msg00018.html
The problem in that commit was that we began searching a list of ip
address definitions (rather than just having one) to look for a dhcp
range or static host; when we didn't find any, our pointer (ipdef) was
left at NULL, and when ipdef was NULL, we returned without starting up
dnsmasq.
Previously dnsmasq was started even without any dhcp ranges or static
entries, because it's still useful for DNS services.
Another problem I noticed while investigating was that, if there are
IPv6 addresses, but no IPv4 addresses of any kind, we would jump out
at an ever higher level in the call chain.
This patch does the following:
1) networkBuildDnsmasqArgv() = all uses of ipdef are protected from
NULL dereference. (this patch doesn't change indentation, to make
review easier. The next patch will change just the
indentation). ipdef is intended to point to the first IPv4 address
with DHCP info (or the first IPv4 address if none of them have any
dhcp info).
2) networkStartDhcpDaemon() = if the loop looking for an ipdef with
DHCP info comes up empty, we then grab the first IPv4 def from the
list. Also, instead of returning if there are no IPv4 defs, we just
return if there are no IP defs at all (either v4 or v6). This way a
network that is IPv6-only will still get dnsmasq listening for DNS
queries.
3) in networkStartNetworkDaemon() - we will startup dhcp not just if there
are any IPv4 addresses, but also if there are any IPv6 addresses.
2011-03-11 16:47:58 +00:00
|
|
|
/* start dnsmasq if there are any IP addresses (v4 or v6) */
|
|
|
|
if ((v4present || v6present) && networkStartDhcpDaemon(network) < 0)
|
2010-12-10 21:04:37 +00:00
|
|
|
goto err3;
|
2008-10-10 13:57:13 +00:00
|
|
|
|
2010-12-20 06:14:11 +00:00
|
|
|
/* start radvd if there are any ipv6 addresses */
|
|
|
|
if (v6present && networkStartRadvd(network) < 0)
|
|
|
|
goto err4;
|
|
|
|
|
Adjust naming of network device bandwidth management APIs
Rename virBandwidth to virNetDevBandwidth, and virRate to
virNetDevBandwidthRate.
* src/util/network.c, src/util/network.h: Rename bandwidth
structs and APIs
* src/conf/domain_conf.c, src/conf/domain_conf.h,
src/conf/network_conf.c, src/conf/network_conf.h,
src/lxc/lxc_driver.c, src/network/bridge_driver.c,
src/qemu/qemu_command.c, src/util/macvtap.c,
src/util/macvtap.h, tools/virsh.c: Update for API changes.
2011-11-02 14:29:05 +00:00
|
|
|
if (virNetDevBandwidthSet(network->def->bridge, network->def->bandwidth) < 0) {
|
2012-07-18 11:50:10 +00:00
|
|
|
virReportError(VIR_ERR_INTERNAL_ERROR,
|
|
|
|
_("cannot set bandwidth limits on %s"),
|
|
|
|
network->def->bridge);
|
2011-07-22 14:07:27 +00:00
|
|
|
goto err5;
|
|
|
|
}
|
|
|
|
|
2011-04-14 12:03:46 +00:00
|
|
|
VIR_FREE(macTapIfName);
|
2008-10-10 13:57:13 +00:00
|
|
|
|
|
|
|
return 0;
|
|
|
|
|
2011-07-22 14:07:27 +00:00
|
|
|
err5:
|
Adjust naming of network device bandwidth management APIs
Rename virBandwidth to virNetDevBandwidth, and virRate to
virNetDevBandwidthRate.
* src/util/network.c, src/util/network.h: Rename bandwidth
structs and APIs
* src/conf/domain_conf.c, src/conf/domain_conf.h,
src/conf/network_conf.c, src/conf/network_conf.h,
src/lxc/lxc_driver.c, src/network/bridge_driver.c,
src/qemu/qemu_command.c, src/util/macvtap.c,
src/util/macvtap.h, tools/virsh.c: Update for API changes.
2011-11-02 14:29:05 +00:00
|
|
|
ignore_value(virNetDevBandwidthClear(network->def->bridge));
|
2011-07-22 14:07:27 +00:00
|
|
|
|
2010-12-10 21:04:37 +00:00
|
|
|
err4:
|
|
|
|
if (!save_err)
|
|
|
|
save_err = virSaveLastError();
|
|
|
|
|
2009-01-20 22:36:10 +00:00
|
|
|
if (network->dnsmasqPid > 0) {
|
|
|
|
kill(network->dnsmasqPid, SIGTERM);
|
|
|
|
network->dnsmasqPid = -1;
|
|
|
|
}
|
|
|
|
|
2010-12-10 21:04:37 +00:00
|
|
|
err3:
|
|
|
|
if (!save_err)
|
|
|
|
save_err = virSaveLastError();
|
2011-11-02 12:35:18 +00:00
|
|
|
ignore_value(virNetDevSetOnline(network->def->bridge, 0));
|
2008-10-10 13:57:13 +00:00
|
|
|
|
2010-12-10 21:04:37 +00:00
|
|
|
err2:
|
|
|
|
if (!save_err)
|
|
|
|
save_err = virSaveLastError();
|
|
|
|
networkRemoveIptablesRules(driver, network);
|
|
|
|
|
|
|
|
err1:
|
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
|
|
|
if (!save_err)
|
|
|
|
save_err = virSaveLastError();
|
|
|
|
|
2011-11-11 08:20:19 +00:00
|
|
|
if (macTapIfName) {
|
|
|
|
ignore_value(virNetDevTapDelete(macTapIfName));
|
|
|
|
VIR_FREE(macTapIfName);
|
|
|
|
}
|
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
|
|
|
|
|
|
|
err0:
|
2010-12-10 21:04:37 +00:00
|
|
|
if (!save_err)
|
|
|
|
save_err = virSaveLastError();
|
2011-11-02 12:35:18 +00:00
|
|
|
ignore_value(virNetDevBridgeDelete(network->def->bridge));
|
2008-10-10 13:57:13 +00:00
|
|
|
|
2010-12-10 21:04:37 +00:00
|
|
|
if (save_err) {
|
|
|
|
virSetError(save_err);
|
|
|
|
virFreeError(save_err);
|
|
|
|
}
|
2008-10-10 13:57:13 +00:00
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
|
network: separate Start/Shutdown functions for new network types
Previously all networks were composed of bridge devices created and
managed by libvirt, and the same operations needed to be done for all
of them when they were started and stopped (create and start the
bridge device, configure its MAC address and IP address, add iptables
rules). The new network types are (for now at least) managed outside
of libvirt, and the network object is used only to contain information
about the network, which is then used as each individual guest
connects itself.
This means that when starting/stopping one of these new networks, we
really want to do nothing, aside from marking the network as
active/inactive.
This has been setup as toplevel Start/Shutdown functions that do the
small bit of common stuff, then have a switch statement to execute
network type-specific start/shutdown code, then do a bit more common
code. The type-specific functions called for the new host bridge and
macvtap based types are currently empty.
In the future these functions may actually do something, and we will
surely add more functions that are similarly patterned. Once
everything has settled, we can make a table of "sub-driver" function
pointers for each network type, and store a pointer to that table in
the network object, then we can replace the switch statements with
calls to functions in the table.
The final step in this will be to add a new table (and corresponding
new functions) for new network types as they are added.
2011-06-30 21:05:07 +00:00
|
|
|
static int networkShutdownNetworkVirtual(struct network_driver *driver,
|
2010-02-10 10:22:52 +00:00
|
|
|
virNetworkObjPtr network)
|
|
|
|
{
|
Adjust naming of network device bandwidth management APIs
Rename virBandwidth to virNetDevBandwidth, and virRate to
virNetDevBandwidthRate.
* src/util/network.c, src/util/network.h: Rename bandwidth
structs and APIs
* src/conf/domain_conf.c, src/conf/domain_conf.h,
src/conf/network_conf.c, src/conf/network_conf.h,
src/lxc/lxc_driver.c, src/network/bridge_driver.c,
src/qemu/qemu_command.c, src/util/macvtap.c,
src/util/macvtap.h, tools/virsh.c: Update for API changes.
2011-11-02 14:29:05 +00:00
|
|
|
ignore_value(virNetDevBandwidthClear(network->def->bridge));
|
2011-07-22 14:07:27 +00:00
|
|
|
|
2010-12-20 06:14:11 +00:00
|
|
|
if (network->radvdPid > 0) {
|
|
|
|
char *radvdpidbase;
|
|
|
|
|
|
|
|
kill(network->radvdPid, SIGTERM);
|
|
|
|
/* attempt to delete the pidfile we created */
|
|
|
|
if (!(radvdpidbase = networkRadvdPidfileBasename(network->def->name))) {
|
|
|
|
virReportOOMError();
|
|
|
|
} else {
|
2011-08-05 13:13:12 +00:00
|
|
|
virPidFileDelete(NETWORK_PID_DIR, radvdpidbase);
|
2010-12-20 06:14:11 +00:00
|
|
|
VIR_FREE(radvdpidbase);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2008-10-10 13:57:13 +00:00
|
|
|
if (network->dnsmasqPid > 0)
|
|
|
|
kill(network->dnsmasqPid, SIGTERM);
|
|
|
|
|
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
|
|
|
if (network->def->mac_specified) {
|
network: separate Start/Shutdown functions for new network types
Previously all networks were composed of bridge devices created and
managed by libvirt, and the same operations needed to be done for all
of them when they were started and stopped (create and start the
bridge device, configure its MAC address and IP address, add iptables
rules). The new network types are (for now at least) managed outside
of libvirt, and the network object is used only to contain information
about the network, which is then used as each individual guest
connects itself.
This means that when starting/stopping one of these new networks, we
really want to do nothing, aside from marking the network as
active/inactive.
This has been setup as toplevel Start/Shutdown functions that do the
small bit of common stuff, then have a switch statement to execute
network type-specific start/shutdown code, then do a bit more common
code. The type-specific functions called for the new host bridge and
macvtap based types are currently empty.
In the future these functions may actually do something, and we will
surely add more functions that are similarly patterned. Once
everything has settled, we can make a table of "sub-driver" function
pointers for each network type, and store a pointer to that table in
the network object, then we can replace the switch statements with
calls to functions in the table.
The final step in this will be to add a new table (and corresponding
new functions) for new network types as they are added.
2011-06-30 21:05:07 +00:00
|
|
|
char *macTapIfName = networkBridgeDummyNicName(network->def->bridge);
|
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
|
|
|
if (!macTapIfName) {
|
|
|
|
virReportOOMError();
|
|
|
|
} else {
|
2011-11-02 12:35:18 +00:00
|
|
|
ignore_value(virNetDevTapDelete(macTapIfName));
|
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
|
|
|
VIR_FREE(macTapIfName);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2011-11-02 12:35:18 +00:00
|
|
|
ignore_value(virNetDevSetOnline(network->def->bridge, 0));
|
2008-10-10 13:57:13 +00:00
|
|
|
|
2010-12-10 21:04:37 +00:00
|
|
|
networkRemoveIptablesRules(driver, network);
|
|
|
|
|
2011-11-02 12:35:18 +00:00
|
|
|
ignore_value(virNetDevBridgeDelete(network->def->bridge));
|
2008-10-10 13:57:13 +00:00
|
|
|
|
2009-01-20 22:36:10 +00:00
|
|
|
/* See if its still alive and really really kill it */
|
2008-10-10 13:57:13 +00:00
|
|
|
if (network->dnsmasqPid > 0 &&
|
2009-01-20 22:36:10 +00:00
|
|
|
(kill(network->dnsmasqPid, 0) == 0))
|
2008-10-10 13:57:13 +00:00
|
|
|
kill(network->dnsmasqPid, SIGKILL);
|
|
|
|
network->dnsmasqPid = -1;
|
2010-12-20 06:14:11 +00:00
|
|
|
|
|
|
|
if (network->radvdPid > 0 &&
|
|
|
|
(kill(network->radvdPid, 0) == 0))
|
|
|
|
kill(network->radvdPid, SIGKILL);
|
|
|
|
network->radvdPid = -1;
|
|
|
|
|
network: separate Start/Shutdown functions for new network types
Previously all networks were composed of bridge devices created and
managed by libvirt, and the same operations needed to be done for all
of them when they were started and stopped (create and start the
bridge device, configure its MAC address and IP address, add iptables
rules). The new network types are (for now at least) managed outside
of libvirt, and the network object is used only to contain information
about the network, which is then used as each individual guest
connects itself.
This means that when starting/stopping one of these new networks, we
really want to do nothing, aside from marking the network as
active/inactive.
This has been setup as toplevel Start/Shutdown functions that do the
small bit of common stuff, then have a switch statement to execute
network type-specific start/shutdown code, then do a bit more common
code. The type-specific functions called for the new host bridge and
macvtap based types are currently empty.
In the future these functions may actually do something, and we will
surely add more functions that are similarly patterned. Once
everything has settled, we can make a table of "sub-driver" function
pointers for each network type, and store a pointer to that table in
the network object, then we can replace the switch statements with
calls to functions in the table.
The final step in this will be to add a new table (and corresponding
new functions) for new network types as they are added.
2011-06-30 21:05:07 +00:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int
|
|
|
|
networkStartNetworkExternal(struct network_driver *driver ATTRIBUTE_UNUSED,
|
|
|
|
virNetworkObjPtr network ATTRIBUTE_UNUSED)
|
|
|
|
{
|
|
|
|
/* put anything here that needs to be done each time a network of
|
|
|
|
* type BRIDGE, PRIVATE, VEPA, or PASSTHROUGH is started. On
|
|
|
|
* failure, undo anything you've done, and return -1. On success
|
|
|
|
* return 0.
|
|
|
|
*/
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int networkShutdownNetworkExternal(struct network_driver *driver ATTRIBUTE_UNUSED,
|
|
|
|
virNetworkObjPtr network ATTRIBUTE_UNUSED)
|
|
|
|
{
|
|
|
|
/* put anything here that needs to be done each time a network of
|
|
|
|
* type BRIDGE, PRIVATE, VEPA, or PASSTHROUGH is shutdown. On
|
|
|
|
* failure, undo anything you've done, and return -1. On success
|
|
|
|
* return 0.
|
|
|
|
*/
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int
|
|
|
|
networkStartNetwork(struct network_driver *driver,
|
|
|
|
virNetworkObjPtr network)
|
|
|
|
{
|
|
|
|
int ret = 0;
|
|
|
|
|
|
|
|
if (virNetworkObjIsActive(network)) {
|
2012-07-18 11:50:10 +00:00
|
|
|
virReportError(VIR_ERR_OPERATION_INVALID,
|
|
|
|
"%s", _("network is already active"));
|
network: separate Start/Shutdown functions for new network types
Previously all networks were composed of bridge devices created and
managed by libvirt, and the same operations needed to be done for all
of them when they were started and stopped (create and start the
bridge device, configure its MAC address and IP address, add iptables
rules). The new network types are (for now at least) managed outside
of libvirt, and the network object is used only to contain information
about the network, which is then used as each individual guest
connects itself.
This means that when starting/stopping one of these new networks, we
really want to do nothing, aside from marking the network as
active/inactive.
This has been setup as toplevel Start/Shutdown functions that do the
small bit of common stuff, then have a switch statement to execute
network type-specific start/shutdown code, then do a bit more common
code. The type-specific functions called for the new host bridge and
macvtap based types are currently empty.
In the future these functions may actually do something, and we will
surely add more functions that are similarly patterned. Once
everything has settled, we can make a table of "sub-driver" function
pointers for each network type, and store a pointer to that table in
the network object, then we can replace the switch statements with
calls to functions in the table.
The final step in this will be to add a new table (and corresponding
new functions) for new network types as they are added.
2011-06-30 21:05:07 +00:00
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
|
|
|
|
switch (network->def->forwardType) {
|
|
|
|
|
|
|
|
case VIR_NETWORK_FORWARD_NONE:
|
|
|
|
case VIR_NETWORK_FORWARD_NAT:
|
|
|
|
case VIR_NETWORK_FORWARD_ROUTE:
|
|
|
|
ret = networkStartNetworkVirtual(driver, network);
|
|
|
|
break;
|
|
|
|
|
|
|
|
case VIR_NETWORK_FORWARD_BRIDGE:
|
|
|
|
case VIR_NETWORK_FORWARD_PRIVATE:
|
|
|
|
case VIR_NETWORK_FORWARD_VEPA:
|
|
|
|
case VIR_NETWORK_FORWARD_PASSTHROUGH:
|
|
|
|
ret = networkStartNetworkExternal(driver, network);
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (ret < 0)
|
|
|
|
return ret;
|
|
|
|
|
|
|
|
/* Persist the live configuration now that anything autogenerated
|
|
|
|
* is setup.
|
|
|
|
*/
|
|
|
|
if ((ret = virNetworkSaveConfig(NETWORK_STATE_DIR, network->def)) < 0) {
|
|
|
|
goto error;
|
|
|
|
}
|
|
|
|
|
|
|
|
VIR_INFO("Starting up network '%s'", network->def->name);
|
|
|
|
network->active = 1;
|
|
|
|
|
|
|
|
error:
|
|
|
|
if (ret < 0) {
|
|
|
|
virErrorPtr save_err = virSaveLastError();
|
|
|
|
int save_errno = errno;
|
|
|
|
networkShutdownNetwork(driver, network);
|
|
|
|
virSetError(save_err);
|
|
|
|
virFreeError(save_err);
|
|
|
|
errno = save_errno;
|
|
|
|
}
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int networkShutdownNetwork(struct network_driver *driver,
|
|
|
|
virNetworkObjPtr network)
|
|
|
|
{
|
|
|
|
int ret = 0;
|
|
|
|
char *stateFile;
|
|
|
|
|
|
|
|
VIR_INFO("Shutting down network '%s'", network->def->name);
|
|
|
|
|
|
|
|
if (!virNetworkObjIsActive(network))
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
stateFile = virNetworkConfigFile(NETWORK_STATE_DIR, network->def->name);
|
|
|
|
if (!stateFile)
|
|
|
|
return -1;
|
|
|
|
|
|
|
|
unlink(stateFile);
|
|
|
|
VIR_FREE(stateFile);
|
|
|
|
|
|
|
|
switch (network->def->forwardType) {
|
|
|
|
|
|
|
|
case VIR_NETWORK_FORWARD_NONE:
|
|
|
|
case VIR_NETWORK_FORWARD_NAT:
|
|
|
|
case VIR_NETWORK_FORWARD_ROUTE:
|
|
|
|
ret = networkShutdownNetworkVirtual(driver, network);
|
|
|
|
break;
|
|
|
|
|
|
|
|
case VIR_NETWORK_FORWARD_BRIDGE:
|
|
|
|
case VIR_NETWORK_FORWARD_PRIVATE:
|
|
|
|
case VIR_NETWORK_FORWARD_VEPA:
|
|
|
|
case VIR_NETWORK_FORWARD_PASSTHROUGH:
|
|
|
|
ret = networkShutdownNetworkExternal(driver, network);
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
2008-10-10 13:57:13 +00:00
|
|
|
network->active = 0;
|
|
|
|
|
|
|
|
if (network->newDef) {
|
|
|
|
virNetworkDefFree(network->def);
|
|
|
|
network->def = network->newDef;
|
|
|
|
network->newDef = NULL;
|
|
|
|
}
|
|
|
|
|
network: separate Start/Shutdown functions for new network types
Previously all networks were composed of bridge devices created and
managed by libvirt, and the same operations needed to be done for all
of them when they were started and stopped (create and start the
bridge device, configure its MAC address and IP address, add iptables
rules). The new network types are (for now at least) managed outside
of libvirt, and the network object is used only to contain information
about the network, which is then used as each individual guest
connects itself.
This means that when starting/stopping one of these new networks, we
really want to do nothing, aside from marking the network as
active/inactive.
This has been setup as toplevel Start/Shutdown functions that do the
small bit of common stuff, then have a switch statement to execute
network type-specific start/shutdown code, then do a bit more common
code. The type-specific functions called for the new host bridge and
macvtap based types are currently empty.
In the future these functions may actually do something, and we will
surely add more functions that are similarly patterned. Once
everything has settled, we can make a table of "sub-driver" function
pointers for each network type, and store a pointer to that table in
the network object, then we can replace the switch statements with
calls to functions in the table.
The final step in this will be to add a new table (and corresponding
new functions) for new network types as they are added.
2011-06-30 21:05:07 +00:00
|
|
|
return ret;
|
2008-10-10 13:57:13 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
2008-12-04 21:37:52 +00:00
|
|
|
static virNetworkPtr networkLookupByUUID(virConnectPtr conn,
|
|
|
|
const unsigned char *uuid) {
|
|
|
|
struct network_driver *driver = conn->networkPrivateData;
|
|
|
|
virNetworkObjPtr network;
|
|
|
|
virNetworkPtr ret = NULL;
|
2008-10-10 13:57:13 +00:00
|
|
|
|
2008-12-04 21:38:38 +00:00
|
|
|
networkDriverLock(driver);
|
2008-12-04 21:37:52 +00:00
|
|
|
network = virNetworkFindByUUID(&driver->networks, uuid);
|
2008-12-04 21:38:38 +00:00
|
|
|
networkDriverUnlock(driver);
|
2008-10-10 13:57:13 +00:00
|
|
|
if (!network) {
|
2012-07-18 11:50:10 +00:00
|
|
|
virReportError(VIR_ERR_NO_NETWORK,
|
|
|
|
"%s", _("no network with matching uuid"));
|
2008-12-04 21:37:52 +00:00
|
|
|
goto cleanup;
|
2008-10-10 13:57:13 +00:00
|
|
|
}
|
|
|
|
|
2008-12-04 21:37:52 +00:00
|
|
|
ret = virGetNetwork(conn, network->def->name, network->def->uuid);
|
|
|
|
|
|
|
|
cleanup:
|
2008-12-04 21:38:38 +00:00
|
|
|
if (network)
|
|
|
|
virNetworkObjUnlock(network);
|
2008-12-04 21:37:52 +00:00
|
|
|
return ret;
|
2008-10-10 13:57:13 +00:00
|
|
|
}
|
|
|
|
|
2008-12-04 21:37:52 +00:00
|
|
|
static virNetworkPtr networkLookupByName(virConnectPtr conn,
|
|
|
|
const char *name) {
|
|
|
|
struct network_driver *driver = conn->networkPrivateData;
|
|
|
|
virNetworkObjPtr network;
|
|
|
|
virNetworkPtr ret = NULL;
|
|
|
|
|
2008-12-04 21:38:38 +00:00
|
|
|
networkDriverLock(driver);
|
2008-12-04 21:37:52 +00:00
|
|
|
network = virNetworkFindByName(&driver->networks, name);
|
2008-12-04 21:38:38 +00:00
|
|
|
networkDriverUnlock(driver);
|
2008-10-10 13:57:13 +00:00
|
|
|
if (!network) {
|
2012-07-18 11:50:10 +00:00
|
|
|
virReportError(VIR_ERR_NO_NETWORK,
|
|
|
|
_("no network with matching name '%s'"), name);
|
2008-12-04 21:37:52 +00:00
|
|
|
goto cleanup;
|
2008-10-10 13:57:13 +00:00
|
|
|
}
|
|
|
|
|
2008-12-04 21:37:52 +00:00
|
|
|
ret = virGetNetwork(conn, network->def->name, network->def->uuid);
|
|
|
|
|
|
|
|
cleanup:
|
2008-12-04 21:38:38 +00:00
|
|
|
if (network)
|
|
|
|
virNetworkObjUnlock(network);
|
2008-12-04 21:37:52 +00:00
|
|
|
return ret;
|
2008-10-10 13:57:13 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
static virDrvOpenStatus networkOpenNetwork(virConnectPtr conn,
|
|
|
|
virConnectAuthPtr auth ATTRIBUTE_UNUSED,
|
2011-07-06 22:29:02 +00:00
|
|
|
unsigned int flags)
|
|
|
|
{
|
|
|
|
virCheckFlags(VIR_CONNECT_RO, VIR_DRV_OPEN_ERROR);
|
|
|
|
|
2008-10-10 13:57:13 +00:00
|
|
|
if (!driverState)
|
|
|
|
return VIR_DRV_OPEN_DECLINED;
|
|
|
|
|
|
|
|
conn->networkPrivateData = driverState;
|
|
|
|
return VIR_DRV_OPEN_SUCCESS;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int networkCloseNetwork(virConnectPtr conn) {
|
|
|
|
conn->networkPrivateData = NULL;
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int networkNumNetworks(virConnectPtr conn) {
|
2008-10-10 14:50:26 +00:00
|
|
|
int nactive = 0, i;
|
2008-12-04 21:37:52 +00:00
|
|
|
struct network_driver *driver = conn->networkPrivateData;
|
2008-10-10 14:50:26 +00:00
|
|
|
|
2008-12-04 21:38:38 +00:00
|
|
|
networkDriverLock(driver);
|
|
|
|
for (i = 0 ; i < driver->networks.count ; i++) {
|
|
|
|
virNetworkObjLock(driver->networks.objs[i]);
|
Rename internal APis
Rename virDomainIsActive to virDomainObjIsActive, and
virInterfaceIsActive to virInterfaceObjIsActive and finally
virNetworkIsActive to virNetworkObjIsActive.
* src/conf/domain_conf.c, src/conf/domain_conf.h,
src/conf/interface_conf.h, src/conf/network_conf.c,
src/conf/network_conf.h, src/lxc/lxc_driver.c,
src/network/bridge_driver.c, src/opennebula/one_driver.c,
src/openvz/openvz_driver.c, src/qemu/qemu_driver.c,
src/test/test_driver.c, src/uml/uml_driver.c: Update for
renamed APIs.
2009-10-20 14:51:03 +00:00
|
|
|
if (virNetworkObjIsActive(driver->networks.objs[i]))
|
2008-10-10 13:57:13 +00:00
|
|
|
nactive++;
|
2008-12-04 21:38:38 +00:00
|
|
|
virNetworkObjUnlock(driver->networks.objs[i]);
|
|
|
|
}
|
|
|
|
networkDriverUnlock(driver);
|
2008-10-10 14:50:26 +00:00
|
|
|
|
2008-10-10 13:57:13 +00:00
|
|
|
return nactive;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int networkListNetworks(virConnectPtr conn, char **const names, int nnames) {
|
2008-12-04 21:37:52 +00:00
|
|
|
struct network_driver *driver = conn->networkPrivateData;
|
2008-10-10 13:57:13 +00:00
|
|
|
int got = 0, i;
|
2008-10-10 14:50:26 +00:00
|
|
|
|
2008-12-04 21:38:38 +00:00
|
|
|
networkDriverLock(driver);
|
2008-10-10 14:50:26 +00:00
|
|
|
for (i = 0 ; i < driver->networks.count && got < nnames ; i++) {
|
2008-12-04 21:38:38 +00:00
|
|
|
virNetworkObjLock(driver->networks.objs[i]);
|
Rename internal APis
Rename virDomainIsActive to virDomainObjIsActive, and
virInterfaceIsActive to virInterfaceObjIsActive and finally
virNetworkIsActive to virNetworkObjIsActive.
* src/conf/domain_conf.c, src/conf/domain_conf.h,
src/conf/interface_conf.h, src/conf/network_conf.c,
src/conf/network_conf.h, src/lxc/lxc_driver.c,
src/network/bridge_driver.c, src/opennebula/one_driver.c,
src/openvz/openvz_driver.c, src/qemu/qemu_driver.c,
src/test/test_driver.c, src/uml/uml_driver.c: Update for
renamed APIs.
2009-10-20 14:51:03 +00:00
|
|
|
if (virNetworkObjIsActive(driver->networks.objs[i])) {
|
2008-10-10 14:50:26 +00:00
|
|
|
if (!(names[got] = strdup(driver->networks.objs[i]->def->name))) {
|
2008-12-04 21:38:38 +00:00
|
|
|
virNetworkObjUnlock(driver->networks.objs[i]);
|
2010-02-04 18:19:08 +00:00
|
|
|
virReportOOMError();
|
2008-10-10 13:57:13 +00:00
|
|
|
goto cleanup;
|
|
|
|
}
|
|
|
|
got++;
|
|
|
|
}
|
2008-12-04 21:38:38 +00:00
|
|
|
virNetworkObjUnlock(driver->networks.objs[i]);
|
2008-10-10 13:57:13 +00:00
|
|
|
}
|
2008-12-04 21:38:38 +00:00
|
|
|
networkDriverUnlock(driver);
|
|
|
|
|
2008-10-10 13:57:13 +00:00
|
|
|
return got;
|
|
|
|
|
|
|
|
cleanup:
|
2008-12-04 21:38:38 +00:00
|
|
|
networkDriverUnlock(driver);
|
2008-10-10 13:57:13 +00:00
|
|
|
for (i = 0 ; i < got ; i++)
|
|
|
|
VIR_FREE(names[i]);
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int networkNumDefinedNetworks(virConnectPtr conn) {
|
2008-10-10 14:50:26 +00:00
|
|
|
int ninactive = 0, i;
|
2008-12-04 21:37:52 +00:00
|
|
|
struct network_driver *driver = conn->networkPrivateData;
|
2008-10-10 14:50:26 +00:00
|
|
|
|
2008-12-04 21:38:38 +00:00
|
|
|
networkDriverLock(driver);
|
|
|
|
for (i = 0 ; i < driver->networks.count ; i++) {
|
|
|
|
virNetworkObjLock(driver->networks.objs[i]);
|
Rename internal APis
Rename virDomainIsActive to virDomainObjIsActive, and
virInterfaceIsActive to virInterfaceObjIsActive and finally
virNetworkIsActive to virNetworkObjIsActive.
* src/conf/domain_conf.c, src/conf/domain_conf.h,
src/conf/interface_conf.h, src/conf/network_conf.c,
src/conf/network_conf.h, src/lxc/lxc_driver.c,
src/network/bridge_driver.c, src/opennebula/one_driver.c,
src/openvz/openvz_driver.c, src/qemu/qemu_driver.c,
src/test/test_driver.c, src/uml/uml_driver.c: Update for
renamed APIs.
2009-10-20 14:51:03 +00:00
|
|
|
if (!virNetworkObjIsActive(driver->networks.objs[i]))
|
2008-10-10 13:57:13 +00:00
|
|
|
ninactive++;
|
2008-12-04 21:38:38 +00:00
|
|
|
virNetworkObjUnlock(driver->networks.objs[i]);
|
|
|
|
}
|
|
|
|
networkDriverUnlock(driver);
|
2008-10-10 14:50:26 +00:00
|
|
|
|
2008-10-10 13:57:13 +00:00
|
|
|
return ninactive;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int networkListDefinedNetworks(virConnectPtr conn, char **const names, int nnames) {
|
2008-12-04 21:37:52 +00:00
|
|
|
struct network_driver *driver = conn->networkPrivateData;
|
2008-10-10 13:57:13 +00:00
|
|
|
int got = 0, i;
|
2008-10-10 14:50:26 +00:00
|
|
|
|
2008-12-04 21:38:38 +00:00
|
|
|
networkDriverLock(driver);
|
2008-10-10 14:50:26 +00:00
|
|
|
for (i = 0 ; i < driver->networks.count && got < nnames ; i++) {
|
2008-12-04 21:38:38 +00:00
|
|
|
virNetworkObjLock(driver->networks.objs[i]);
|
Rename internal APis
Rename virDomainIsActive to virDomainObjIsActive, and
virInterfaceIsActive to virInterfaceObjIsActive and finally
virNetworkIsActive to virNetworkObjIsActive.
* src/conf/domain_conf.c, src/conf/domain_conf.h,
src/conf/interface_conf.h, src/conf/network_conf.c,
src/conf/network_conf.h, src/lxc/lxc_driver.c,
src/network/bridge_driver.c, src/opennebula/one_driver.c,
src/openvz/openvz_driver.c, src/qemu/qemu_driver.c,
src/test/test_driver.c, src/uml/uml_driver.c: Update for
renamed APIs.
2009-10-20 14:51:03 +00:00
|
|
|
if (!virNetworkObjIsActive(driver->networks.objs[i])) {
|
2008-10-10 14:50:26 +00:00
|
|
|
if (!(names[got] = strdup(driver->networks.objs[i]->def->name))) {
|
2008-12-04 21:38:38 +00:00
|
|
|
virNetworkObjUnlock(driver->networks.objs[i]);
|
2010-02-04 18:19:08 +00:00
|
|
|
virReportOOMError();
|
2008-10-10 13:57:13 +00:00
|
|
|
goto cleanup;
|
|
|
|
}
|
|
|
|
got++;
|
|
|
|
}
|
2008-12-04 21:38:38 +00:00
|
|
|
virNetworkObjUnlock(driver->networks.objs[i]);
|
2008-10-10 13:57:13 +00:00
|
|
|
}
|
2008-12-04 21:38:38 +00:00
|
|
|
networkDriverUnlock(driver);
|
2008-10-10 13:57:13 +00:00
|
|
|
return got;
|
|
|
|
|
|
|
|
cleanup:
|
2008-12-04 21:38:38 +00:00
|
|
|
networkDriverUnlock(driver);
|
2008-10-10 13:57:13 +00:00
|
|
|
for (i = 0 ; i < got ; i++)
|
|
|
|
VIR_FREE(names[i]);
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
|
Implmentation of new APIs to checking state/persistence of objects
This implements the virConnectIsSecure, virConnectIsEncrypted,
virDomainIsPersistent, virDomainIsActive, virNetworkIsActive,
virNetworkIsPersistent, virStoragePoolIsActive,
virStoragePoolIsPersistent, virInterfaceIsActive APIs in
(nearly) all drivers. Exceptions are:
phyp: missing domainIsActive/Persistent
esx: missing domainIsPersistent
opennebula: missing domainIsActive/Persistent
* src/remote/remote_protocol.x: Define remote wire ABI for newly
added APIs.
* daemon/remote_dispatch*.h: Re-generated from remote_protocol.x
* src/esx/esx_driver.c, src/lxc/lxc_driver.c, src/network/bridge_driver.c,
src/opennebula/one_driver.c, src/openvz/openvz_conf.c,
src/openvz/openvz_driver.c, src/phyp/phyp_driver.c,
src/remote/remote_driver.c, src/storage/storage_driver.c,
src/test/test_driver.c, src/uml/uml_driver.c, src/vbox/vbox_tmpl.c,
src/xen/xen_driver.c, src/xen/xen_driver.h, src/xen/xen_inotify.c,
src/xen/xen_inotify.h: Implement all the new APIs where possible
2009-10-20 14:12:03 +00:00
|
|
|
|
|
|
|
static int networkIsActive(virNetworkPtr net)
|
|
|
|
{
|
2010-02-16 18:09:31 +00:00
|
|
|
struct network_driver *driver = net->conn->networkPrivateData;
|
Implmentation of new APIs to checking state/persistence of objects
This implements the virConnectIsSecure, virConnectIsEncrypted,
virDomainIsPersistent, virDomainIsActive, virNetworkIsActive,
virNetworkIsPersistent, virStoragePoolIsActive,
virStoragePoolIsPersistent, virInterfaceIsActive APIs in
(nearly) all drivers. Exceptions are:
phyp: missing domainIsActive/Persistent
esx: missing domainIsPersistent
opennebula: missing domainIsActive/Persistent
* src/remote/remote_protocol.x: Define remote wire ABI for newly
added APIs.
* daemon/remote_dispatch*.h: Re-generated from remote_protocol.x
* src/esx/esx_driver.c, src/lxc/lxc_driver.c, src/network/bridge_driver.c,
src/opennebula/one_driver.c, src/openvz/openvz_conf.c,
src/openvz/openvz_driver.c, src/phyp/phyp_driver.c,
src/remote/remote_driver.c, src/storage/storage_driver.c,
src/test/test_driver.c, src/uml/uml_driver.c, src/vbox/vbox_tmpl.c,
src/xen/xen_driver.c, src/xen/xen_driver.h, src/xen/xen_inotify.c,
src/xen/xen_inotify.h: Implement all the new APIs where possible
2009-10-20 14:12:03 +00:00
|
|
|
virNetworkObjPtr obj;
|
|
|
|
int ret = -1;
|
|
|
|
|
|
|
|
networkDriverLock(driver);
|
|
|
|
obj = virNetworkFindByUUID(&driver->networks, net->uuid);
|
|
|
|
networkDriverUnlock(driver);
|
|
|
|
if (!obj) {
|
2012-07-18 11:50:10 +00:00
|
|
|
virReportError(VIR_ERR_NO_NETWORK, NULL);
|
Implmentation of new APIs to checking state/persistence of objects
This implements the virConnectIsSecure, virConnectIsEncrypted,
virDomainIsPersistent, virDomainIsActive, virNetworkIsActive,
virNetworkIsPersistent, virStoragePoolIsActive,
virStoragePoolIsPersistent, virInterfaceIsActive APIs in
(nearly) all drivers. Exceptions are:
phyp: missing domainIsActive/Persistent
esx: missing domainIsPersistent
opennebula: missing domainIsActive/Persistent
* src/remote/remote_protocol.x: Define remote wire ABI for newly
added APIs.
* daemon/remote_dispatch*.h: Re-generated from remote_protocol.x
* src/esx/esx_driver.c, src/lxc/lxc_driver.c, src/network/bridge_driver.c,
src/opennebula/one_driver.c, src/openvz/openvz_conf.c,
src/openvz/openvz_driver.c, src/phyp/phyp_driver.c,
src/remote/remote_driver.c, src/storage/storage_driver.c,
src/test/test_driver.c, src/uml/uml_driver.c, src/vbox/vbox_tmpl.c,
src/xen/xen_driver.c, src/xen/xen_driver.h, src/xen/xen_inotify.c,
src/xen/xen_inotify.h: Implement all the new APIs where possible
2009-10-20 14:12:03 +00:00
|
|
|
goto cleanup;
|
|
|
|
}
|
|
|
|
ret = virNetworkObjIsActive(obj);
|
|
|
|
|
|
|
|
cleanup:
|
|
|
|
if (obj)
|
|
|
|
virNetworkObjUnlock(obj);
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int networkIsPersistent(virNetworkPtr net)
|
|
|
|
{
|
2010-02-16 18:09:31 +00:00
|
|
|
struct network_driver *driver = net->conn->networkPrivateData;
|
Implmentation of new APIs to checking state/persistence of objects
This implements the virConnectIsSecure, virConnectIsEncrypted,
virDomainIsPersistent, virDomainIsActive, virNetworkIsActive,
virNetworkIsPersistent, virStoragePoolIsActive,
virStoragePoolIsPersistent, virInterfaceIsActive APIs in
(nearly) all drivers. Exceptions are:
phyp: missing domainIsActive/Persistent
esx: missing domainIsPersistent
opennebula: missing domainIsActive/Persistent
* src/remote/remote_protocol.x: Define remote wire ABI for newly
added APIs.
* daemon/remote_dispatch*.h: Re-generated from remote_protocol.x
* src/esx/esx_driver.c, src/lxc/lxc_driver.c, src/network/bridge_driver.c,
src/opennebula/one_driver.c, src/openvz/openvz_conf.c,
src/openvz/openvz_driver.c, src/phyp/phyp_driver.c,
src/remote/remote_driver.c, src/storage/storage_driver.c,
src/test/test_driver.c, src/uml/uml_driver.c, src/vbox/vbox_tmpl.c,
src/xen/xen_driver.c, src/xen/xen_driver.h, src/xen/xen_inotify.c,
src/xen/xen_inotify.h: Implement all the new APIs where possible
2009-10-20 14:12:03 +00:00
|
|
|
virNetworkObjPtr obj;
|
|
|
|
int ret = -1;
|
|
|
|
|
|
|
|
networkDriverLock(driver);
|
|
|
|
obj = virNetworkFindByUUID(&driver->networks, net->uuid);
|
|
|
|
networkDriverUnlock(driver);
|
|
|
|
if (!obj) {
|
2012-07-18 11:50:10 +00:00
|
|
|
virReportError(VIR_ERR_NO_NETWORK, NULL);
|
Implmentation of new APIs to checking state/persistence of objects
This implements the virConnectIsSecure, virConnectIsEncrypted,
virDomainIsPersistent, virDomainIsActive, virNetworkIsActive,
virNetworkIsPersistent, virStoragePoolIsActive,
virStoragePoolIsPersistent, virInterfaceIsActive APIs in
(nearly) all drivers. Exceptions are:
phyp: missing domainIsActive/Persistent
esx: missing domainIsPersistent
opennebula: missing domainIsActive/Persistent
* src/remote/remote_protocol.x: Define remote wire ABI for newly
added APIs.
* daemon/remote_dispatch*.h: Re-generated from remote_protocol.x
* src/esx/esx_driver.c, src/lxc/lxc_driver.c, src/network/bridge_driver.c,
src/opennebula/one_driver.c, src/openvz/openvz_conf.c,
src/openvz/openvz_driver.c, src/phyp/phyp_driver.c,
src/remote/remote_driver.c, src/storage/storage_driver.c,
src/test/test_driver.c, src/uml/uml_driver.c, src/vbox/vbox_tmpl.c,
src/xen/xen_driver.c, src/xen/xen_driver.h, src/xen/xen_inotify.c,
src/xen/xen_inotify.h: Implement all the new APIs where possible
2009-10-20 14:12:03 +00:00
|
|
|
goto cleanup;
|
|
|
|
}
|
|
|
|
ret = obj->persistent;
|
|
|
|
|
|
|
|
cleanup:
|
|
|
|
if (obj)
|
|
|
|
virNetworkObjUnlock(obj);
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
network: make network driver vlan-aware
The network driver now looks for the vlan element in network and
portgroup objects, and logs an error at network define time if a vlan
is requested for a network type that doesn't support it. (Currently
vlan configuration is only supported for openvswitch networks, and
networks used to do hostdev assignment of SR-IOV VFs.)
At runtime, the three potential sources of vlan information are
examined in this order: interface, chosen portgroup, network, and the
first that is non-empty is used. Another check for valid network type
is made at this time, since the interface may have requested a vlan (a
legal thing to have in the interface config, since it's not known
until runtime if the chosen network will actually support it).
Since we must also check for domains requesting vlans for unsupported
connection types even if they are type='network', and since
networkAllocateActualDevice() is being called in exactly the correct
places, and has all of the necessary information to check, I slightly
modified the logic of that function so that interfaces that aren't
type='network' don't just return immediately. Instead, they also
perform all the same validation for supported features. Because of
this, it's not necessary to make this identical check in the other
three places that would normally require it: 1) qemu domain startup,
2) qemu device hotplug, 3) lxc domain startup.
This can be seen as a first step in consolidating network-related
functionality into the network driver, rather than having copies of
the same code spread around in multiple places; this will make it
easier to split the network parts off into a separate daemon, as we've
discussed recently.
2012-08-13 02:46:27 +00:00
|
|
|
static int
|
|
|
|
networkValidate(virNetworkDefPtr def)
|
|
|
|
{
|
|
|
|
int ii;
|
|
|
|
bool vlanUsed, vlanAllowed;
|
|
|
|
|
|
|
|
/* The only type of networks that currently support transparent
|
|
|
|
* vlan configuration are those using hostdev sr-iov devices from
|
|
|
|
* a pool, and those using an Open vSwitch bridge.
|
|
|
|
*/
|
|
|
|
|
|
|
|
vlanAllowed = (def->forwardType == VIR_NETWORK_FORWARD_BRIDGE &&
|
|
|
|
def->virtPortProfile &&
|
|
|
|
def->virtPortProfile->virtPortType == VIR_NETDEV_VPORT_PROFILE_OPENVSWITCH);
|
|
|
|
|
|
|
|
vlanUsed = def->vlan.nTags > 0;
|
|
|
|
for (ii = 0; ii < def->nPortGroups && !(vlanUsed && vlanAllowed); ii++) {
|
|
|
|
if (def->portGroups[ii].vlan.nTags > 0)
|
|
|
|
vlanUsed = true;
|
|
|
|
if (def->forwardType == VIR_NETWORK_FORWARD_BRIDGE &&
|
|
|
|
def->portGroups[ii].virtPortProfile &&
|
|
|
|
(def->portGroups[ii].virtPortProfile->virtPortType
|
|
|
|
== VIR_NETDEV_VPORT_PROFILE_OPENVSWITCH)) {
|
|
|
|
vlanAllowed = true;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
if (vlanUsed && !vlanAllowed) {
|
|
|
|
virReportError(VIR_ERR_CONFIG_UNSUPPORTED,
|
|
|
|
_("<vlan> element specified for network %s, "
|
|
|
|
"whose type doesn't support vlan configuration"),
|
|
|
|
def->name);
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2008-10-10 13:57:13 +00:00
|
|
|
static virNetworkPtr networkCreate(virConnectPtr conn, const char *xml) {
|
2008-12-04 21:37:52 +00:00
|
|
|
struct network_driver *driver = conn->networkPrivateData;
|
2008-10-10 13:57:13 +00:00
|
|
|
virNetworkDefPtr def;
|
2008-12-04 21:38:38 +00:00
|
|
|
virNetworkObjPtr network = NULL;
|
2008-12-04 21:37:52 +00:00
|
|
|
virNetworkPtr ret = NULL;
|
2008-10-10 13:57:13 +00:00
|
|
|
|
2008-12-04 21:38:38 +00:00
|
|
|
networkDriverLock(driver);
|
|
|
|
|
2010-02-10 10:22:52 +00:00
|
|
|
if (!(def = virNetworkDefParseString(xml)))
|
2008-12-04 21:37:52 +00:00
|
|
|
goto cleanup;
|
2008-10-10 13:57:13 +00:00
|
|
|
|
2010-05-27 15:44:31 +00:00
|
|
|
if (virNetworkObjIsDuplicate(&driver->networks, def, 1) < 0)
|
|
|
|
goto cleanup;
|
|
|
|
|
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
|
|
|
/* Only the three L3 network types that are configured by libvirt
|
|
|
|
* need to have a bridge device name / mac address provided
|
|
|
|
*/
|
|
|
|
if (def->forwardType == VIR_NETWORK_FORWARD_NONE ||
|
|
|
|
def->forwardType == VIR_NETWORK_FORWARD_NAT ||
|
|
|
|
def->forwardType == VIR_NETWORK_FORWARD_ROUTE) {
|
2009-03-02 17:37:03 +00:00
|
|
|
|
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
|
|
|
if (virNetworkSetBridgeName(&driver->networks, def, 1))
|
|
|
|
goto cleanup;
|
|
|
|
|
|
|
|
virNetworkSetBridgeMacAddr(def);
|
|
|
|
}
|
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
|
|
|
|
network: make network driver vlan-aware
The network driver now looks for the vlan element in network and
portgroup objects, and logs an error at network define time if a vlan
is requested for a network type that doesn't support it. (Currently
vlan configuration is only supported for openvswitch networks, and
networks used to do hostdev assignment of SR-IOV VFs.)
At runtime, the three potential sources of vlan information are
examined in this order: interface, chosen portgroup, network, and the
first that is non-empty is used. Another check for valid network type
is made at this time, since the interface may have requested a vlan (a
legal thing to have in the interface config, since it's not known
until runtime if the chosen network will actually support it).
Since we must also check for domains requesting vlans for unsupported
connection types even if they are type='network', and since
networkAllocateActualDevice() is being called in exactly the correct
places, and has all of the necessary information to check, I slightly
modified the logic of that function so that interfaces that aren't
type='network' don't just return immediately. Instead, they also
perform all the same validation for supported features. Because of
this, it's not necessary to make this identical check in the other
three places that would normally require it: 1) qemu domain startup,
2) qemu device hotplug, 3) lxc domain startup.
This can be seen as a first step in consolidating network-related
functionality into the network driver, rather than having copies of
the same code spread around in multiple places; this will make it
easier to split the network parts off into a separate daemon, as we've
discussed recently.
2012-08-13 02:46:27 +00:00
|
|
|
if (networkValidate(def) < 0)
|
|
|
|
goto cleanup;
|
|
|
|
|
2010-02-10 10:22:52 +00:00
|
|
|
if (!(network = virNetworkAssignDef(&driver->networks,
|
2008-12-04 21:37:52 +00:00
|
|
|
def)))
|
|
|
|
goto cleanup;
|
|
|
|
def = NULL;
|
2008-10-10 13:57:13 +00:00
|
|
|
|
network: separate Start/Shutdown functions for new network types
Previously all networks were composed of bridge devices created and
managed by libvirt, and the same operations needed to be done for all
of them when they were started and stopped (create and start the
bridge device, configure its MAC address and IP address, add iptables
rules). The new network types are (for now at least) managed outside
of libvirt, and the network object is used only to contain information
about the network, which is then used as each individual guest
connects itself.
This means that when starting/stopping one of these new networks, we
really want to do nothing, aside from marking the network as
active/inactive.
This has been setup as toplevel Start/Shutdown functions that do the
small bit of common stuff, then have a switch statement to execute
network type-specific start/shutdown code, then do a bit more common
code. The type-specific functions called for the new host bridge and
macvtap based types are currently empty.
In the future these functions may actually do something, and we will
surely add more functions that are similarly patterned. Once
everything has settled, we can make a table of "sub-driver" function
pointers for each network type, and store a pointer to that table in
the network object, then we can replace the switch statements with
calls to functions in the table.
The final step in this will be to add a new table (and corresponding
new functions) for new network types as they are added.
2011-06-30 21:05:07 +00:00
|
|
|
if (networkStartNetwork(driver, network) < 0) {
|
2008-10-10 13:57:13 +00:00
|
|
|
virNetworkRemoveInactive(&driver->networks,
|
|
|
|
network);
|
2008-12-04 21:38:38 +00:00
|
|
|
network = NULL;
|
2008-12-04 21:37:52 +00:00
|
|
|
goto cleanup;
|
2008-10-10 13:57:13 +00:00
|
|
|
}
|
|
|
|
|
maint: omit translation for all VIR_INFO
We were 31/73 on whether to translate; since less than 50% translated
and since VIR_INFO is less than VIR_WARN which also doesn't translate,
this makes sense.
* cfg.mk (sc_prohibit_gettext_markup): Add VIR_INFO, since it
falls between WARN and DEBUG.
* daemon/libvirtd.c (qemudDispatchSignalEvent, remoteCheckAccess)
(qemudDispatchServer): Adjust offenders.
* daemon/remote.c (remoteDispatchAuthPolkit): Likewise.
* src/network/bridge_driver.c (networkReloadIptablesRules)
(networkStartNetworkDaemon, networkShutdownNetworkDaemon)
(networkCreate, networkDefine, networkUndefine): Likewise.
* src/qemu/qemu_driver.c (qemudDomainDefine)
(qemudDomainUndefine): Likewise.
* src/storage/storage_driver.c (storagePoolCreate)
(storagePoolDefine, storagePoolUndefine, storagePoolStart)
(storagePoolDestroy, storagePoolDelete, storageVolumeCreateXML)
(storageVolumeCreateXMLFrom, storageVolumeDelete): Likewise.
* src/util/bridge.c (brProbeVnetHdr): Likewise.
* po/POTFILES.in: Drop src/util/bridge.c.
2011-05-11 15:08:44 +00:00
|
|
|
VIR_INFO("Creating network '%s'", network->def->name);
|
2008-12-04 21:37:52 +00:00
|
|
|
ret = virGetNetwork(conn, network->def->name, network->def->uuid);
|
|
|
|
|
|
|
|
cleanup:
|
|
|
|
virNetworkDefFree(def);
|
2008-12-04 21:38:38 +00:00
|
|
|
if (network)
|
|
|
|
virNetworkObjUnlock(network);
|
|
|
|
networkDriverUnlock(driver);
|
2008-12-04 21:37:52 +00:00
|
|
|
return ret;
|
2008-10-10 13:57:13 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
static virNetworkPtr networkDefine(virConnectPtr conn, const char *xml) {
|
2008-12-04 21:37:52 +00:00
|
|
|
struct network_driver *driver = conn->networkPrivateData;
|
2010-12-10 21:04:37 +00:00
|
|
|
virNetworkIpDefPtr ipdef, ipv4def = NULL;
|
2008-10-10 13:57:13 +00:00
|
|
|
virNetworkDefPtr def;
|
2011-08-03 19:33:24 +00:00
|
|
|
bool freeDef = true;
|
2008-12-04 21:38:38 +00:00
|
|
|
virNetworkObjPtr network = NULL;
|
2008-12-04 21:37:52 +00:00
|
|
|
virNetworkPtr ret = NULL;
|
2010-12-10 21:04:37 +00:00
|
|
|
int ii;
|
network: Fix dnsmasq hostsfile creation logic and related tests
networkSaveDnsmasqHostsfile was added in 8fa9c2214247 (Apr 2010).
It has a force flag. If the dnsmasq hostsfile already exists force
needs to be true to overwrite it. networkBuildDnsmasqArgv sets force
to false, networkDefine sets it to true. This results in the
hostsfile being written only in networkDefine in the common case.
If no error occurred networkSaveDnsmasqHostsfile returns true and
networkBuildDnsmasqArgv adds the --dhcp-hostsfile to the dnsmasq
command line.
networkSaveDnsmasqHostsfile was changed in 89ae9849f744 (24 Jun 2011)
to return a new dnsmasqContext instead of reusing one. This change broke
the logic of the force flag as now networkSaveDnsmasqHostsfile returns
NULL on error, but the early return -- if force was not set and the
hostsfile exists -- returns 0. This turned the early return in an error
case and networkBuildDnsmasqArgv didn't add the --dhcp-hostsfile option
anymore if the hostsfile already exists. It did because networkDefine
created the hostsfile already.
Then 9d4e2845d498 fixed the return 0 case in networkSaveDnsmasqHostsfile
but didn't apply the force option correctly to the new addnhosts file.
Now force doesn't control an early return anymore, but influences the
handling of the hostsfile context creation and dnsmasqSave is always
called now. This commit also added test cases that reveal several
problems. First, the tests now calls functions that try to write the
dnsmasq config files to disk. If someone runs this tests as root this
might overwrite actively used dnsmasq config files, this is a no-go. Also
the tests depend on configure --localstatedir, this needs to be fixed as
well, because it makes the tests fail when localstatedir is different
from /var.
This patch does several things to fix this:
1) Move dnsmasqContext creation and saving out of networkBuildDnsmasqArgv
to the caller to separate the command line generation from the config
file writing. This makes the command line generation testable without the
risk of interfering with system files, because the tests just don't call
dnsmasqSave.
2) This refactoring of networkSaveDnsmasqHostsfile makes the force flag
useless as the saving happens somewhere else now. This fixes the wrong
usage of the force flag in combination with then newly added addnhosts
file by removing the force flag.
3) Adapt the wrong test cases to the correct behavior, by adding the
missing --dhcp-hostsfile option. Both affected tests contain DHCP host
elements but missed the necessary --dhcp-hostsfile option.
4) Rename networkSaveDnsmasqHostsfile to networkBuildDnsmasqHostsfile,
because it doesn't save the dnsmasqContext anymore.
5) Move all directory creations in dnsmasq context handling code from
the *New functions to dnsmasqSave to avoid directory creations in system
paths in the test cases.
6) Now that networkBuildDnsmasqArgv doesn't create the dnsmasqContext
anymore the test case can create one with the localstatedir that is
expected by the tests instead of the configure --localstatedir given one.
2011-06-28 11:07:59 +00:00
|
|
|
dnsmasqContext* dctx = NULL;
|
2008-10-10 13:57:13 +00:00
|
|
|
|
2008-12-04 21:38:38 +00:00
|
|
|
networkDriverLock(driver);
|
|
|
|
|
2010-02-10 10:22:52 +00:00
|
|
|
if (!(def = virNetworkDefParseString(xml)))
|
2008-12-04 21:37:52 +00:00
|
|
|
goto cleanup;
|
2008-10-10 13:57:13 +00:00
|
|
|
|
2010-07-30 15:59:17 +00:00
|
|
|
if (virNetworkObjIsDuplicate(&driver->networks, def, 0) < 0)
|
2010-05-27 15:44:31 +00:00
|
|
|
goto cleanup;
|
|
|
|
|
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
|
|
|
/* Only the three L3 network types that are configured by libvirt
|
|
|
|
* need to have a bridge device name / mac address provided
|
|
|
|
*/
|
|
|
|
if (def->forwardType == VIR_NETWORK_FORWARD_NONE ||
|
|
|
|
def->forwardType == VIR_NETWORK_FORWARD_NAT ||
|
|
|
|
def->forwardType == VIR_NETWORK_FORWARD_ROUTE) {
|
2009-03-02 17:37:03 +00:00
|
|
|
|
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
|
|
|
if (virNetworkSetBridgeName(&driver->networks, def, 1))
|
|
|
|
goto cleanup;
|
|
|
|
|
|
|
|
virNetworkSetBridgeMacAddr(def);
|
|
|
|
}
|
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
|
|
|
|
2010-12-16 20:50:01 +00:00
|
|
|
/* We only support dhcp on one IPv4 address per defined network */
|
2010-12-10 21:04:37 +00:00
|
|
|
for (ii = 0;
|
2011-08-03 19:33:24 +00:00
|
|
|
(ipdef = virNetworkDefGetIpByIndex(def, AF_UNSPEC, ii));
|
2010-12-10 21:04:37 +00:00
|
|
|
ii++) {
|
Santize naming of socket address APIs
The socket address APIs in src/util/network.h either take the
form virSocketAddrXXX, virSocketXXX or virSocketXXXAddr.
Sanitize this so everything is virSocketAddrXXXX, and ensure
that the virSocketAddr parameter is always the first one.
* src/util/network.c, src/util/network.h: Santize socket
address API naming
* src/conf/domain_conf.c, src/conf/network_conf.c,
src/conf/nwfilter_conf.c, src/network/bridge_driver.c,
src/nwfilter/nwfilter_ebiptables_driver.c,
src/nwfilter/nwfilter_learnipaddr.c,
src/qemu/qemu_command.c, src/rpc/virnetsocket.c,
src/util/dnsmasq.c, src/util/iptables.c,
src/util/virnetdev.c, src/vbox/vbox_tmpl.c: Update for
API renaming
2011-11-02 14:06:59 +00:00
|
|
|
if (VIR_SOCKET_ADDR_IS_FAMILY(&ipdef->address, AF_INET)) {
|
2010-12-10 21:04:37 +00:00
|
|
|
if (ipdef->nranges || ipdef->nhosts) {
|
|
|
|
if (ipv4def) {
|
2012-07-18 11:50:10 +00:00
|
|
|
virReportError(VIR_ERR_CONFIG_UNSUPPORTED, "%s",
|
|
|
|
_("Multiple dhcp sections found. "
|
|
|
|
"dhcp is supported only for a "
|
|
|
|
"single IPv4 address on each network"));
|
2010-12-10 21:04:37 +00:00
|
|
|
goto cleanup;
|
|
|
|
} else {
|
|
|
|
ipv4def = ipdef;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
2011-11-30 14:26:25 +00:00
|
|
|
|
network: make network driver vlan-aware
The network driver now looks for the vlan element in network and
portgroup objects, and logs an error at network define time if a vlan
is requested for a network type that doesn't support it. (Currently
vlan configuration is only supported for openvswitch networks, and
networks used to do hostdev assignment of SR-IOV VFs.)
At runtime, the three potential sources of vlan information are
examined in this order: interface, chosen portgroup, network, and the
first that is non-empty is used. Another check for valid network type
is made at this time, since the interface may have requested a vlan (a
legal thing to have in the interface config, since it's not known
until runtime if the chosen network will actually support it).
Since we must also check for domains requesting vlans for unsupported
connection types even if they are type='network', and since
networkAllocateActualDevice() is being called in exactly the correct
places, and has all of the necessary information to check, I slightly
modified the logic of that function so that interfaces that aren't
type='network' don't just return immediately. Instead, they also
perform all the same validation for supported features. Because of
this, it's not necessary to make this identical check in the other
three places that would normally require it: 1) qemu domain startup,
2) qemu device hotplug, 3) lxc domain startup.
This can be seen as a first step in consolidating network-related
functionality into the network driver, rather than having copies of
the same code spread around in multiple places; this will make it
easier to split the network parts off into a separate daemon, as we've
discussed recently.
2012-08-13 02:46:27 +00:00
|
|
|
if (networkValidate(def) < 0)
|
|
|
|
goto cleanup;
|
|
|
|
|
2011-11-30 14:26:25 +00:00
|
|
|
if (!(network = virNetworkAssignDef(&driver->networks,
|
|
|
|
def)))
|
|
|
|
goto cleanup;
|
|
|
|
freeDef = false;
|
|
|
|
|
|
|
|
network->persistent = 1;
|
|
|
|
|
|
|
|
if (virNetworkSaveConfig(driver->networkConfigDir, def) < 0) {
|
|
|
|
virNetworkRemoveInactive(&driver->networks, network);
|
|
|
|
network = NULL;
|
|
|
|
goto cleanup;
|
|
|
|
}
|
|
|
|
|
2010-12-10 21:04:37 +00:00
|
|
|
if (ipv4def) {
|
2011-08-03 19:33:24 +00:00
|
|
|
dctx = dnsmasqContextNew(def->name, DNSMASQ_STATE_DIR);
|
network: Fix dnsmasq hostsfile creation logic and related tests
networkSaveDnsmasqHostsfile was added in 8fa9c2214247 (Apr 2010).
It has a force flag. If the dnsmasq hostsfile already exists force
needs to be true to overwrite it. networkBuildDnsmasqArgv sets force
to false, networkDefine sets it to true. This results in the
hostsfile being written only in networkDefine in the common case.
If no error occurred networkSaveDnsmasqHostsfile returns true and
networkBuildDnsmasqArgv adds the --dhcp-hostsfile to the dnsmasq
command line.
networkSaveDnsmasqHostsfile was changed in 89ae9849f744 (24 Jun 2011)
to return a new dnsmasqContext instead of reusing one. This change broke
the logic of the force flag as now networkSaveDnsmasqHostsfile returns
NULL on error, but the early return -- if force was not set and the
hostsfile exists -- returns 0. This turned the early return in an error
case and networkBuildDnsmasqArgv didn't add the --dhcp-hostsfile option
anymore if the hostsfile already exists. It did because networkDefine
created the hostsfile already.
Then 9d4e2845d498 fixed the return 0 case in networkSaveDnsmasqHostsfile
but didn't apply the force option correctly to the new addnhosts file.
Now force doesn't control an early return anymore, but influences the
handling of the hostsfile context creation and dnsmasqSave is always
called now. This commit also added test cases that reveal several
problems. First, the tests now calls functions that try to write the
dnsmasq config files to disk. If someone runs this tests as root this
might overwrite actively used dnsmasq config files, this is a no-go. Also
the tests depend on configure --localstatedir, this needs to be fixed as
well, because it makes the tests fail when localstatedir is different
from /var.
This patch does several things to fix this:
1) Move dnsmasqContext creation and saving out of networkBuildDnsmasqArgv
to the caller to separate the command line generation from the config
file writing. This makes the command line generation testable without the
risk of interfering with system files, because the tests just don't call
dnsmasqSave.
2) This refactoring of networkSaveDnsmasqHostsfile makes the force flag
useless as the saving happens somewhere else now. This fixes the wrong
usage of the force flag in combination with then newly added addnhosts
file by removing the force flag.
3) Adapt the wrong test cases to the correct behavior, by adding the
missing --dhcp-hostsfile option. Both affected tests contain DHCP host
elements but missed the necessary --dhcp-hostsfile option.
4) Rename networkSaveDnsmasqHostsfile to networkBuildDnsmasqHostsfile,
because it doesn't save the dnsmasqContext anymore.
5) Move all directory creations in dnsmasq context handling code from
the *New functions to dnsmasqSave to avoid directory creations in system
paths in the test cases.
6) Now that networkBuildDnsmasqArgv doesn't create the dnsmasqContext
anymore the test case can create one with the localstatedir that is
expected by the tests instead of the configure --localstatedir given one.
2011-06-28 11:07:59 +00:00
|
|
|
if (dctx == NULL ||
|
2011-08-03 19:33:24 +00:00
|
|
|
networkBuildDnsmasqHostsfile(dctx, ipv4def, def->dns) < 0 ||
|
network: Fix dnsmasq hostsfile creation logic and related tests
networkSaveDnsmasqHostsfile was added in 8fa9c2214247 (Apr 2010).
It has a force flag. If the dnsmasq hostsfile already exists force
needs to be true to overwrite it. networkBuildDnsmasqArgv sets force
to false, networkDefine sets it to true. This results in the
hostsfile being written only in networkDefine in the common case.
If no error occurred networkSaveDnsmasqHostsfile returns true and
networkBuildDnsmasqArgv adds the --dhcp-hostsfile to the dnsmasq
command line.
networkSaveDnsmasqHostsfile was changed in 89ae9849f744 (24 Jun 2011)
to return a new dnsmasqContext instead of reusing one. This change broke
the logic of the force flag as now networkSaveDnsmasqHostsfile returns
NULL on error, but the early return -- if force was not set and the
hostsfile exists -- returns 0. This turned the early return in an error
case and networkBuildDnsmasqArgv didn't add the --dhcp-hostsfile option
anymore if the hostsfile already exists. It did because networkDefine
created the hostsfile already.
Then 9d4e2845d498 fixed the return 0 case in networkSaveDnsmasqHostsfile
but didn't apply the force option correctly to the new addnhosts file.
Now force doesn't control an early return anymore, but influences the
handling of the hostsfile context creation and dnsmasqSave is always
called now. This commit also added test cases that reveal several
problems. First, the tests now calls functions that try to write the
dnsmasq config files to disk. If someone runs this tests as root this
might overwrite actively used dnsmasq config files, this is a no-go. Also
the tests depend on configure --localstatedir, this needs to be fixed as
well, because it makes the tests fail when localstatedir is different
from /var.
This patch does several things to fix this:
1) Move dnsmasqContext creation and saving out of networkBuildDnsmasqArgv
to the caller to separate the command line generation from the config
file writing. This makes the command line generation testable without the
risk of interfering with system files, because the tests just don't call
dnsmasqSave.
2) This refactoring of networkSaveDnsmasqHostsfile makes the force flag
useless as the saving happens somewhere else now. This fixes the wrong
usage of the force flag in combination with then newly added addnhosts
file by removing the force flag.
3) Adapt the wrong test cases to the correct behavior, by adding the
missing --dhcp-hostsfile option. Both affected tests contain DHCP host
elements but missed the necessary --dhcp-hostsfile option.
4) Rename networkSaveDnsmasqHostsfile to networkBuildDnsmasqHostsfile,
because it doesn't save the dnsmasqContext anymore.
5) Move all directory creations in dnsmasq context handling code from
the *New functions to dnsmasqSave to avoid directory creations in system
paths in the test cases.
6) Now that networkBuildDnsmasqArgv doesn't create the dnsmasqContext
anymore the test case can create one with the localstatedir that is
expected by the tests instead of the configure --localstatedir given one.
2011-06-28 11:07:59 +00:00
|
|
|
dnsmasqSave(dctx) < 0)
|
2010-04-26 14:07:25 +00:00
|
|
|
goto cleanup;
|
|
|
|
}
|
|
|
|
|
2011-08-03 19:33:24 +00:00
|
|
|
VIR_INFO("Defining network '%s'", def->name);
|
|
|
|
ret = virGetNetwork(conn, def->name, def->uuid);
|
2008-12-04 21:37:52 +00:00
|
|
|
|
|
|
|
cleanup:
|
2011-08-03 19:33:24 +00:00
|
|
|
if (freeDef)
|
|
|
|
virNetworkDefFree(def);
|
network: Fix dnsmasq hostsfile creation logic and related tests
networkSaveDnsmasqHostsfile was added in 8fa9c2214247 (Apr 2010).
It has a force flag. If the dnsmasq hostsfile already exists force
needs to be true to overwrite it. networkBuildDnsmasqArgv sets force
to false, networkDefine sets it to true. This results in the
hostsfile being written only in networkDefine in the common case.
If no error occurred networkSaveDnsmasqHostsfile returns true and
networkBuildDnsmasqArgv adds the --dhcp-hostsfile to the dnsmasq
command line.
networkSaveDnsmasqHostsfile was changed in 89ae9849f744 (24 Jun 2011)
to return a new dnsmasqContext instead of reusing one. This change broke
the logic of the force flag as now networkSaveDnsmasqHostsfile returns
NULL on error, but the early return -- if force was not set and the
hostsfile exists -- returns 0. This turned the early return in an error
case and networkBuildDnsmasqArgv didn't add the --dhcp-hostsfile option
anymore if the hostsfile already exists. It did because networkDefine
created the hostsfile already.
Then 9d4e2845d498 fixed the return 0 case in networkSaveDnsmasqHostsfile
but didn't apply the force option correctly to the new addnhosts file.
Now force doesn't control an early return anymore, but influences the
handling of the hostsfile context creation and dnsmasqSave is always
called now. This commit also added test cases that reveal several
problems. First, the tests now calls functions that try to write the
dnsmasq config files to disk. If someone runs this tests as root this
might overwrite actively used dnsmasq config files, this is a no-go. Also
the tests depend on configure --localstatedir, this needs to be fixed as
well, because it makes the tests fail when localstatedir is different
from /var.
This patch does several things to fix this:
1) Move dnsmasqContext creation and saving out of networkBuildDnsmasqArgv
to the caller to separate the command line generation from the config
file writing. This makes the command line generation testable without the
risk of interfering with system files, because the tests just don't call
dnsmasqSave.
2) This refactoring of networkSaveDnsmasqHostsfile makes the force flag
useless as the saving happens somewhere else now. This fixes the wrong
usage of the force flag in combination with then newly added addnhosts
file by removing the force flag.
3) Adapt the wrong test cases to the correct behavior, by adding the
missing --dhcp-hostsfile option. Both affected tests contain DHCP host
elements but missed the necessary --dhcp-hostsfile option.
4) Rename networkSaveDnsmasqHostsfile to networkBuildDnsmasqHostsfile,
because it doesn't save the dnsmasqContext anymore.
5) Move all directory creations in dnsmasq context handling code from
the *New functions to dnsmasqSave to avoid directory creations in system
paths in the test cases.
6) Now that networkBuildDnsmasqArgv doesn't create the dnsmasqContext
anymore the test case can create one with the localstatedir that is
expected by the tests instead of the configure --localstatedir given one.
2011-06-28 11:07:59 +00:00
|
|
|
dnsmasqContextFree(dctx);
|
2008-12-04 21:38:38 +00:00
|
|
|
if (network)
|
|
|
|
virNetworkObjUnlock(network);
|
|
|
|
networkDriverUnlock(driver);
|
2008-12-04 21:37:52 +00:00
|
|
|
return ret;
|
2008-10-10 13:57:13 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
static int networkUndefine(virNetworkPtr net) {
|
2008-12-04 21:37:52 +00:00
|
|
|
struct network_driver *driver = net->conn->networkPrivateData;
|
2010-11-17 18:36:19 +00:00
|
|
|
virNetworkObjPtr network;
|
2010-12-16 20:50:01 +00:00
|
|
|
virNetworkIpDefPtr ipdef;
|
|
|
|
bool dhcp_present = false, v6present = false;
|
2010-12-10 21:04:37 +00:00
|
|
|
int ret = -1, ii;
|
2008-10-10 13:57:13 +00:00
|
|
|
|
2008-12-04 21:38:38 +00:00
|
|
|
networkDriverLock(driver);
|
|
|
|
|
2008-12-04 21:37:52 +00:00
|
|
|
network = virNetworkFindByUUID(&driver->networks, net->uuid);
|
2008-10-10 13:57:13 +00:00
|
|
|
if (!network) {
|
2012-07-18 11:50:10 +00:00
|
|
|
virReportError(VIR_ERR_NO_NETWORK,
|
|
|
|
"%s", _("no network with matching uuid"));
|
2008-12-04 21:37:52 +00:00
|
|
|
goto cleanup;
|
2008-10-10 13:57:13 +00:00
|
|
|
}
|
|
|
|
|
Rename internal APis
Rename virDomainIsActive to virDomainObjIsActive, and
virInterfaceIsActive to virInterfaceObjIsActive and finally
virNetworkIsActive to virNetworkObjIsActive.
* src/conf/domain_conf.c, src/conf/domain_conf.h,
src/conf/interface_conf.h, src/conf/network_conf.c,
src/conf/network_conf.h, src/lxc/lxc_driver.c,
src/network/bridge_driver.c, src/opennebula/one_driver.c,
src/openvz/openvz_driver.c, src/qemu/qemu_driver.c,
src/test/test_driver.c, src/uml/uml_driver.c: Update for
renamed APIs.
2009-10-20 14:51:03 +00:00
|
|
|
if (virNetworkObjIsActive(network)) {
|
2012-07-18 11:50:10 +00:00
|
|
|
virReportError(VIR_ERR_OPERATION_INVALID,
|
|
|
|
"%s", _("network is still active"));
|
2008-12-04 21:37:52 +00:00
|
|
|
goto cleanup;
|
2008-10-10 13:57:13 +00:00
|
|
|
}
|
|
|
|
|
2010-02-10 10:22:52 +00:00
|
|
|
if (virNetworkDeleteConfig(driver->networkConfigDir,
|
2009-01-20 22:36:10 +00:00
|
|
|
driver->networkAutostartDir,
|
|
|
|
network) < 0)
|
2008-12-04 21:37:52 +00:00
|
|
|
goto cleanup;
|
2008-10-10 13:57:13 +00:00
|
|
|
|
2010-12-10 21:04:37 +00:00
|
|
|
/* we only support dhcp on one IPv4 address per defined network */
|
|
|
|
for (ii = 0;
|
2010-12-16 20:50:01 +00:00
|
|
|
(ipdef = virNetworkDefGetIpByIndex(network->def, AF_UNSPEC, ii));
|
2010-12-10 21:04:37 +00:00
|
|
|
ii++) {
|
Santize naming of socket address APIs
The socket address APIs in src/util/network.h either take the
form virSocketAddrXXX, virSocketXXX or virSocketXXXAddr.
Sanitize this so everything is virSocketAddrXXXX, and ensure
that the virSocketAddr parameter is always the first one.
* src/util/network.c, src/util/network.h: Santize socket
address API naming
* src/conf/domain_conf.c, src/conf/network_conf.c,
src/conf/nwfilter_conf.c, src/network/bridge_driver.c,
src/nwfilter/nwfilter_ebiptables_driver.c,
src/nwfilter/nwfilter_learnipaddr.c,
src/qemu/qemu_command.c, src/rpc/virnetsocket.c,
src/util/dnsmasq.c, src/util/iptables.c,
src/util/virnetdev.c, src/vbox/vbox_tmpl.c: Update for
API renaming
2011-11-02 14:06:59 +00:00
|
|
|
if (VIR_SOCKET_ADDR_IS_FAMILY(&ipdef->address, AF_INET)) {
|
2010-12-16 20:50:01 +00:00
|
|
|
if (ipdef->nranges || ipdef->nhosts)
|
|
|
|
dhcp_present = true;
|
Santize naming of socket address APIs
The socket address APIs in src/util/network.h either take the
form virSocketAddrXXX, virSocketXXX or virSocketXXXAddr.
Sanitize this so everything is virSocketAddrXXXX, and ensure
that the virSocketAddr parameter is always the first one.
* src/util/network.c, src/util/network.h: Santize socket
address API naming
* src/conf/domain_conf.c, src/conf/network_conf.c,
src/conf/nwfilter_conf.c, src/network/bridge_driver.c,
src/nwfilter/nwfilter_ebiptables_driver.c,
src/nwfilter/nwfilter_learnipaddr.c,
src/qemu/qemu_command.c, src/rpc/virnetsocket.c,
src/util/dnsmasq.c, src/util/iptables.c,
src/util/virnetdev.c, src/vbox/vbox_tmpl.c: Update for
API renaming
2011-11-02 14:06:59 +00:00
|
|
|
} else if (VIR_SOCKET_ADDR_IS_FAMILY(&ipdef->address, AF_INET6)) {
|
2010-12-16 20:50:01 +00:00
|
|
|
v6present = true;
|
|
|
|
}
|
2010-12-10 21:04:37 +00:00
|
|
|
}
|
2010-12-16 20:50:01 +00:00
|
|
|
|
|
|
|
if (dhcp_present) {
|
2011-03-11 18:20:48 +00:00
|
|
|
char *leasefile;
|
2010-04-26 14:07:25 +00:00
|
|
|
dnsmasqContext *dctx = dnsmasqContextNew(network->def->name, DNSMASQ_STATE_DIR);
|
|
|
|
if (dctx == NULL)
|
|
|
|
goto cleanup;
|
|
|
|
|
|
|
|
dnsmasqDelete(dctx);
|
|
|
|
dnsmasqContextFree(dctx);
|
2011-03-11 18:20:48 +00:00
|
|
|
|
|
|
|
leasefile = networkDnsmasqLeaseFileName(network->def->name);
|
|
|
|
if (!leasefile)
|
|
|
|
goto cleanup;
|
|
|
|
unlink(leasefile);
|
|
|
|
VIR_FREE(leasefile);
|
2010-04-26 14:07:25 +00:00
|
|
|
}
|
|
|
|
|
2010-12-20 06:14:11 +00:00
|
|
|
if (v6present) {
|
|
|
|
char *configfile = networkRadvdConfigFileName(network->def->name);
|
|
|
|
|
|
|
|
if (!configfile) {
|
|
|
|
virReportOOMError();
|
|
|
|
goto cleanup;
|
|
|
|
}
|
|
|
|
unlink(configfile);
|
|
|
|
VIR_FREE(configfile);
|
|
|
|
|
|
|
|
char *radvdpidbase = networkRadvdPidfileBasename(network->def->name);
|
|
|
|
|
|
|
|
if (!(radvdpidbase)) {
|
|
|
|
virReportOOMError();
|
|
|
|
goto cleanup;
|
|
|
|
}
|
2011-08-05 13:13:12 +00:00
|
|
|
virPidFileDelete(NETWORK_PID_DIR, radvdpidbase);
|
2010-12-20 06:14:11 +00:00
|
|
|
VIR_FREE(radvdpidbase);
|
|
|
|
|
|
|
|
}
|
|
|
|
|
maint: omit translation for all VIR_INFO
We were 31/73 on whether to translate; since less than 50% translated
and since VIR_INFO is less than VIR_WARN which also doesn't translate,
this makes sense.
* cfg.mk (sc_prohibit_gettext_markup): Add VIR_INFO, since it
falls between WARN and DEBUG.
* daemon/libvirtd.c (qemudDispatchSignalEvent, remoteCheckAccess)
(qemudDispatchServer): Adjust offenders.
* daemon/remote.c (remoteDispatchAuthPolkit): Likewise.
* src/network/bridge_driver.c (networkReloadIptablesRules)
(networkStartNetworkDaemon, networkShutdownNetworkDaemon)
(networkCreate, networkDefine, networkUndefine): Likewise.
* src/qemu/qemu_driver.c (qemudDomainDefine)
(qemudDomainUndefine): Likewise.
* src/storage/storage_driver.c (storagePoolCreate)
(storagePoolDefine, storagePoolUndefine, storagePoolStart)
(storagePoolDestroy, storagePoolDelete, storageVolumeCreateXML)
(storageVolumeCreateXMLFrom, storageVolumeDelete): Likewise.
* src/util/bridge.c (brProbeVnetHdr): Likewise.
* po/POTFILES.in: Drop src/util/bridge.c.
2011-05-11 15:08:44 +00:00
|
|
|
VIR_INFO("Undefining network '%s'", network->def->name);
|
2008-10-10 13:57:13 +00:00
|
|
|
virNetworkRemoveInactive(&driver->networks,
|
|
|
|
network);
|
2008-12-04 21:38:38 +00:00
|
|
|
network = NULL;
|
2008-12-04 21:37:52 +00:00
|
|
|
ret = 0;
|
2008-10-10 13:57:13 +00:00
|
|
|
|
2008-12-04 21:37:52 +00:00
|
|
|
cleanup:
|
2008-12-04 21:38:38 +00:00
|
|
|
if (network)
|
|
|
|
virNetworkObjUnlock(network);
|
|
|
|
networkDriverUnlock(driver);
|
2008-12-04 21:37:52 +00:00
|
|
|
return ret;
|
2008-10-10 13:57:13 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
static int networkStart(virNetworkPtr net) {
|
2008-12-04 21:37:52 +00:00
|
|
|
struct network_driver *driver = net->conn->networkPrivateData;
|
|
|
|
virNetworkObjPtr network;
|
|
|
|
int ret = -1;
|
2008-10-10 13:57:13 +00:00
|
|
|
|
2008-12-04 21:38:38 +00:00
|
|
|
networkDriverLock(driver);
|
2008-12-04 21:37:52 +00:00
|
|
|
network = virNetworkFindByUUID(&driver->networks, net->uuid);
|
2008-12-04 21:38:38 +00:00
|
|
|
|
2008-10-10 13:57:13 +00:00
|
|
|
if (!network) {
|
2012-07-18 11:50:10 +00:00
|
|
|
virReportError(VIR_ERR_NO_NETWORK,
|
|
|
|
"%s", _("no network with matching uuid"));
|
2008-12-04 21:37:52 +00:00
|
|
|
goto cleanup;
|
2008-10-10 13:57:13 +00:00
|
|
|
}
|
|
|
|
|
network: separate Start/Shutdown functions for new network types
Previously all networks were composed of bridge devices created and
managed by libvirt, and the same operations needed to be done for all
of them when they were started and stopped (create and start the
bridge device, configure its MAC address and IP address, add iptables
rules). The new network types are (for now at least) managed outside
of libvirt, and the network object is used only to contain information
about the network, which is then used as each individual guest
connects itself.
This means that when starting/stopping one of these new networks, we
really want to do nothing, aside from marking the network as
active/inactive.
This has been setup as toplevel Start/Shutdown functions that do the
small bit of common stuff, then have a switch statement to execute
network type-specific start/shutdown code, then do a bit more common
code. The type-specific functions called for the new host bridge and
macvtap based types are currently empty.
In the future these functions may actually do something, and we will
surely add more functions that are similarly patterned. Once
everything has settled, we can make a table of "sub-driver" function
pointers for each network type, and store a pointer to that table in
the network object, then we can replace the switch statements with
calls to functions in the table.
The final step in this will be to add a new table (and corresponding
new functions) for new network types as they are added.
2011-06-30 21:05:07 +00:00
|
|
|
ret = networkStartNetwork(driver, network);
|
2008-12-04 21:37:52 +00:00
|
|
|
|
|
|
|
cleanup:
|
2008-12-04 21:38:38 +00:00
|
|
|
if (network)
|
|
|
|
virNetworkObjUnlock(network);
|
2009-05-19 11:06:25 +00:00
|
|
|
networkDriverUnlock(driver);
|
2008-12-04 21:37:52 +00:00
|
|
|
return ret;
|
2008-10-10 13:57:13 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
static int networkDestroy(virNetworkPtr net) {
|
2008-12-04 21:37:52 +00:00
|
|
|
struct network_driver *driver = net->conn->networkPrivateData;
|
|
|
|
virNetworkObjPtr network;
|
|
|
|
int ret = -1;
|
2008-10-10 13:57:13 +00:00
|
|
|
|
2008-12-04 21:38:38 +00:00
|
|
|
networkDriverLock(driver);
|
2008-12-04 21:37:52 +00:00
|
|
|
network = virNetworkFindByUUID(&driver->networks, net->uuid);
|
2008-12-04 21:38:38 +00:00
|
|
|
|
2008-10-10 13:57:13 +00:00
|
|
|
if (!network) {
|
2012-07-18 11:50:10 +00:00
|
|
|
virReportError(VIR_ERR_NO_NETWORK,
|
|
|
|
"%s", _("no network with matching uuid"));
|
2008-12-04 21:37:52 +00:00
|
|
|
goto cleanup;
|
2008-10-10 13:57:13 +00:00
|
|
|
}
|
|
|
|
|
Rename internal APis
Rename virDomainIsActive to virDomainObjIsActive, and
virInterfaceIsActive to virInterfaceObjIsActive and finally
virNetworkIsActive to virNetworkObjIsActive.
* src/conf/domain_conf.c, src/conf/domain_conf.h,
src/conf/interface_conf.h, src/conf/network_conf.c,
src/conf/network_conf.h, src/lxc/lxc_driver.c,
src/network/bridge_driver.c, src/opennebula/one_driver.c,
src/openvz/openvz_driver.c, src/qemu/qemu_driver.c,
src/test/test_driver.c, src/uml/uml_driver.c: Update for
renamed APIs.
2009-10-20 14:51:03 +00:00
|
|
|
if (!virNetworkObjIsActive(network)) {
|
2012-07-18 11:50:10 +00:00
|
|
|
virReportError(VIR_ERR_OPERATION_INVALID,
|
|
|
|
"%s", _("network is not active"));
|
2009-05-29 14:14:32 +00:00
|
|
|
goto cleanup;
|
|
|
|
}
|
|
|
|
|
network: separate Start/Shutdown functions for new network types
Previously all networks were composed of bridge devices created and
managed by libvirt, and the same operations needed to be done for all
of them when they were started and stopped (create and start the
bridge device, configure its MAC address and IP address, add iptables
rules). The new network types are (for now at least) managed outside
of libvirt, and the network object is used only to contain information
about the network, which is then used as each individual guest
connects itself.
This means that when starting/stopping one of these new networks, we
really want to do nothing, aside from marking the network as
active/inactive.
This has been setup as toplevel Start/Shutdown functions that do the
small bit of common stuff, then have a switch statement to execute
network type-specific start/shutdown code, then do a bit more common
code. The type-specific functions called for the new host bridge and
macvtap based types are currently empty.
In the future these functions may actually do something, and we will
surely add more functions that are similarly patterned. Once
everything has settled, we can make a table of "sub-driver" function
pointers for each network type, and store a pointer to that table in
the network object, then we can replace the switch statements with
calls to functions in the table.
The final step in this will be to add a new table (and corresponding
new functions) for new network types as they are added.
2011-06-30 21:05:07 +00:00
|
|
|
ret = networkShutdownNetwork(driver, network);
|
2009-01-20 22:36:10 +00:00
|
|
|
if (!network->persistent) {
|
2008-12-04 21:38:38 +00:00
|
|
|
virNetworkRemoveInactive(&driver->networks,
|
|
|
|
network);
|
|
|
|
network = NULL;
|
|
|
|
}
|
2008-10-10 13:57:13 +00:00
|
|
|
|
2008-12-04 21:37:52 +00:00
|
|
|
cleanup:
|
2008-12-04 21:38:38 +00:00
|
|
|
if (network)
|
|
|
|
virNetworkObjUnlock(network);
|
2009-05-19 11:06:25 +00:00
|
|
|
networkDriverUnlock(driver);
|
2008-10-10 13:57:13 +00:00
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2011-07-06 20:40:19 +00:00
|
|
|
static char *networkGetXMLDesc(virNetworkPtr net,
|
2011-07-06 22:29:02 +00:00
|
|
|
unsigned int flags)
|
2011-07-06 20:40:19 +00:00
|
|
|
{
|
2008-12-04 21:37:52 +00:00
|
|
|
struct network_driver *driver = net->conn->networkPrivateData;
|
|
|
|
virNetworkObjPtr network;
|
2012-06-04 18:45:16 +00:00
|
|
|
virNetworkDefPtr def;
|
2008-12-04 21:37:52 +00:00
|
|
|
char *ret = NULL;
|
2008-10-10 13:57:13 +00:00
|
|
|
|
2011-12-14 10:50:40 +00:00
|
|
|
virCheckFlags(VIR_NETWORK_XML_INACTIVE, NULL);
|
2011-07-06 22:29:02 +00:00
|
|
|
|
2008-12-04 21:38:38 +00:00
|
|
|
networkDriverLock(driver);
|
2008-12-04 21:37:52 +00:00
|
|
|
network = virNetworkFindByUUID(&driver->networks, net->uuid);
|
2008-12-04 21:38:38 +00:00
|
|
|
networkDriverUnlock(driver);
|
|
|
|
|
2008-10-10 13:57:13 +00:00
|
|
|
if (!network) {
|
2012-07-18 11:50:10 +00:00
|
|
|
virReportError(VIR_ERR_NO_NETWORK,
|
|
|
|
"%s", _("no network with matching uuid"));
|
2008-12-04 21:37:52 +00:00
|
|
|
goto cleanup;
|
2008-10-10 13:57:13 +00:00
|
|
|
}
|
|
|
|
|
2012-06-04 18:45:16 +00:00
|
|
|
if ((flags & VIR_NETWORK_XML_INACTIVE) && network->newDef)
|
|
|
|
def = network->newDef;
|
|
|
|
else
|
|
|
|
def = network->def;
|
|
|
|
|
|
|
|
ret = virNetworkDefFormat(def, flags);
|
2008-12-04 21:37:52 +00:00
|
|
|
|
|
|
|
cleanup:
|
2008-12-04 21:38:38 +00:00
|
|
|
if (network)
|
|
|
|
virNetworkObjUnlock(network);
|
2008-12-04 21:37:52 +00:00
|
|
|
return ret;
|
2008-10-10 13:57:13 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
static char *networkGetBridgeName(virNetworkPtr net) {
|
2008-12-04 21:37:52 +00:00
|
|
|
struct network_driver *driver = net->conn->networkPrivateData;
|
|
|
|
virNetworkObjPtr network;
|
|
|
|
char *bridge = NULL;
|
|
|
|
|
2008-12-04 21:38:38 +00:00
|
|
|
networkDriverLock(driver);
|
2008-12-04 21:37:52 +00:00
|
|
|
network = virNetworkFindByUUID(&driver->networks, net->uuid);
|
2008-12-04 21:38:38 +00:00
|
|
|
networkDriverUnlock(driver);
|
|
|
|
|
2008-10-10 13:57:13 +00:00
|
|
|
if (!network) {
|
2012-07-18 11:50:10 +00:00
|
|
|
virReportError(VIR_ERR_NO_NETWORK,
|
|
|
|
"%s", _("no network with matching id"));
|
2008-12-04 21:37:52 +00:00
|
|
|
goto cleanup;
|
2008-10-10 13:57:13 +00:00
|
|
|
}
|
|
|
|
|
2008-12-11 14:57:45 +00:00
|
|
|
if (!(network->def->bridge)) {
|
2012-07-18 11:50:10 +00:00
|
|
|
virReportError(VIR_ERR_INTERNAL_ERROR,
|
|
|
|
_("network '%s' does not have a bridge name."),
|
|
|
|
network->def->name);
|
2008-12-11 14:57:45 +00:00
|
|
|
goto cleanup;
|
|
|
|
}
|
|
|
|
|
2008-10-10 13:57:13 +00:00
|
|
|
bridge = strdup(network->def->bridge);
|
2008-12-04 21:37:52 +00:00
|
|
|
if (!bridge)
|
2010-02-04 18:19:08 +00:00
|
|
|
virReportOOMError();
|
2008-12-04 21:37:52 +00:00
|
|
|
|
|
|
|
cleanup:
|
2008-12-04 21:38:38 +00:00
|
|
|
if (network)
|
|
|
|
virNetworkObjUnlock(network);
|
2008-10-10 13:57:13 +00:00
|
|
|
return bridge;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int networkGetAutostart(virNetworkPtr net,
|
|
|
|
int *autostart) {
|
2008-12-04 21:37:52 +00:00
|
|
|
struct network_driver *driver = net->conn->networkPrivateData;
|
|
|
|
virNetworkObjPtr network;
|
|
|
|
int ret = -1;
|
2008-10-10 13:57:13 +00:00
|
|
|
|
2008-12-04 21:38:38 +00:00
|
|
|
networkDriverLock(driver);
|
2008-12-04 21:37:52 +00:00
|
|
|
network = virNetworkFindByUUID(&driver->networks, net->uuid);
|
2008-12-04 21:38:38 +00:00
|
|
|
networkDriverUnlock(driver);
|
2008-10-10 13:57:13 +00:00
|
|
|
if (!network) {
|
2012-07-18 11:50:10 +00:00
|
|
|
virReportError(VIR_ERR_NO_NETWORK,
|
|
|
|
"%s", _("no network with matching uuid"));
|
2008-12-04 21:37:52 +00:00
|
|
|
goto cleanup;
|
2008-10-10 13:57:13 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
*autostart = network->autostart;
|
2008-12-04 21:37:52 +00:00
|
|
|
ret = 0;
|
2008-10-10 13:57:13 +00:00
|
|
|
|
2008-12-04 21:37:52 +00:00
|
|
|
cleanup:
|
2008-12-04 21:38:38 +00:00
|
|
|
if (network)
|
|
|
|
virNetworkObjUnlock(network);
|
2008-12-04 21:37:52 +00:00
|
|
|
return ret;
|
2008-10-10 13:57:13 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
static int networkSetAutostart(virNetworkPtr net,
|
2009-01-20 22:36:10 +00:00
|
|
|
int autostart) {
|
2008-12-04 21:37:52 +00:00
|
|
|
struct network_driver *driver = net->conn->networkPrivateData;
|
|
|
|
virNetworkObjPtr network;
|
2009-01-20 22:36:10 +00:00
|
|
|
char *configFile = NULL, *autostartLink = NULL;
|
2008-12-04 21:37:52 +00:00
|
|
|
int ret = -1;
|
2008-10-10 13:57:13 +00:00
|
|
|
|
2008-12-04 21:38:38 +00:00
|
|
|
networkDriverLock(driver);
|
2008-12-04 21:37:52 +00:00
|
|
|
network = virNetworkFindByUUID(&driver->networks, net->uuid);
|
2008-12-04 21:38:38 +00:00
|
|
|
|
2008-10-10 13:57:13 +00:00
|
|
|
if (!network) {
|
2012-07-18 11:50:10 +00:00
|
|
|
virReportError(VIR_ERR_NO_NETWORK,
|
|
|
|
"%s", _("no network with matching uuid"));
|
2008-12-04 21:37:52 +00:00
|
|
|
goto cleanup;
|
2008-10-10 13:57:13 +00:00
|
|
|
}
|
|
|
|
|
2009-06-03 13:52:06 +00:00
|
|
|
if (!network->persistent) {
|
2012-07-18 11:50:10 +00:00
|
|
|
virReportError(VIR_ERR_OPERATION_INVALID,
|
|
|
|
"%s", _("cannot set autostart for transient network"));
|
2009-06-03 13:52:06 +00:00
|
|
|
goto cleanup;
|
|
|
|
}
|
|
|
|
|
2008-10-10 13:57:13 +00:00
|
|
|
autostart = (autostart != 0);
|
|
|
|
|
2008-12-04 21:37:52 +00:00
|
|
|
if (network->autostart != autostart) {
|
2010-02-10 10:22:52 +00:00
|
|
|
if ((configFile = virNetworkConfigFile(driver->networkConfigDir, network->def->name)) == NULL)
|
2009-01-20 22:36:10 +00:00
|
|
|
goto cleanup;
|
2010-02-10 10:22:52 +00:00
|
|
|
if ((autostartLink = virNetworkConfigFile(driver->networkAutostartDir, network->def->name)) == NULL)
|
2009-01-20 22:36:10 +00:00
|
|
|
goto cleanup;
|
|
|
|
|
2008-12-04 21:37:52 +00:00
|
|
|
if (autostart) {
|
2011-07-05 21:02:53 +00:00
|
|
|
if (virFileMakePath(driver->networkAutostartDir) < 0) {
|
2010-02-04 20:02:58 +00:00
|
|
|
virReportSystemError(errno,
|
2009-01-20 17:13:33 +00:00
|
|
|
_("cannot create autostart directory '%s'"),
|
|
|
|
driver->networkAutostartDir);
|
2008-12-04 21:37:52 +00:00
|
|
|
goto cleanup;
|
|
|
|
}
|
2008-10-10 13:57:13 +00:00
|
|
|
|
2009-01-20 22:36:10 +00:00
|
|
|
if (symlink(configFile, autostartLink) < 0) {
|
2010-02-04 20:02:58 +00:00
|
|
|
virReportSystemError(errno,
|
2009-01-20 17:13:33 +00:00
|
|
|
_("Failed to create symlink '%s' to '%s'"),
|
2009-01-20 22:36:10 +00:00
|
|
|
autostartLink, configFile);
|
2008-12-04 21:37:52 +00:00
|
|
|
goto cleanup;
|
|
|
|
}
|
|
|
|
} else {
|
2009-01-20 22:36:10 +00:00
|
|
|
if (unlink(autostartLink) < 0 && errno != ENOENT && errno != ENOTDIR) {
|
2010-02-04 20:02:58 +00:00
|
|
|
virReportSystemError(errno,
|
2009-01-20 17:13:33 +00:00
|
|
|
_("Failed to delete symlink '%s'"),
|
2009-01-20 22:36:10 +00:00
|
|
|
autostartLink);
|
2008-12-04 21:37:52 +00:00
|
|
|
goto cleanup;
|
|
|
|
}
|
2008-10-10 13:57:13 +00:00
|
|
|
}
|
|
|
|
|
2008-12-04 21:37:52 +00:00
|
|
|
network->autostart = autostart;
|
2008-10-10 13:57:13 +00:00
|
|
|
}
|
2008-12-04 21:37:52 +00:00
|
|
|
ret = 0;
|
2008-10-10 13:57:13 +00:00
|
|
|
|
2008-12-04 21:37:52 +00:00
|
|
|
cleanup:
|
2009-01-20 22:36:10 +00:00
|
|
|
VIR_FREE(configFile);
|
|
|
|
VIR_FREE(autostartLink);
|
2008-12-04 21:38:38 +00:00
|
|
|
if (network)
|
|
|
|
virNetworkObjUnlock(network);
|
2009-05-19 11:06:25 +00:00
|
|
|
networkDriverUnlock(driver);
|
2008-12-04 21:37:52 +00:00
|
|
|
return ret;
|
2008-10-10 13:57:13 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
static virNetworkDriver networkDriver = {
|
|
|
|
"Network",
|
2011-05-13 13:35:01 +00:00
|
|
|
.open = networkOpenNetwork, /* 0.2.0 */
|
|
|
|
.close = networkCloseNetwork, /* 0.2.0 */
|
|
|
|
.numOfNetworks = networkNumNetworks, /* 0.2.0 */
|
|
|
|
.listNetworks = networkListNetworks, /* 0.2.0 */
|
|
|
|
.numOfDefinedNetworks = networkNumDefinedNetworks, /* 0.2.0 */
|
|
|
|
.listDefinedNetworks = networkListDefinedNetworks, /* 0.2.0 */
|
|
|
|
.networkLookupByUUID = networkLookupByUUID, /* 0.2.0 */
|
|
|
|
.networkLookupByName = networkLookupByName, /* 0.2.0 */
|
|
|
|
.networkCreateXML = networkCreate, /* 0.2.0 */
|
|
|
|
.networkDefineXML = networkDefine, /* 0.2.0 */
|
|
|
|
.networkUndefine = networkUndefine, /* 0.2.0 */
|
|
|
|
.networkCreate = networkStart, /* 0.2.0 */
|
|
|
|
.networkDestroy = networkDestroy, /* 0.2.0 */
|
|
|
|
.networkGetXMLDesc = networkGetXMLDesc, /* 0.2.0 */
|
|
|
|
.networkGetBridgeName = networkGetBridgeName, /* 0.2.0 */
|
|
|
|
.networkGetAutostart = networkGetAutostart, /* 0.2.1 */
|
|
|
|
.networkSetAutostart = networkSetAutostart, /* 0.2.1 */
|
|
|
|
.networkIsActive = networkIsActive, /* 0.7.3 */
|
|
|
|
.networkIsPersistent = networkIsPersistent, /* 0.7.3 */
|
2008-10-10 13:57:13 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
static virStateDriver networkStateDriver = {
|
Fix return value in virStateInitialize impl for LXC
The LXC driver was mistakenly returning -1 for lxcStartup()
in scenarios that are not an error. This caused the libvirtd
to quit for unprivileged users. This fixes the return code
of LXC driver, and also adds a "name" field to the virStateDriver
struct and logging to make it easier to find these problems
in the future
* src/driver.h: Add a 'name' field to state driver to allow
easy identification during failures
* src/libvirt.c: Log name of failed driver for virStateInit
failures
* src/lxc/lxc_driver.c: Don't return a failure code for
lxcStartup() if LXC is not available on this host, simply
disable the driver.
* src/network/bridge_driver.c, src/node_device/node_device_devkit.c,
src/node_device/node_device_hal.c, src/opennebula/one_driver.c,
src/qemu/qemu_driver.c, src/remote/remote_driver.c,
src/secret/secret_driver.c, src/storage/storage_driver.c,
src/uml/uml_driver.c, src/xen/xen_driver.c: Fill in name
field in virStateDriver struct
2009-11-02 23:18:19 +00:00
|
|
|
"Network",
|
2008-10-10 13:57:13 +00:00
|
|
|
networkStartup,
|
|
|
|
networkShutdown,
|
|
|
|
networkReload,
|
|
|
|
networkActive,
|
|
|
|
};
|
|
|
|
|
|
|
|
int networkRegister(void) {
|
|
|
|
virRegisterNetworkDriver(&networkDriver);
|
|
|
|
virRegisterStateDriver(&networkStateDriver);
|
|
|
|
return 0;
|
|
|
|
}
|
2011-07-04 06:27:12 +00:00
|
|
|
|
|
|
|
/********************************************************/
|
|
|
|
|
|
|
|
/* Private API to deal with logical switch capabilities.
|
|
|
|
* These functions are exported so that other parts of libvirt can
|
|
|
|
* call them, but are not part of the public API and not in the
|
|
|
|
* driver's function table. If we ever have more than one network
|
|
|
|
* driver, we will need to present these functions via a second
|
|
|
|
* "backend" function table.
|
|
|
|
*/
|
|
|
|
|
|
|
|
/* networkAllocateActualDevice:
|
|
|
|
* @iface: the original NetDef from the domain
|
|
|
|
*
|
|
|
|
* Looks up the network reference by iface, allocates a physical
|
|
|
|
* device from that network (if appropriate), and returns with the
|
|
|
|
* virDomainActualNetDef filled in accordingly. If there are no
|
|
|
|
* changes to be made in the netdef, then just leave the actualdef
|
|
|
|
* empty.
|
|
|
|
*
|
|
|
|
* Returns 0 on success, -1 on failure.
|
|
|
|
*/
|
|
|
|
int
|
|
|
|
networkAllocateActualDevice(virDomainNetDefPtr iface)
|
|
|
|
{
|
|
|
|
struct network_driver *driver = driverState;
|
network: make network driver vlan-aware
The network driver now looks for the vlan element in network and
portgroup objects, and logs an error at network define time if a vlan
is requested for a network type that doesn't support it. (Currently
vlan configuration is only supported for openvswitch networks, and
networks used to do hostdev assignment of SR-IOV VFs.)
At runtime, the three potential sources of vlan information are
examined in this order: interface, chosen portgroup, network, and the
first that is non-empty is used. Another check for valid network type
is made at this time, since the interface may have requested a vlan (a
legal thing to have in the interface config, since it's not known
until runtime if the chosen network will actually support it).
Since we must also check for domains requesting vlans for unsupported
connection types even if they are type='network', and since
networkAllocateActualDevice() is being called in exactly the correct
places, and has all of the necessary information to check, I slightly
modified the logic of that function so that interfaces that aren't
type='network' don't just return immediately. Instead, they also
perform all the same validation for supported features. Because of
this, it's not necessary to make this identical check in the other
three places that would normally require it: 1) qemu domain startup,
2) qemu device hotplug, 3) lxc domain startup.
This can be seen as a first step in consolidating network-related
functionality into the network driver, rather than having copies of
the same code spread around in multiple places; this will make it
easier to split the network parts off into a separate daemon, as we've
discussed recently.
2012-08-13 02:46:27 +00:00
|
|
|
enum virDomainNetType actualType = iface->type;
|
|
|
|
virNetworkObjPtr network = NULL;
|
|
|
|
virNetworkDefPtr netdef = NULL;
|
|
|
|
virPortGroupDefPtr portgroup = NULL;
|
|
|
|
virNetDevVPortProfilePtr virtport = iface->virtPortProfile;
|
|
|
|
virNetDevVlanPtr vlan = NULL;
|
network: merge relevant virtualports rather than choosing one
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),
2012-08-02 18:10:00 +00:00
|
|
|
virNetworkForwardIfDefPtr dev = NULL;
|
2011-12-14 10:50:30 +00:00
|
|
|
unsigned int num_virt_fns = 0;
|
|
|
|
char **vfname = NULL;
|
|
|
|
int ii;
|
2011-07-04 06:27:12 +00:00
|
|
|
int ret = -1;
|
|
|
|
|
network: make network driver vlan-aware
The network driver now looks for the vlan element in network and
portgroup objects, and logs an error at network define time if a vlan
is requested for a network type that doesn't support it. (Currently
vlan configuration is only supported for openvswitch networks, and
networks used to do hostdev assignment of SR-IOV VFs.)
At runtime, the three potential sources of vlan information are
examined in this order: interface, chosen portgroup, network, and the
first that is non-empty is used. Another check for valid network type
is made at this time, since the interface may have requested a vlan (a
legal thing to have in the interface config, since it's not known
until runtime if the chosen network will actually support it).
Since we must also check for domains requesting vlans for unsupported
connection types even if they are type='network', and since
networkAllocateActualDevice() is being called in exactly the correct
places, and has all of the necessary information to check, I slightly
modified the logic of that function so that interfaces that aren't
type='network' don't just return immediately. Instead, they also
perform all the same validation for supported features. Because of
this, it's not necessary to make this identical check in the other
three places that would normally require it: 1) qemu domain startup,
2) qemu device hotplug, 3) lxc domain startup.
This can be seen as a first step in consolidating network-related
functionality into the network driver, rather than having copies of
the same code spread around in multiple places; this will make it
easier to split the network parts off into a separate daemon, as we've
discussed recently.
2012-08-13 02:46:27 +00:00
|
|
|
/* it's handy to have this initialized if we skip directly to validate */
|
|
|
|
if (iface->vlan.nTags > 0)
|
|
|
|
vlan = &iface->vlan;
|
|
|
|
|
2011-07-04 06:27:12 +00:00
|
|
|
if (iface->type != VIR_DOMAIN_NET_TYPE_NETWORK)
|
network: make network driver vlan-aware
The network driver now looks for the vlan element in network and
portgroup objects, and logs an error at network define time if a vlan
is requested for a network type that doesn't support it. (Currently
vlan configuration is only supported for openvswitch networks, and
networks used to do hostdev assignment of SR-IOV VFs.)
At runtime, the three potential sources of vlan information are
examined in this order: interface, chosen portgroup, network, and the
first that is non-empty is used. Another check for valid network type
is made at this time, since the interface may have requested a vlan (a
legal thing to have in the interface config, since it's not known
until runtime if the chosen network will actually support it).
Since we must also check for domains requesting vlans for unsupported
connection types even if they are type='network', and since
networkAllocateActualDevice() is being called in exactly the correct
places, and has all of the necessary information to check, I slightly
modified the logic of that function so that interfaces that aren't
type='network' don't just return immediately. Instead, they also
perform all the same validation for supported features. Because of
this, it's not necessary to make this identical check in the other
three places that would normally require it: 1) qemu domain startup,
2) qemu device hotplug, 3) lxc domain startup.
This can be seen as a first step in consolidating network-related
functionality into the network driver, rather than having copies of
the same code spread around in multiple places; this will make it
easier to split the network parts off into a separate daemon, as we've
discussed recently.
2012-08-13 02:46:27 +00:00
|
|
|
goto validate;
|
2011-07-04 06:27:12 +00:00
|
|
|
|
|
|
|
virDomainActualNetDefFree(iface->data.network.actual);
|
|
|
|
iface->data.network.actual = NULL;
|
|
|
|
|
|
|
|
networkDriverLock(driver);
|
|
|
|
network = virNetworkFindByName(&driver->networks, iface->data.network.name);
|
|
|
|
networkDriverUnlock(driver);
|
|
|
|
if (!network) {
|
2012-07-18 11:50:10 +00:00
|
|
|
virReportError(VIR_ERR_NO_NETWORK,
|
|
|
|
_("no network with matching name '%s'"),
|
|
|
|
iface->data.network.name);
|
2012-08-06 17:45:57 +00:00
|
|
|
goto error;
|
2011-07-04 06:27:12 +00:00
|
|
|
}
|
|
|
|
netdef = network->def;
|
2011-10-04 03:53:36 +00:00
|
|
|
|
|
|
|
/* portgroup can be present for any type of network, in particular
|
|
|
|
* for bandwidth information, so we need to check for that and
|
|
|
|
* fill it in appropriately for all forward types.
|
|
|
|
*/
|
|
|
|
portgroup = virPortGroupFindByName(netdef, iface->data.network.portgroup);
|
|
|
|
|
|
|
|
/* If there is already interface-specific bandwidth, just use that
|
|
|
|
* (already in NetDef). Otherwise, if there is bandwidth info in
|
|
|
|
* the portgroup, fill that into the ActualDef.
|
|
|
|
*/
|
|
|
|
if (portgroup && !iface->bandwidth) {
|
|
|
|
if (!iface->data.network.actual
|
|
|
|
&& (VIR_ALLOC(iface->data.network.actual) < 0)) {
|
|
|
|
virReportOOMError();
|
2012-08-06 17:45:57 +00:00
|
|
|
goto error;
|
2011-10-04 03:53:36 +00:00
|
|
|
}
|
|
|
|
|
Adjust naming of network device bandwidth management APIs
Rename virBandwidth to virNetDevBandwidth, and virRate to
virNetDevBandwidthRate.
* src/util/network.c, src/util/network.h: Rename bandwidth
structs and APIs
* src/conf/domain_conf.c, src/conf/domain_conf.h,
src/conf/network_conf.c, src/conf/network_conf.h,
src/lxc/lxc_driver.c, src/network/bridge_driver.c,
src/qemu/qemu_command.c, src/util/macvtap.c,
src/util/macvtap.h, tools/virsh.c: Update for API changes.
2011-11-02 14:29:05 +00:00
|
|
|
if (virNetDevBandwidthCopy(&iface->data.network.actual->bandwidth,
|
|
|
|
portgroup->bandwidth) < 0)
|
2012-08-06 17:45:57 +00:00
|
|
|
goto error;
|
2011-10-04 03:53:36 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
if ((netdef->forwardType == VIR_NETWORK_FORWARD_NONE) ||
|
|
|
|
(netdef->forwardType == VIR_NETWORK_FORWARD_NAT) ||
|
|
|
|
(netdef->forwardType == VIR_NETWORK_FORWARD_ROUTE)) {
|
|
|
|
/* for these forward types, the actual net type really *is*
|
|
|
|
*NETWORK; we just keep the info from the portgroup in
|
|
|
|
* iface->data.network.actual
|
|
|
|
*/
|
|
|
|
if (iface->data.network.actual)
|
|
|
|
iface->data.network.actual->type = VIR_DOMAIN_NET_TYPE_NETWORK;
|
|
|
|
} else if ((netdef->forwardType == VIR_NETWORK_FORWARD_BRIDGE) &&
|
|
|
|
netdef->bridge) {
|
2011-07-04 06:27:12 +00:00
|
|
|
|
|
|
|
/* <forward type='bridge'/> <bridge name='xxx'/>
|
|
|
|
* is VIR_DOMAIN_NET_TYPE_BRIDGE
|
|
|
|
*/
|
|
|
|
|
2011-10-04 03:53:36 +00:00
|
|
|
if (!iface->data.network.actual
|
|
|
|
&& (VIR_ALLOC(iface->data.network.actual) < 0)) {
|
2011-07-04 06:27:12 +00:00
|
|
|
virReportOOMError();
|
2012-08-06 17:45:57 +00:00
|
|
|
goto error;
|
2011-07-04 06:27:12 +00:00
|
|
|
}
|
|
|
|
|
network: make network driver vlan-aware
The network driver now looks for the vlan element in network and
portgroup objects, and logs an error at network define time if a vlan
is requested for a network type that doesn't support it. (Currently
vlan configuration is only supported for openvswitch networks, and
networks used to do hostdev assignment of SR-IOV VFs.)
At runtime, the three potential sources of vlan information are
examined in this order: interface, chosen portgroup, network, and the
first that is non-empty is used. Another check for valid network type
is made at this time, since the interface may have requested a vlan (a
legal thing to have in the interface config, since it's not known
until runtime if the chosen network will actually support it).
Since we must also check for domains requesting vlans for unsupported
connection types even if they are type='network', and since
networkAllocateActualDevice() is being called in exactly the correct
places, and has all of the necessary information to check, I slightly
modified the logic of that function so that interfaces that aren't
type='network' don't just return immediately. Instead, they also
perform all the same validation for supported features. Because of
this, it's not necessary to make this identical check in the other
three places that would normally require it: 1) qemu domain startup,
2) qemu device hotplug, 3) lxc domain startup.
This can be seen as a first step in consolidating network-related
functionality into the network driver, rather than having copies of
the same code spread around in multiple places; this will make it
easier to split the network parts off into a separate daemon, as we've
discussed recently.
2012-08-13 02:46:27 +00:00
|
|
|
iface->data.network.actual->type = actualType = VIR_DOMAIN_NET_TYPE_BRIDGE;
|
2011-07-04 06:27:12 +00:00
|
|
|
iface->data.network.actual->data.bridge.brname = strdup(netdef->bridge);
|
|
|
|
if (!iface->data.network.actual->data.bridge.brname) {
|
|
|
|
virReportOOMError();
|
2012-08-06 17:45:57 +00:00
|
|
|
goto error;
|
2011-07-04 06:27:12 +00:00
|
|
|
}
|
|
|
|
|
network: merge relevant virtualports rather than choosing one
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),
2012-08-02 18:10:00 +00:00
|
|
|
/* merge virtualports from interface, network, and portgroup to
|
|
|
|
* arrive at actual virtualport to use
|
|
|
|
*/
|
|
|
|
if (virNetDevVPortProfileMerge3(&iface->data.network.actual->virtPortProfile,
|
|
|
|
iface->virtPortProfile,
|
|
|
|
netdef->virtPortProfile,
|
|
|
|
portgroup
|
|
|
|
? portgroup->virtPortProfile : NULL) < 0) {
|
2012-08-06 17:45:57 +00:00
|
|
|
goto error;
|
network: merge relevant virtualports rather than choosing one
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),
2012-08-02 18:10:00 +00:00
|
|
|
}
|
|
|
|
virtport = iface->data.network.actual->virtPortProfile;
|
|
|
|
if (virtport) {
|
|
|
|
/* only type='openvswitch' is allowed for bridges */
|
|
|
|
if (virtport->virtPortType != VIR_NETDEV_VPORT_PROFILE_OPENVSWITCH) {
|
|
|
|
virReportError(VIR_ERR_CONFIG_UNSUPPORTED,
|
|
|
|
_("<virtualport type='%s'> not supported for network "
|
|
|
|
"'%s' which uses a bridge device"),
|
|
|
|
virNetDevVPortTypeToString(virtport->virtPortType),
|
|
|
|
netdef->name);
|
2012-08-06 17:45:57 +00:00
|
|
|
goto error;
|
network: merge relevant virtualports rather than choosing one
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),
2012-08-02 18:10:00 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2011-07-04 06:27:12 +00:00
|
|
|
} else if ((netdef->forwardType == VIR_NETWORK_FORWARD_BRIDGE) ||
|
|
|
|
(netdef->forwardType == VIR_NETWORK_FORWARD_PRIVATE) ||
|
|
|
|
(netdef->forwardType == VIR_NETWORK_FORWARD_VEPA) ||
|
|
|
|
(netdef->forwardType == VIR_NETWORK_FORWARD_PASSTHROUGH)) {
|
|
|
|
|
|
|
|
/* <forward type='bridge|private|vepa|passthrough'> are all
|
|
|
|
* VIR_DOMAIN_NET_TYPE_DIRECT.
|
|
|
|
*/
|
|
|
|
|
2011-10-04 03:53:36 +00:00
|
|
|
if (!iface->data.network.actual
|
|
|
|
&& (VIR_ALLOC(iface->data.network.actual) < 0)) {
|
2011-07-04 06:27:12 +00:00
|
|
|
virReportOOMError();
|
2012-08-06 17:45:57 +00:00
|
|
|
goto error;
|
2011-07-04 06:27:12 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/* Set type=direct and appropriate <source mode='xxx'/> */
|
network: make network driver vlan-aware
The network driver now looks for the vlan element in network and
portgroup objects, and logs an error at network define time if a vlan
is requested for a network type that doesn't support it. (Currently
vlan configuration is only supported for openvswitch networks, and
networks used to do hostdev assignment of SR-IOV VFs.)
At runtime, the three potential sources of vlan information are
examined in this order: interface, chosen portgroup, network, and the
first that is non-empty is used. Another check for valid network type
is made at this time, since the interface may have requested a vlan (a
legal thing to have in the interface config, since it's not known
until runtime if the chosen network will actually support it).
Since we must also check for domains requesting vlans for unsupported
connection types even if they are type='network', and since
networkAllocateActualDevice() is being called in exactly the correct
places, and has all of the necessary information to check, I slightly
modified the logic of that function so that interfaces that aren't
type='network' don't just return immediately. Instead, they also
perform all the same validation for supported features. Because of
this, it's not necessary to make this identical check in the other
three places that would normally require it: 1) qemu domain startup,
2) qemu device hotplug, 3) lxc domain startup.
This can be seen as a first step in consolidating network-related
functionality into the network driver, rather than having copies of
the same code spread around in multiple places; this will make it
easier to split the network parts off into a separate daemon, as we've
discussed recently.
2012-08-13 02:46:27 +00:00
|
|
|
iface->data.network.actual->type = actualType = VIR_DOMAIN_NET_TYPE_DIRECT;
|
2011-07-04 06:27:12 +00:00
|
|
|
switch (netdef->forwardType) {
|
|
|
|
case VIR_NETWORK_FORWARD_BRIDGE:
|
Rename Macvtap management APIs
In preparation for code re-organization, rename the Macvtap
management APIs to have the following patterns
virNetDevMacVLanXXXXX - macvlan/macvtap interface management
virNetDevVPortProfileXXXX - virtual port profile management
* src/util/macvtap.c, src/util/macvtap.h: Rename APIs
* src/conf/domain_conf.c, src/network/bridge_driver.c,
src/qemu/qemu_command.c, src/qemu/qemu_command.h,
src/qemu/qemu_driver.c, src/qemu/qemu_hotplug.c,
src/qemu/qemu_migration.c, src/qemu/qemu_process.c,
src/qemu/qemu_process.h: Update for renamed APIs
2011-11-02 16:51:01 +00:00
|
|
|
iface->data.network.actual->data.direct.mode = VIR_NETDEV_MACVLAN_MODE_BRIDGE;
|
2011-07-04 06:27:12 +00:00
|
|
|
break;
|
|
|
|
case VIR_NETWORK_FORWARD_PRIVATE:
|
Rename Macvtap management APIs
In preparation for code re-organization, rename the Macvtap
management APIs to have the following patterns
virNetDevMacVLanXXXXX - macvlan/macvtap interface management
virNetDevVPortProfileXXXX - virtual port profile management
* src/util/macvtap.c, src/util/macvtap.h: Rename APIs
* src/conf/domain_conf.c, src/network/bridge_driver.c,
src/qemu/qemu_command.c, src/qemu/qemu_command.h,
src/qemu/qemu_driver.c, src/qemu/qemu_hotplug.c,
src/qemu/qemu_migration.c, src/qemu/qemu_process.c,
src/qemu/qemu_process.h: Update for renamed APIs
2011-11-02 16:51:01 +00:00
|
|
|
iface->data.network.actual->data.direct.mode = VIR_NETDEV_MACVLAN_MODE_PRIVATE;
|
2011-07-04 06:27:12 +00:00
|
|
|
break;
|
|
|
|
case VIR_NETWORK_FORWARD_VEPA:
|
Rename Macvtap management APIs
In preparation for code re-organization, rename the Macvtap
management APIs to have the following patterns
virNetDevMacVLanXXXXX - macvlan/macvtap interface management
virNetDevVPortProfileXXXX - virtual port profile management
* src/util/macvtap.c, src/util/macvtap.h: Rename APIs
* src/conf/domain_conf.c, src/network/bridge_driver.c,
src/qemu/qemu_command.c, src/qemu/qemu_command.h,
src/qemu/qemu_driver.c, src/qemu/qemu_hotplug.c,
src/qemu/qemu_migration.c, src/qemu/qemu_process.c,
src/qemu/qemu_process.h: Update for renamed APIs
2011-11-02 16:51:01 +00:00
|
|
|
iface->data.network.actual->data.direct.mode = VIR_NETDEV_MACVLAN_MODE_VEPA;
|
2011-07-04 06:27:12 +00:00
|
|
|
break;
|
|
|
|
case VIR_NETWORK_FORWARD_PASSTHROUGH:
|
Rename Macvtap management APIs
In preparation for code re-organization, rename the Macvtap
management APIs to have the following patterns
virNetDevMacVLanXXXXX - macvlan/macvtap interface management
virNetDevVPortProfileXXXX - virtual port profile management
* src/util/macvtap.c, src/util/macvtap.h: Rename APIs
* src/conf/domain_conf.c, src/network/bridge_driver.c,
src/qemu/qemu_command.c, src/qemu/qemu_command.h,
src/qemu/qemu_driver.c, src/qemu/qemu_hotplug.c,
src/qemu/qemu_migration.c, src/qemu/qemu_process.c,
src/qemu/qemu_process.h: Update for renamed APIs
2011-11-02 16:51:01 +00:00
|
|
|
iface->data.network.actual->data.direct.mode = VIR_NETDEV_MACVLAN_MODE_PASSTHRU;
|
2011-07-04 06:27:12 +00:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
network: merge relevant virtualports rather than choosing one
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),
2012-08-02 18:10:00 +00:00
|
|
|
/* merge virtualports from interface, network, and portgroup to
|
|
|
|
* arrive at actual virtualport to use
|
|
|
|
*/
|
|
|
|
if (virNetDevVPortProfileMerge3(&iface->data.network.actual->virtPortProfile,
|
|
|
|
iface->virtPortProfile,
|
|
|
|
netdef->virtPortProfile,
|
|
|
|
portgroup
|
|
|
|
? portgroup->virtPortProfile : NULL) < 0) {
|
2012-08-06 17:45:57 +00:00
|
|
|
goto error;
|
2011-07-04 06:27:12 +00:00
|
|
|
}
|
network: merge relevant virtualports rather than choosing one
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),
2012-08-02 18:10:00 +00:00
|
|
|
virtport = iface->data.network.actual->virtPortProfile;
|
2011-07-04 06:27:12 +00:00
|
|
|
if (virtport) {
|
network: merge relevant virtualports rather than choosing one
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),
2012-08-02 18:10:00 +00:00
|
|
|
/* make sure type is supported for macvtap connections */
|
|
|
|
if (virtport->virtPortType != VIR_NETDEV_VPORT_PROFILE_8021QBG &&
|
|
|
|
virtport->virtPortType != VIR_NETDEV_VPORT_PROFILE_8021QBH) {
|
|
|
|
virReportError(VIR_ERR_CONFIG_UNSUPPORTED,
|
|
|
|
_("<virtualport type='%s'> not supported for network "
|
|
|
|
"'%s' which uses a macvtap device"),
|
|
|
|
virNetDevVPortTypeToString(virtport->virtPortType),
|
|
|
|
netdef->name);
|
2012-08-06 17:45:57 +00:00
|
|
|
goto error;
|
2011-07-04 06:27:12 +00:00
|
|
|
}
|
|
|
|
}
|
2011-07-26 12:42:37 +00:00
|
|
|
|
2011-07-04 06:27:12 +00:00
|
|
|
/* If there is only a single device, just return it (caller will detect
|
|
|
|
* any error if exclusive use is required but could not be acquired).
|
|
|
|
*/
|
2011-12-14 10:50:30 +00:00
|
|
|
if ((netdef->nForwardIfs <= 0) && (netdef->nForwardPfs <= 0)) {
|
2012-07-18 11:50:10 +00:00
|
|
|
virReportError(VIR_ERR_INTERNAL_ERROR,
|
|
|
|
_("network '%s' uses a direct mode, but "
|
|
|
|
"has no forward dev and no interface pool"),
|
|
|
|
netdef->name);
|
2012-08-06 17:45:57 +00:00
|
|
|
goto error;
|
2011-07-04 06:27:12 +00:00
|
|
|
} else {
|
|
|
|
/* pick an interface from the pool */
|
|
|
|
|
2012-08-05 06:45:04 +00:00
|
|
|
/* PASSTHROUGH mode, and PRIVATE Mode + 802.1Qbh both
|
|
|
|
* require exclusive access to a device, so current
|
|
|
|
* connections count must be 0. Other modes can share, so
|
|
|
|
* just search for the one with the lowest number of
|
|
|
|
* connections.
|
2011-07-04 06:27:12 +00:00
|
|
|
*/
|
2011-12-14 10:50:30 +00:00
|
|
|
if (netdef->forwardType == VIR_NETWORK_FORWARD_PASSTHROUGH) {
|
|
|
|
if ((netdef->nForwardPfs > 0) && (netdef->nForwardIfs <= 0)) {
|
|
|
|
if ((virNetDevGetVirtualFunctions(netdef->forwardPfs->dev,
|
|
|
|
&vfname, &num_virt_fns)) < 0) {
|
2012-07-18 11:50:10 +00:00
|
|
|
virReportError(VIR_ERR_INTERNAL_ERROR,
|
|
|
|
_("Could not get Virtual functions on %s"),
|
|
|
|
netdef->forwardPfs->dev);
|
2012-08-06 17:45:57 +00:00
|
|
|
goto error;
|
2011-12-14 10:50:30 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
if (num_virt_fns == 0) {
|
2012-07-18 11:50:10 +00:00
|
|
|
virReportError(VIR_ERR_INTERNAL_ERROR,
|
|
|
|
_("No Vf's present on SRIOV PF %s"),
|
|
|
|
netdef->forwardPfs->dev);
|
2012-08-06 17:45:57 +00:00
|
|
|
goto error;
|
2011-12-14 10:50:30 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
if ((VIR_ALLOC_N(netdef->forwardIfs, num_virt_fns)) < 0) {
|
|
|
|
virReportOOMError();
|
2012-08-06 17:45:57 +00:00
|
|
|
goto error;
|
2011-12-14 10:50:30 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
netdef->nForwardIfs = num_virt_fns;
|
|
|
|
|
|
|
|
for (ii = 0; ii < netdef->nForwardIfs; ii++) {
|
|
|
|
netdef->forwardIfs[ii].dev = strdup(vfname[ii]);
|
|
|
|
if (!netdef->forwardIfs[ii].dev) {
|
|
|
|
virReportOOMError();
|
2012-08-06 17:45:57 +00:00
|
|
|
goto error;
|
2011-12-14 10:50:30 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2012-08-05 06:45:04 +00:00
|
|
|
/* pick first dev with 0 connections */
|
2011-07-04 06:27:12 +00:00
|
|
|
|
2011-12-14 10:50:30 +00:00
|
|
|
for (ii = 0; ii < netdef->nForwardIfs; ii++) {
|
2012-08-05 06:45:04 +00:00
|
|
|
if (netdef->forwardIfs[ii].connections == 0) {
|
2011-12-14 10:50:30 +00:00
|
|
|
dev = &netdef->forwardIfs[ii];
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
} else if ((netdef->forwardType == VIR_NETWORK_FORWARD_PRIVATE) &&
|
2012-07-30 06:03:25 +00:00
|
|
|
iface->data.network.actual->virtPortProfile &&
|
|
|
|
(iface->data.network.actual->virtPortProfile->virtPortType
|
2011-12-14 10:50:30 +00:00
|
|
|
== VIR_NETDEV_VPORT_PROFILE_8021QBH)) {
|
|
|
|
|
2012-08-05 06:45:04 +00:00
|
|
|
/* pick first dev with 0 connections */
|
2011-07-04 06:27:12 +00:00
|
|
|
for (ii = 0; ii < netdef->nForwardIfs; ii++) {
|
2012-08-05 06:45:04 +00:00
|
|
|
if (netdef->forwardIfs[ii].connections == 0) {
|
2011-07-04 06:27:12 +00:00
|
|
|
dev = &netdef->forwardIfs[ii];
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
} else {
|
|
|
|
/* pick least used dev */
|
|
|
|
dev = &netdef->forwardIfs[0];
|
|
|
|
for (ii = 1; ii < netdef->nForwardIfs; ii++) {
|
2012-08-05 06:45:04 +00:00
|
|
|
if (netdef->forwardIfs[ii].connections < dev->connections)
|
2011-07-04 06:27:12 +00:00
|
|
|
dev = &netdef->forwardIfs[ii];
|
|
|
|
}
|
|
|
|
}
|
|
|
|
/* dev points at the physical device we want to use */
|
|
|
|
if (!dev) {
|
2012-07-18 11:50:10 +00:00
|
|
|
virReportError(VIR_ERR_INTERNAL_ERROR,
|
|
|
|
_("network '%s' requires exclusive access "
|
|
|
|
"to interfaces, but none are available"),
|
|
|
|
netdef->name);
|
2012-08-06 17:45:57 +00:00
|
|
|
goto error;
|
2011-07-04 06:27:12 +00:00
|
|
|
}
|
|
|
|
iface->data.network.actual->data.direct.linkdev = strdup(dev->dev);
|
|
|
|
if (!iface->data.network.actual->data.direct.linkdev) {
|
|
|
|
virReportOOMError();
|
2012-08-06 17:45:57 +00:00
|
|
|
goto error;
|
2011-07-04 06:27:12 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
network: merge relevant virtualports rather than choosing one
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),
2012-08-02 18:10:00 +00:00
|
|
|
if (virNetDevVPortProfileCheckComplete(virtport, true) < 0)
|
2012-08-06 17:45:57 +00:00
|
|
|
goto error;
|
network: merge relevant virtualports rather than choosing one
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),
2012-08-02 18:10:00 +00:00
|
|
|
|
network: make network driver vlan-aware
The network driver now looks for the vlan element in network and
portgroup objects, and logs an error at network define time if a vlan
is requested for a network type that doesn't support it. (Currently
vlan configuration is only supported for openvswitch networks, and
networks used to do hostdev assignment of SR-IOV VFs.)
At runtime, the three potential sources of vlan information are
examined in this order: interface, chosen portgroup, network, and the
first that is non-empty is used. Another check for valid network type
is made at this time, since the interface may have requested a vlan (a
legal thing to have in the interface config, since it's not known
until runtime if the chosen network will actually support it).
Since we must also check for domains requesting vlans for unsupported
connection types even if they are type='network', and since
networkAllocateActualDevice() is being called in exactly the correct
places, and has all of the necessary information to check, I slightly
modified the logic of that function so that interfaces that aren't
type='network' don't just return immediately. Instead, they also
perform all the same validation for supported features. Because of
this, it's not necessary to make this identical check in the other
three places that would normally require it: 1) qemu domain startup,
2) qemu device hotplug, 3) lxc domain startup.
This can be seen as a first step in consolidating network-related
functionality into the network driver, rather than having copies of
the same code spread around in multiple places; this will make it
easier to split the network parts off into a separate daemon, as we've
discussed recently.
2012-08-13 02:46:27 +00:00
|
|
|
/* copy appropriate vlan info to actualNet */
|
|
|
|
if (iface->vlan.nTags > 0)
|
|
|
|
vlan = &iface->vlan;
|
|
|
|
else if (portgroup && portgroup->vlan.nTags > 0)
|
|
|
|
vlan = &portgroup->vlan;
|
|
|
|
else if (netdef && netdef->vlan.nTags > 0)
|
|
|
|
vlan = &netdef->vlan;
|
|
|
|
|
|
|
|
if (virNetDevVlanCopy(&iface->data.network.actual->vlan, vlan) < 0)
|
|
|
|
goto error;
|
|
|
|
|
|
|
|
validate:
|
|
|
|
/* make sure that everything now specified for the device is
|
|
|
|
* actually supported on this type of network. NB: network,
|
|
|
|
* netdev, and iface->data.network.actual may all be NULL.
|
|
|
|
*/
|
|
|
|
|
|
|
|
if (vlan) {
|
|
|
|
/* vlan configuration via libvirt is only supported for
|
|
|
|
* PCI Passthrough SR-IOV devices and openvswitch bridges.
|
|
|
|
* otherwise log an error and fail
|
|
|
|
*/
|
|
|
|
if (!(actualType == VIR_DOMAIN_NET_TYPE_HOSTDEV ||
|
|
|
|
(actualType == VIR_DOMAIN_NET_TYPE_BRIDGE &&
|
|
|
|
virtport && virtport->virtPortType
|
|
|
|
== VIR_NETDEV_VPORT_PROFILE_OPENVSWITCH))) {
|
|
|
|
if (netdef) {
|
|
|
|
virReportError(VIR_ERR_CONFIG_UNSUPPORTED,
|
|
|
|
_("an interface connecting to network '%s' "
|
|
|
|
"is requesting a vlan tag, but that is not "
|
|
|
|
"supported for this type of network"),
|
|
|
|
netdef->name);
|
|
|
|
} else {
|
|
|
|
virReportError(VIR_ERR_CONFIG_UNSUPPORTED,
|
|
|
|
_("an interface of type '%s' "
|
|
|
|
"is requesting a vlan tag, but that is not "
|
|
|
|
"supported for this type of connection"),
|
|
|
|
virDomainNetTypeToString(iface->type));
|
|
|
|
}
|
|
|
|
goto error;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
network: merge relevant virtualports rather than choosing one
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),
2012-08-02 18:10:00 +00:00
|
|
|
if (dev) {
|
|
|
|
/* we are now assured of success, so mark the allocation */
|
2012-08-05 06:45:04 +00:00
|
|
|
dev->connections++;
|
|
|
|
VIR_DEBUG("Using physical device %s, %d connections",
|
|
|
|
dev->dev, dev->connections);
|
network: merge relevant virtualports rather than choosing one
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),
2012-08-02 18:10:00 +00:00
|
|
|
}
|
2012-08-06 20:17:58 +00:00
|
|
|
|
network: make network driver vlan-aware
The network driver now looks for the vlan element in network and
portgroup objects, and logs an error at network define time if a vlan
is requested for a network type that doesn't support it. (Currently
vlan configuration is only supported for openvswitch networks, and
networks used to do hostdev assignment of SR-IOV VFs.)
At runtime, the three potential sources of vlan information are
examined in this order: interface, chosen portgroup, network, and the
first that is non-empty is used. Another check for valid network type
is made at this time, since the interface may have requested a vlan (a
legal thing to have in the interface config, since it's not known
until runtime if the chosen network will actually support it).
Since we must also check for domains requesting vlans for unsupported
connection types even if they are type='network', and since
networkAllocateActualDevice() is being called in exactly the correct
places, and has all of the necessary information to check, I slightly
modified the logic of that function so that interfaces that aren't
type='network' don't just return immediately. Instead, they also
perform all the same validation for supported features. Because of
this, it's not necessary to make this identical check in the other
three places that would normally require it: 1) qemu domain startup,
2) qemu device hotplug, 3) lxc domain startup.
This can be seen as a first step in consolidating network-related
functionality into the network driver, rather than having copies of
the same code spread around in multiple places; this will make it
easier to split the network parts off into a separate daemon, as we've
discussed recently.
2012-08-13 02:46:27 +00:00
|
|
|
if (netdef) {
|
|
|
|
netdef->connections++;
|
|
|
|
VIR_DEBUG("Using network %s, %d connections",
|
|
|
|
netdef->name, netdef->connections);
|
|
|
|
}
|
2011-07-04 06:27:12 +00:00
|
|
|
ret = 0;
|
network: make network driver vlan-aware
The network driver now looks for the vlan element in network and
portgroup objects, and logs an error at network define time if a vlan
is requested for a network type that doesn't support it. (Currently
vlan configuration is only supported for openvswitch networks, and
networks used to do hostdev assignment of SR-IOV VFs.)
At runtime, the three potential sources of vlan information are
examined in this order: interface, chosen portgroup, network, and the
first that is non-empty is used. Another check for valid network type
is made at this time, since the interface may have requested a vlan (a
legal thing to have in the interface config, since it's not known
until runtime if the chosen network will actually support it).
Since we must also check for domains requesting vlans for unsupported
connection types even if they are type='network', and since
networkAllocateActualDevice() is being called in exactly the correct
places, and has all of the necessary information to check, I slightly
modified the logic of that function so that interfaces that aren't
type='network' don't just return immediately. Instead, they also
perform all the same validation for supported features. Because of
this, it's not necessary to make this identical check in the other
three places that would normally require it: 1) qemu domain startup,
2) qemu device hotplug, 3) lxc domain startup.
This can be seen as a first step in consolidating network-related
functionality into the network driver, rather than having copies of
the same code spread around in multiple places; this will make it
easier to split the network parts off into a separate daemon, as we've
discussed recently.
2012-08-13 02:46:27 +00:00
|
|
|
|
2011-07-04 06:27:12 +00:00
|
|
|
cleanup:
|
2011-12-14 10:50:30 +00:00
|
|
|
for (ii = 0; ii < num_virt_fns; ii++)
|
|
|
|
VIR_FREE(vfname[ii]);
|
|
|
|
VIR_FREE(vfname);
|
2011-07-04 06:27:12 +00:00
|
|
|
if (network)
|
|
|
|
virNetworkObjUnlock(network);
|
2012-08-06 17:45:57 +00:00
|
|
|
return ret;
|
|
|
|
|
|
|
|
error:
|
|
|
|
if (iface->type == VIR_DOMAIN_NET_TYPE_NETWORK) {
|
2011-07-04 06:27:12 +00:00
|
|
|
virDomainActualNetDefFree(iface->data.network.actual);
|
|
|
|
iface->data.network.actual = NULL;
|
|
|
|
}
|
2012-08-06 17:45:57 +00:00
|
|
|
goto cleanup;
|
2011-07-04 06:27:12 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/* networkNotifyActualDevice:
|
|
|
|
* @iface: the domain's NetDef with an "actual" device already filled in.
|
|
|
|
*
|
|
|
|
* Called to notify the network driver when libvirtd is restarted and
|
|
|
|
* finds an already running domain. If appropriate it will force an
|
|
|
|
* allocation of the actual->direct.linkdev to get everything back in
|
|
|
|
* order.
|
|
|
|
*
|
|
|
|
* Returns 0 on success, -1 on failure.
|
|
|
|
*/
|
|
|
|
int
|
|
|
|
networkNotifyActualDevice(virDomainNetDefPtr iface)
|
|
|
|
{
|
|
|
|
struct network_driver *driver = driverState;
|
|
|
|
virNetworkObjPtr network;
|
|
|
|
virNetworkDefPtr netdef;
|
2011-11-10 11:18:57 +00:00
|
|
|
const char *actualDev;
|
2011-07-04 06:27:12 +00:00
|
|
|
int ret = -1;
|
|
|
|
|
|
|
|
if (iface->type != VIR_DOMAIN_NET_TYPE_NETWORK)
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
networkDriverLock(driver);
|
|
|
|
network = virNetworkFindByName(&driver->networks, iface->data.network.name);
|
|
|
|
networkDriverUnlock(driver);
|
|
|
|
if (!network) {
|
2012-07-18 11:50:10 +00:00
|
|
|
virReportError(VIR_ERR_NO_NETWORK,
|
|
|
|
_("no network with matching name '%s'"),
|
|
|
|
iface->data.network.name);
|
2012-08-06 17:45:57 +00:00
|
|
|
goto error;
|
|
|
|
}
|
|
|
|
netdef = network->def;
|
|
|
|
|
|
|
|
if (!iface->data.network.actual ||
|
|
|
|
(virDomainNetGetActualType(iface) != VIR_DOMAIN_NET_TYPE_DIRECT)) {
|
|
|
|
VIR_DEBUG("Nothing to claim from network %s", iface->data.network.name);
|
|
|
|
goto success;
|
2011-07-04 06:27:12 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
actualDev = virDomainNetGetActualDirectDev(iface);
|
|
|
|
if (!actualDev) {
|
2012-07-18 11:50:10 +00:00
|
|
|
virReportError(VIR_ERR_INTERNAL_ERROR,
|
|
|
|
"%s", _("the interface uses a direct "
|
|
|
|
"mode, but has no source dev"));
|
2012-08-06 17:45:57 +00:00
|
|
|
goto error;
|
2011-11-10 11:18:57 +00:00
|
|
|
}
|
2011-07-04 06:27:12 +00:00
|
|
|
|
|
|
|
if (netdef->nForwardIfs == 0) {
|
2012-07-18 11:50:10 +00:00
|
|
|
virReportError(VIR_ERR_INTERNAL_ERROR,
|
|
|
|
_("network '%s' uses a direct mode, but "
|
|
|
|
"has no forward dev and no interface pool"),
|
|
|
|
netdef->name);
|
2012-08-06 17:45:57 +00:00
|
|
|
goto error;
|
2011-07-04 06:27:12 +00:00
|
|
|
} else {
|
|
|
|
int ii;
|
|
|
|
virNetworkForwardIfDefPtr dev = NULL;
|
|
|
|
|
2012-08-05 06:45:04 +00:00
|
|
|
/* find the matching interface and increment its connections */
|
2011-07-04 06:27:12 +00:00
|
|
|
|
|
|
|
for (ii = 0; ii < netdef->nForwardIfs; ii++) {
|
|
|
|
if (STREQ(actualDev, netdef->forwardIfs[ii].dev)) {
|
|
|
|
dev = &netdef->forwardIfs[ii];
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
/* dev points at the physical device we want to use */
|
|
|
|
if (!dev) {
|
2012-07-18 11:50:10 +00:00
|
|
|
virReportError(VIR_ERR_INTERNAL_ERROR,
|
|
|
|
_("network '%s' doesn't have dev='%s' in use by domain"),
|
|
|
|
netdef->name, actualDev);
|
2012-08-06 17:45:57 +00:00
|
|
|
goto error;
|
2011-07-04 06:27:12 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/* PASSTHROUGH mode, and PRIVATE Mode + 802.1Qbh both require
|
2012-08-05 06:45:04 +00:00
|
|
|
* exclusive access to a device, so current connections count
|
|
|
|
* must be 0 in those cases.
|
2011-07-04 06:27:12 +00:00
|
|
|
*/
|
2012-08-05 06:45:04 +00:00
|
|
|
if ((dev->connections > 0) &&
|
2011-07-04 06:27:12 +00:00
|
|
|
((netdef->forwardType == VIR_NETWORK_FORWARD_PASSTHROUGH) ||
|
|
|
|
((netdef->forwardType == VIR_NETWORK_FORWARD_PRIVATE) &&
|
2012-07-30 06:03:25 +00:00
|
|
|
iface->data.network.actual->virtPortProfile &&
|
|
|
|
(iface->data.network.actual->virtPortProfile->virtPortType
|
2011-11-02 14:43:16 +00:00
|
|
|
== VIR_NETDEV_VPORT_PROFILE_8021QBH)))) {
|
2012-07-18 11:50:10 +00:00
|
|
|
virReportError(VIR_ERR_INTERNAL_ERROR,
|
|
|
|
_("network '%s' claims dev='%s' is already in use by a different domain"),
|
|
|
|
netdef->name, actualDev);
|
2012-08-06 17:45:57 +00:00
|
|
|
goto error;
|
2011-07-04 06:27:12 +00:00
|
|
|
}
|
|
|
|
/* we are now assured of success, so mark the allocation */
|
2012-08-05 06:45:04 +00:00
|
|
|
dev->connections++;
|
|
|
|
VIR_DEBUG("Using physical device %s, %d connections",
|
|
|
|
dev->dev, dev->connections);
|
2011-07-04 06:27:12 +00:00
|
|
|
}
|
|
|
|
|
2012-08-06 17:45:57 +00:00
|
|
|
success:
|
2012-08-06 20:17:58 +00:00
|
|
|
netdef->connections++;
|
|
|
|
VIR_DEBUG("Using network %s, %d connections",
|
|
|
|
netdef->name, netdef->connections);
|
2011-07-04 06:27:12 +00:00
|
|
|
ret = 0;
|
|
|
|
cleanup:
|
|
|
|
if (network)
|
|
|
|
virNetworkObjUnlock(network);
|
|
|
|
return ret;
|
2012-08-06 17:45:57 +00:00
|
|
|
|
|
|
|
error:
|
|
|
|
goto cleanup;
|
2011-07-04 06:27:12 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
/* networkReleaseActualDevice:
|
|
|
|
* @iface: a domain's NetDef (interface definition)
|
|
|
|
*
|
|
|
|
* Given a domain <interface> element that previously had its <actual>
|
|
|
|
* element filled in (and possibly a physical device allocated to it),
|
|
|
|
* free up the physical device for use by someone else, and free the
|
|
|
|
* virDomainActualNetDef.
|
|
|
|
*
|
|
|
|
* Returns 0 on success, -1 on failure.
|
|
|
|
*/
|
|
|
|
int
|
|
|
|
networkReleaseActualDevice(virDomainNetDefPtr iface)
|
|
|
|
{
|
|
|
|
struct network_driver *driver = driverState;
|
2012-08-06 17:45:57 +00:00
|
|
|
virNetworkObjPtr network;
|
2011-07-04 06:27:12 +00:00
|
|
|
virNetworkDefPtr netdef;
|
2011-11-10 11:18:57 +00:00
|
|
|
const char *actualDev;
|
2011-07-04 06:27:12 +00:00
|
|
|
int ret = -1;
|
|
|
|
|
|
|
|
if (iface->type != VIR_DOMAIN_NET_TYPE_NETWORK)
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
networkDriverLock(driver);
|
|
|
|
network = virNetworkFindByName(&driver->networks, iface->data.network.name);
|
|
|
|
networkDriverUnlock(driver);
|
|
|
|
if (!network) {
|
2012-07-18 11:50:10 +00:00
|
|
|
virReportError(VIR_ERR_NO_NETWORK,
|
|
|
|
_("no network with matching name '%s'"),
|
|
|
|
iface->data.network.name);
|
2012-08-06 17:45:57 +00:00
|
|
|
goto error;
|
|
|
|
}
|
|
|
|
netdef = network->def;
|
|
|
|
|
|
|
|
if (!iface->data.network.actual ||
|
|
|
|
(virDomainNetGetActualType(iface) != VIR_DOMAIN_NET_TYPE_DIRECT)) {
|
|
|
|
VIR_DEBUG("Nothing to release to network %s", iface->data.network.name);
|
|
|
|
goto success;
|
2011-07-04 06:27:12 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
actualDev = virDomainNetGetActualDirectDev(iface);
|
|
|
|
if (!actualDev) {
|
2012-07-18 11:50:10 +00:00
|
|
|
virReportError(VIR_ERR_INTERNAL_ERROR,
|
|
|
|
"%s", _("the interface uses a direct "
|
|
|
|
"mode, but has no source dev"));
|
2012-08-06 17:45:57 +00:00
|
|
|
goto error;
|
2011-11-10 11:18:57 +00:00
|
|
|
}
|
2011-07-04 06:27:12 +00:00
|
|
|
|
|
|
|
if (netdef->nForwardIfs == 0) {
|
2012-07-18 11:50:10 +00:00
|
|
|
virReportError(VIR_ERR_INTERNAL_ERROR,
|
|
|
|
_("network '%s' uses a direct mode, but "
|
|
|
|
"has no forward dev and no interface pool"),
|
|
|
|
netdef->name);
|
2012-08-06 17:45:57 +00:00
|
|
|
goto error;
|
2011-07-04 06:27:12 +00:00
|
|
|
} else {
|
|
|
|
int ii;
|
|
|
|
virNetworkForwardIfDefPtr dev = NULL;
|
|
|
|
|
|
|
|
for (ii = 0; ii < netdef->nForwardIfs; ii++) {
|
|
|
|
if (STREQ(actualDev, netdef->forwardIfs[ii].dev)) {
|
|
|
|
dev = &netdef->forwardIfs[ii];
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
/* dev points at the physical device we've been using */
|
|
|
|
if (!dev) {
|
2012-07-18 11:50:10 +00:00
|
|
|
virReportError(VIR_ERR_INTERNAL_ERROR,
|
|
|
|
_("network '%s' doesn't have dev='%s' in use by domain"),
|
|
|
|
netdef->name, actualDev);
|
2012-08-06 17:45:57 +00:00
|
|
|
goto error;
|
2011-07-04 06:27:12 +00:00
|
|
|
}
|
|
|
|
|
2012-08-05 06:45:04 +00:00
|
|
|
dev->connections--;
|
|
|
|
VIR_DEBUG("Releasing physical device %s, %d connections",
|
|
|
|
dev->dev, dev->connections);
|
2011-07-04 06:27:12 +00:00
|
|
|
}
|
|
|
|
|
2012-08-06 17:45:57 +00:00
|
|
|
success:
|
2012-08-06 20:17:58 +00:00
|
|
|
netdef->connections--;
|
|
|
|
VIR_DEBUG("Releasing network %s, %d connections",
|
|
|
|
netdef->name, netdef->connections);
|
2011-07-04 06:27:12 +00:00
|
|
|
ret = 0;
|
|
|
|
cleanup:
|
|
|
|
if (network)
|
|
|
|
virNetworkObjUnlock(network);
|
2012-08-06 17:45:57 +00:00
|
|
|
if (iface->type == VIR_DOMAIN_NET_TYPE_NETWORK) {
|
|
|
|
virDomainActualNetDefFree(iface->data.network.actual);
|
|
|
|
iface->data.network.actual = NULL;
|
|
|
|
}
|
2011-07-04 06:27:12 +00:00
|
|
|
return ret;
|
2012-08-06 17:45:57 +00:00
|
|
|
|
|
|
|
error:
|
|
|
|
goto cleanup;
|
2011-07-04 06:27:12 +00:00
|
|
|
}
|
2011-07-07 04:24:08 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* networkGetNetworkAddress:
|
|
|
|
* @netname: the name of a network
|
|
|
|
* @netaddr: string representation of IP address for that network.
|
|
|
|
*
|
|
|
|
* Attempt to return an IP (v4) address associated with the named
|
|
|
|
* network. If a libvirt virtual network, that will be provided in the
|
|
|
|
* configuration. For host bridge and direct (macvtap) networks, we
|
|
|
|
* must do an ioctl to learn the address.
|
|
|
|
*
|
|
|
|
* Note: This function returns the 1st IPv4 address it finds. It might
|
|
|
|
* be useful if it was more flexible, but the current use (getting a
|
|
|
|
* listen address for qemu's vnc/spice graphics server) can only use a
|
|
|
|
* single address anyway.
|
|
|
|
*
|
|
|
|
* Returns 0 on success, and puts a string (which must be free'd by
|
|
|
|
* the caller) into *netaddr. Returns -1 on failure or -2 if
|
|
|
|
* completely unsupported.
|
|
|
|
*/
|
|
|
|
int
|
|
|
|
networkGetNetworkAddress(const char *netname, char **netaddr)
|
|
|
|
{
|
|
|
|
int ret = -1;
|
|
|
|
struct network_driver *driver = driverState;
|
2012-08-06 17:45:57 +00:00
|
|
|
virNetworkObjPtr network;
|
2011-07-07 04:24:08 +00:00
|
|
|
virNetworkDefPtr netdef;
|
|
|
|
virNetworkIpDefPtr ipdef;
|
|
|
|
virSocketAddr addr;
|
|
|
|
virSocketAddrPtr addrptr = NULL;
|
2011-09-16 12:05:58 +00:00
|
|
|
char *dev_name = NULL;
|
2011-07-07 04:24:08 +00:00
|
|
|
|
|
|
|
*netaddr = NULL;
|
|
|
|
networkDriverLock(driver);
|
|
|
|
network = virNetworkFindByName(&driver->networks, netname);
|
|
|
|
networkDriverUnlock(driver);
|
|
|
|
if (!network) {
|
2012-07-18 11:50:10 +00:00
|
|
|
virReportError(VIR_ERR_NO_NETWORK,
|
|
|
|
_("no network with matching name '%s'"),
|
|
|
|
netname);
|
2012-08-06 17:45:57 +00:00
|
|
|
goto error;
|
2011-07-07 04:24:08 +00:00
|
|
|
}
|
|
|
|
netdef = network->def;
|
|
|
|
|
|
|
|
switch (netdef->forwardType) {
|
|
|
|
case VIR_NETWORK_FORWARD_NONE:
|
|
|
|
case VIR_NETWORK_FORWARD_NAT:
|
|
|
|
case VIR_NETWORK_FORWARD_ROUTE:
|
|
|
|
/* if there's an ipv4def, get it's address */
|
|
|
|
ipdef = virNetworkDefGetIpByIndex(netdef, AF_INET, 0);
|
|
|
|
if (!ipdef) {
|
2012-07-18 11:50:10 +00:00
|
|
|
virReportError(VIR_ERR_INTERNAL_ERROR,
|
|
|
|
_("network '%s' doesn't have an IPv4 address"),
|
|
|
|
netdef->name);
|
2011-07-07 04:24:08 +00:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
addrptr = &ipdef->address;
|
|
|
|
break;
|
|
|
|
|
|
|
|
case VIR_NETWORK_FORWARD_BRIDGE:
|
2011-09-16 12:05:58 +00:00
|
|
|
if ((dev_name = netdef->bridge))
|
2011-07-07 04:24:08 +00:00
|
|
|
break;
|
|
|
|
/*
|
|
|
|
* fall through if netdef->bridge wasn't set, since this is
|
|
|
|
* also a direct-mode interface.
|
|
|
|
*/
|
|
|
|
case VIR_NETWORK_FORWARD_PRIVATE:
|
|
|
|
case VIR_NETWORK_FORWARD_VEPA:
|
|
|
|
case VIR_NETWORK_FORWARD_PASSTHROUGH:
|
|
|
|
if ((netdef->nForwardIfs > 0) && netdef->forwardIfs)
|
2011-09-16 12:05:58 +00:00
|
|
|
dev_name = netdef->forwardIfs[0].dev;
|
2011-07-07 04:24:08 +00:00
|
|
|
|
2011-09-16 12:05:58 +00:00
|
|
|
if (!dev_name) {
|
2012-07-18 11:50:10 +00:00
|
|
|
virReportError(VIR_ERR_INTERNAL_ERROR,
|
|
|
|
_("network '%s' has no associated interface or bridge"),
|
|
|
|
netdef->name);
|
2011-07-07 04:24:08 +00:00
|
|
|
}
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
2011-09-16 12:05:58 +00:00
|
|
|
if (dev_name) {
|
2011-11-03 10:31:01 +00:00
|
|
|
if (virNetDevGetIPv4Address(dev_name, &addr) < 0)
|
2012-08-06 17:45:57 +00:00
|
|
|
goto error;
|
2011-11-03 10:31:01 +00:00
|
|
|
addrptr = &addr;
|
2011-07-07 04:24:08 +00:00
|
|
|
}
|
|
|
|
|
2012-08-06 17:45:57 +00:00
|
|
|
if (!(addrptr &&
|
|
|
|
(*netaddr = virSocketAddrFormat(addrptr)))) {
|
|
|
|
goto error;
|
2011-07-07 04:24:08 +00:00
|
|
|
}
|
|
|
|
|
2012-08-06 17:45:57 +00:00
|
|
|
ret = 0;
|
2011-07-07 04:24:08 +00:00
|
|
|
cleanup:
|
|
|
|
if (network)
|
|
|
|
virNetworkObjUnlock(network);
|
|
|
|
return ret;
|
2012-08-06 17:45:57 +00:00
|
|
|
|
|
|
|
error:
|
|
|
|
goto cleanup;
|
2011-07-07 04:24:08 +00:00
|
|
|
}
|