- 09 3月, 2015 2 次提交
-
-
由 Michal Privoznik 提交于
Well, one day this will be self-locking object, but not today. But lets prepare the code for that! Moreover, virNetworkObjListFree() is no longer needed, so turn it into virNetworkObjListDispose(). Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Michal Privoznik 提交于
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
- 04 3月, 2015 7 次提交
-
-
由 Michal Privoznik 提交于
It's returning virNetworkObjPtr after all. And it matches the pattern laid out by domain_conf.h. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Michal Privoznik 提交于
It's returning virNetworkObjPtr after all. And it matches the pattern laid out by domain_conf.h. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Michal Privoznik 提交于
In order to hide the object internals (and use just accessors everywhere), lets store a pointer to the object, instead of object itself. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Michal Privoznik 提交于
Instead of copying the whole object onto stack when calling the function, just pass the pointer to the object and save up some space on the stack. Moreover, this prepares the code to hide the virNetworkObjList structure into network_conf.c and use accessors only. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Michal Privoznik 提交于
Moreover, there are two points within the function, where we're missing 'goto cleanup'. Fix this too. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Michal Privoznik 提交于
Okay, this is mainly for educational purposes since is called from single point only with all the possible locks held. So there's no way for other thread to hop in and do something wrong. Nevertheless, we should not give bad example. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Michal Privoznik 提交于
We have this function networkObjFromNetwork() which for given virNetworkPtr tries to find corresponding virNetworkObjPtr. If no object is found, a nice error message is printed out: no network with matching uuid '$uuid' ($name) Let's improve the error message produced by networkLookupByUUID to follow that logic. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
- 26 2月, 2015 1 次提交
-
-
由 Laine Stump 提交于
libvirt was unconditionally calling virNetDevBandwidthClear() for every interface (and network bridge) of a type that supported bandwidth, whether it actually had anything set or not. This doesn't hurt anything (unless ifname == NULL!), but is wasteful. This patch makes sure that all calls to virNetDevBandwidthClear() are qualified by checking that the interface really had some bandwidth setup done, and checks for a null ifname inside virNetDevBandwidthClear(), silently returning success if it is null (as well as removing the ATTRIBUTE_NONNULL from that function's prototype, since we can't guarantee that it is never null, e.g. sometimes a type='ethernet' interface has no ifname as it is provided on the fly by qemu).
-
- 21 2月, 2015 1 次提交
-
-
由 Laine Stump 提交于
The function that parses the <forward> subelement of a network used to fail/log an error if the network definition contained both a <pf> element as well as at least one <interface> or <address> element. That check was present because the configuration of a network should have either one <pf>, one or more <interface>, or one or more <address>, but never combinations of multiple kinds. This caused a problem when libvirtd was restarted with a network already active - when a network with a <pf> element is started, the referenced PF (Physical Function of an SRIOV-capable network card) is checked for VFs (Virtual Functions), and the <forward> is filled in with a list of all VFs for that PF either in the form of their PCI addresses (a list of <address>) or their netdev names (a list of <interface>); the <pf> element is not removed though. When libvirtd is restarted, it parses the network status and finds both the original <pf> from the config, as well as the list of either <address> or <interface>, fails the parse, and the network is not added to the active list. This failure is often obscured because the network is marked as autostart so libvirt immediately restarts it. It seems odd to me that <interface> and <address> are stored in the same array rather than keeping two separate arrays, and having separate arrays would have made the check much simpler. However, changing to use two separate arrays would have required changes in more places, potentially creating more conflicts and (more importantly) more possible regressions in the event of a backport, so I chose to keep the existing data structure in order to localize the change. It appears that this problem has been in the code ever since support for <pf> was added (0.9.10), but until commit 34cc3b2f (first in libvirt 1.2.4) networks with interface pools were not properly marked as active on restart anyway, so there is no point in backporting this patch any further than that.
-
- 19 2月, 2015 1 次提交
-
-
由 Jiri Denemark 提交于
Not all files we want to find using virFileFindResource{,Full} are generated when libvirt is built, some of them (such as RNG schemas) are distributed with sources. The current API was not able to find source files if libvirt was built in VPATH. Both RNG schemas and cpu_map.xml are distributed in source tarball. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
- 06 2月, 2015 1 次提交
-
-
由 Laine Stump 提交于
When defining and creating networks, we have been checking to make sure there is only a single "default" portgroup, but haven't verified that no two portgroups have the same name. We *do* check for multiple definitions when updating the portgroups in an existing network though. This patch adds a check to networkValidate(), which is called when a network is defined or created, to disallow duplicate names. It would actually make sense to do this in the network XML parser (since it's not really "something that might make sense but isn't supported by this driver", but is instead "something that should never be allowed"), but doing that carries the danger of causing errors when rereading the config of existing networks when libvirtd is restarted after an upgrade, and that would result in networks disappearing from libvirt's list. (I'm thinking I should change the error to "XML_ERROR" instead of "UNSUPPORTED", even though that's not the type of error that networkValidate is intended for) This resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1115858
-
- 27 1月, 2015 1 次提交
-
-
由 Daniel P. Berrange 提交于
For stateless, client side drivers, it is never correct to probe for secondary drivers. It is only ever appropriate to use the secondary driver that is associated with the hypervisor in question. As a result the ESX & HyperV drivers have both been forced to do hacks where they register no-op drivers for the ones they don't implement. For stateful, server side drivers, we always just want to use the same built-in shared driver. The exception is virtualbox which is really a stateless driver and so wants to use its own server side secondary drivers. To deal with this virtualbox has to be built as 3 separate loadable modules to allow registration to work in the right order. This can all be simplified by introducing a new struct recording the precise set of secondary drivers each hypervisor driver wants struct _virConnectDriver { virHypervisorDriverPtr hypervisorDriver; virInterfaceDriverPtr interfaceDriver; virNetworkDriverPtr networkDriver; virNodeDeviceDriverPtr nodeDeviceDriver; virNWFilterDriverPtr nwfilterDriver; virSecretDriverPtr secretDriver; virStorageDriverPtr storageDriver; }; Instead of registering the hypervisor driver, we now just register a virConnectDriver instead. This allows us to remove all probing of secondary drivers. Once we have chosen the primary driver, we immediately know the correct secondary drivers to use. Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
- 20 1月, 2015 1 次提交
-
-
由 Josh Stone 提交于
This adds a new "localOnly" attribute on the domain element of the network xml. With this set to "yes", DNS requests under that domain will only be resolved by libvirt's dnsmasq, never forwarded upstream. This was how it worked before commit f69a6b98, and I found that functionality useful. For example, I have my host's NetworkManager dnsmasq configured to forward that domain to libvirt's dnsmasq, so I can easily resolve guest names from outside. But if libvirt's dnsmasq doesn't know a name and forwards it to the host, I'd get an endless forwarding loop. Now I can set localOnly="yes" to prevent the loop. Signed-off-by: NJosh Stone <jistone@redhat.com>
-
- 16 1月, 2015 1 次提交
-
-
由 Cédric Bosdonnat 提交于
Moving code for parsing and formatting network routes to networkcommon_conf helps reusing those routes for domains. The route definition has been hidden to help reducing the number of unnecessary checks in the format function.
-
- 06 1月, 2015 2 次提交
-
-
由 Nehal J Wani 提交于
Lack of a lease (whether mac is given or not) is a normal expected scenario, since we are already filling in rv with nleases (which is okay as 0 if there is no lease). There is no need to raise an error. This fixes: > virsh # net-dhcp-leases --mac 00:50:56:c0:00:01 default > error: Failed to get leases info for default > error: internal error: no lease with matching MAC address: 00:50:56:c0:00:01 Signed-off-by: NNehal J Wani <nehaljw.kkd1@gmail.com> Signed-off-by: NEric Blake <eblake@redhat.com>
-
由 Cédric Bosdonnat 提交于
Renamed virNetDevSetIPv4Address as it also handles IPv6 addresses.
-
- 09 12月, 2014 3 次提交
-
-
由 Laine Stump 提交于
When the bridge device for a network has macTableManager='libvirt' the intent is that all kernel management of the bridge's MAC table (Forwarding Database, or fdb, in the case of a Linux Host Bridge) be disabled, with libvirt handling updates to the table instead. The setup required for the bridge itself is: 1) set the "vlan_filtering" property of the bridge device to 1. 2) If the bridge has a "Dummy" tap device used to set a fixed MAC address on the bridge (which is always the case for a bridge created by libvirt, and never the case for a bridge created by the host system network config), turn off learning and unicast_flood on this tap (this is needed even though this tap is never IFF_UP, because the kernel ignores the IFF_UP flag of devices when using their settings to automatically decide whether or not to turn off promiscuous mode for any attached device). (1) is done both for libvirt-created/managed bridges, and for bridges that are created by the host system config, while (2) is done only for bridges created by libvirt (i.e. for forward modes of nat, routed, and isolated bridges) There is no attempt to turn vlan_filtering off when destroying the network because in the case of a libvirt-created bridge, the bridge is about to be destroyed anyway, and in the case of a system bridge, if the other devices attached to the bridge could operate properly before destroying libvirt's network object, they will continue to operate properly (this is similar to the way that libvirt will enable ip_forwarding whenever a routed/natted network is started, but will never attempt to disable it if they are stopped).
-
由 Laine Stump 提交于
At the time that the network driver allocates a connection to a network, the tap device that will be used hasn't yet been created - that will be done later by qemu (or lxc or whoever) - but if the network has macTableManager='libvirt', then when we do get around to creating the tap device, we will need to add an entry for it to the network bridge's fdb (forwarding database) *and* turn off learning and unicast_flood for that tap device in the bridge's sysfs settings. This means that qemu needs to know both the bridge name as well as the setting of macTableManager, so we either need to create a new API to retrieve that info, or just pass it back in the ActualNetDef that is created during networkAllocateActualDevice. We choose the latter method, since it's already done for the bridge device, and it has the side effect of making the information available in domain status. (NB: in the future, I think that the tap device should actually be created by networkAllocateActualDevice(), as that will solve several other problems, but that is a battle for another day, and this information will still be useful outside the network driver)
-
由 Laine Stump 提交于
When the actualType of a virDomainNetDef is "network", it means that we are connecting to a libvirt-managed network (routed, natted, or isolated) which does use a bridge device (created by libvirt). In the past we have required drivers such as qemu to call the public API to retrieve the bridge name in this case (even though it is available in the NetDef's ActualNetDef if the actualType is "bridge" (i.e., an externally-created bridge that isn't managed by libvirt). There is no real reason for this difference, and as a matter of fact it complicates things for qemu. Also, there is another bridge-related attribute (macTableManager) that will need to be available in both cases, so this makes things consistent. In order to avoid problems when restarting libvirtd after an update from an older version that *doesn't* store the network's bridgename in the ActualNetDef, we also need to put it in place during networkNotifyActualDevice() (this function is run for each interface of each domain whenever libvirtd is restarted). Along with making the bridge name available in the internal object, it is also now reported in the <source> element of the <interface> state XML (or the <actual> subelement in the internally-stored format). The one oddity about this change is that usually there is a separate union for every different "type" in a higher level object (e.g. in the case of a virDomainNetDef there are separate "network" and "bridge" members of the union that pivots on the type), but in this case network and bridge types both have exactly the same attributes, so the "bridge" member is used for both type==network and type==bridge.
-
- 05 12月, 2014 1 次提交
-
-
由 Michal Privoznik 提交于
https://bugzilla.redhat.com/show_bug.cgi?id=1115292 In one of the previous commits (eafb53fe) we disallowed network-wide bandwidth to some network types. However, we forgot about <portgroups/> which can have <bandwidth/> too. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
- 03 12月, 2014 2 次提交
-
-
由 Peter Krempa 提交于
Now that we don't use the leases file at all for leases just don't format it into the config and use the leaseshelper to do all the lifting.
-
由 Nehal J Wani 提交于
This patch enables the helper program to detect event(s) triggered when there is a change in lease length or expiry and client-id. This transfers complete control of leases database to libvirt and obsoletes use of the lease database file (<network-name>.leases). That file will not be created, read, or written. This is achieved by adding the option --leasefile-ro to dnsmasq and passing a custom env var to leaseshelper, which helps us map events related to leases with their corresponding network bridges, no matter what the event be. Also, this requires the addition of a new non-lease entry in our custom lease database: "server-duid". It is required to identify a DHCPv6 server. Now that dnsmasq doesn't maintain its own leases database, it relies on our helper program to tell it about previous leases and server duid. Thus, this patch makes our leases program honor an extra action: "init", in which it sends the known info in a particular format to dnsmasq by printing it to stdout. The drawback of this change is that upgrade to this new approach does not transfer the existing leases for the network if the leaseshelper wasn't already used.
-
- 27 11月, 2014 1 次提交
-
-
由 Jiri Denemark 提交于
Starting from libvirt-1.2.4, network state XML files moved to another directory (see commit b9e95491) and libvirt automatically migrates the network state files to a new location. However, the code used dirent.d_type which is not supported by all filesystems. Thus, when libvirt was upgraded on a host which used such filesystem, network state XMLs were not properly moved and running networks disappeared from libvirt. This patch falls back to lstat() whenever dirent.d_type is DT_UNKNOWN to fix this issue. https://bugzilla.redhat.com/show_bug.cgi?id=1167145Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
- 15 11月, 2014 1 次提交
-
-
由 Martin Kletzander 提交于
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
-
- 07 11月, 2014 1 次提交
-
-
由 Daniel P. Berrange 提交于
The shared network driver is stateful and inside the daemon so there is no need to use the networkPrivateData field to get the driver handle. Just access the global driver handle directly. Many places already directly accessed the global driver handle in any case, so the code could never work without relying on this.
-
- 06 11月, 2014 1 次提交
-
-
由 Luyao Huang 提交于
When start a network fail, libvirt still call virNetworkEventLifecycleNew to send a event. Signed-off-by: NLuyao Huang <lhuang@redhat.com>
-
- 29 10月, 2014 1 次提交
-
-
由 Eric Blake 提交于
C guarantees that static variables are zero-initialized. Some older compilers (and also gcc -fno-zero-initialized-in-bss) create larger binaries if you explicitly zero-initialize a static variable. * src/conf/nwfilter_conf.c: Fix initialization. * src/cpu/cpu_x86.c: Likewise. * src/interface/interface_backend_netcf.c: Likewise. * src/locking/lock_daemon.c: Likewise. * src/locking/lock_driver_lockd.c: Likewise. * src/locking/lock_driver_sanlock.c: Likewise. * src/network/bridge_driver.c: Likewise. * src/node_device/node_device_udev.c: Likewise. * src/nwfilter/nwfilter_learnipaddr.c: Likewise. * src/rpc/virnetserver.c: Likewise. * src/security/security_selinux.c (virSecuritySELinuxGenSecurityLabel): Likewise. Signed-off-by: NEric Blake <eblake@redhat.com>
-
- 06 10月, 2014 1 次提交
-
-
由 Laine Stump 提交于
As is done with other items such as vlan, virtualport, and bandwidth, set the actual trustGuestRxFilters value to be used by a domain interface according to a merge of the same attribute in the interface, portgroup, and network in use. the interface setting always takes precedence (if specified), followed by portgroup, and finally the setting in the network is used if it's not specified in the interface or portgroup.
-
- 16 9月, 2014 1 次提交
-
-
由 Ján Tomko 提交于
Pass the user-specified tun path down when creating tap device when called from the qemu driver. Also honor the vhost device path specified by user.
-
- 05 9月, 2014 1 次提交
-
-
由 Eric Blake 提交于
Our style overwhelmingly uses hanging braces (the open brace hangs at the end of the compound condition, rather than on its own line), with the primary exception of the top level function body. Fix the few remaining outliers, before adding a syntax check in a later patch. * src/interface/interface_backend_netcf.c (netcfStateReload) (netcfInterfaceClose, netcf_to_vir_err): Correct use of { in compound statement. * src/conf/domain_conf.c (virDomainHostdevDefFormatSubsys) (virDomainHostdevDefFormatCaps): Likewise. * src/network/bridge_driver.c (networkAllocateActualDevice): Likewise. * src/util/virfile.c (virBuildPathInternal): Likewise. * src/util/virnetdev.c (virNetDevGetVirtualFunctions): Likewise. * src/util/virnetdevmacvlan.c (virNetDevMacVLanVPortProfileCallback): Likewise. * src/util/virtypedparam.c (virTypedParameterAssign): Likewise. * src/util/virutil.c (virGetWin32DirectoryRoot) (virFileWaitForDevices): Likewise. * src/vbox/vbox_common.c (vboxDumpNetwork): Likewise. * tests/seclabeltest.c (main): Likewise. Signed-off-by: NEric Blake <eblake@redhat.com>
-
- 04 9月, 2014 1 次提交
-
-
由 Eric Blake 提交于
I'm about to add a syntax check that enforces our documented HACKING style of always using matching {} on if-else statements. This patch focuses on code shared between multiple drivers. * src/conf/domain_conf.c (virDomainFSDefParseXML) (virSysinfoParseXML, virDomainNetDefParseXML) (virDomainWatchdogDefParseXML) (virDomainRedirFilterUSBDevDefParseXML): Correct use of {}. * src/conf/interface_conf.c (virInterfaceDefParseDhcp) (virInterfaceDefParseIp, virInterfaceVlanDefFormat) (virInterfaceDefParseStartMode, virInterfaceDefParseBondMode) (virInterfaceDefParseBondMiiCarrier) (virInterfaceDefParseBondArpValid): Likewise. * src/conf/node_device_conf.c (virNodeDevCapStorageParseXML): Likewise. * src/conf/nwfilter_conf.c (virNWFilterRuleDetailsParse) (virNWFilterRuleParse, virNWFilterDefParseXML): Likewise. * src/conf/secret_conf.c (secretXMLParseNode): Likewise. * src/cpu/cpu_x86.c (x86Baseline, x86FeatureLoad, x86ModelLoad): Likewise. * src/network/bridge_driver.c (networkKillDaemon) (networkDnsmasqConfContents): Likewise. * src/node_device/node_device_hal.c (dev_refresh): Likewise. * src/nwfilter/nwfilter_gentech_driver.c (virNWFilterInstantiate): Likewise. * src/nwfilter/nwfilter_ebiptables_driver.c (_iptablesCreateRuleInstance): Likewise. * src/storage/storage_backend_disk.c (virStorageBackendDiskBuildPool): Likewise. Signed-off-by: NEric Blake <eblake@redhat.com>
-
- 28 8月, 2014 1 次提交
-
-
由 John Ferlan 提交于
In the error path the 'ipaddr' wasn't VIR_FREE'd before jumping to cleanup
-
- 15 8月, 2014 1 次提交
-
-
由 Laine Stump 提交于
Martin Kletzander pointed out in email that my commit 2a193f64 introduced a crash in networkCreateInterfacePool() during startup of any network that doesn't have a <pf> subelement of its <forward> element. He also supplied a patch. http://www.redhat.com/archives/libvir-list/2014-August/msg00655.html I expanded on that patch by cleaning up now-extraneous checks in the callers of networkCreateInterfacePool(). Fortunately the offending patch hasn't been in any release, and hasn't been (to my knowledge) backported to any other branch.
-
- 12 8月, 2014 2 次提交
-
-
由 Laine Stump 提交于
When a network is defined with "<pf dev='xyz'/>", libvirt will query sysfs to learn the list of all virtual functions (VF) associated with that Physical Function (PF) then populate the network's interface pool accordingly. This action was previously done only when the first guest actually requested an interface from the network. This patch changes it to populate the pool immediately when the network is started. This way any problems with the PF or its VFs will become apparent sooner. Note that we can't remove the old calls to networkCreateInterfacePool that happen whenever a guest requests an interface - doing so would be asking for failures on hosts that had libvirt upgraded with a network that had been started but not yet used. This resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1047818
-
由 Laine Stump 提交于
networkCreateInterfacePool was a bit loose in its error cleanup, which could result in a network definition with interfaces in the pool that were NULL. This would in turn lead to a libvirtd crash when a guest tried to attach an interface using the network with that pool. In particular this would happen when creating a pool to be used for macvtap connections. macvtap needs the netdev name of the virtual function in order to use it, and each VF only has a netdev name if it is currently bound to a network driver. If one of the VFs of a PF happened to be bound to the pci-stub or vfio-pci driver (indicating it's already in use for PCI passthrough), or no driver at all, it would have no name. In this case networkCreateInterfacePool would return an error, but would leave the netdef->forward.nifs set to the total number of VFs in the PF. The interface attach that triggered calling of networkCreateInterfacePool (it uses a "lazy fill" strategy) would simply fail, but the very next attempt to attach an interface using the same network pool would result in a crash. This patch refactors networkCreateInterfacePool to bring it more in line with current coding practices (label name, use of a switch with no default case) as well as providing the following two changes to behavior: 1) If a VF with no netdev name is encountered, just log a warning and continue; only fail if exactly 0 devices are found to put in the pool. 2) If the function fails, clean up any partial interface pool and set netdef->forward.nifs to 0. This resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1111455
-
- 04 8月, 2014 1 次提交
-
-
由 Ján Tomko 提交于
Otherwise this beautiful error would be overwritten when the function is called with a really high rate number: 2014-07-28 12:51:47.920+0000: 2304: error : virCommandWait:2399 : internal error: Child process (/sbin/tc class add dev vnet0 parent 1: classid 1:1 htb rate 4294968kbps) unexpected exit status 1: Illegal "rate" Usage: ... qdisc add ... htb [default N] [r2q N] default minor id of class to which unclassified packets are sent {0} r2q DRR quantums are computed as rate in Bps/r2q {10} debug string of 16 numbers each 0-3 {0} ... class add ... htb rate R1 [burst B1] [mpu B] [overhead O] [prio P] [slot S] [pslot PS] [ceil R2] [cburst B2] [mtu MTU] [quantum Q] rate rate allocated to this class (class can still borrow) burst max bytes burst which can be accumulated during idle period {computed} mpu minimum packet size used in rate computations overhead per-packet size overhead used in rate computations linklay adapting to a linklayer e.g. atm ceil definite upper class rate (no borrows) {rate} cburst burst but for ceil {computed} mtu max packet size we create rate map for {1600} prio priority of leaf; lowe https://bugzilla.redhat.com/show_bug.cgi?id=1043735
-
- 03 8月, 2014 1 次提交
-
-
由 Laine Stump 提交于
libvirt previously only touched an interface's disable_ipv6 setting in sysfs if it needed to be set to 1, assuming that 0 is the default. Apparently that isn't always the case though (kernel 3.15.7-1 in Arch Linux reportedly defaults a new interface's disable_ipv6 setting to 1) so this patch explicitly sets it to 0 or 1 as appropriate.
-
- 23 7月, 2014 1 次提交
-
-
由 Ján Tomko 提交于
Replace all three-state (default/yes/no) enums with it: virDomainBIOSUseserial virDomainBootMenu virDomainPMState virDomainGraphicsSpiceClipboardCopypaste virDomainGraphicsSpiceAgentFileTransfer virNetworkDNSForwardPlainNames
-