- 13 6月, 2013 2 次提交
-
-
由 Cole Robinson 提交于
-
由 Christophe Fergeau 提交于
qemu-img resize will fail with "The new size must be a multiple of 512" if libvirt doesn't round it first. This fixes rhbz#951495 Signed-off-by: NChristophe Fergeau <cfergeau@redhat.com> (cherry picked from commit 9a8f39d0)
-
- 12 6月, 2013 1 次提交
-
-
由 Eric Blake 提交于
Reported by Anthony Messina in https://bugzilla.redhat.com/show_bug.cgi?id=904692 Present since introduction of smartcard support in commit f5fd9baa * src/qemu/qemu_command.c (qemuBuildCommandLine): Match qemu spelling. * tests/qemuxml2argvdata/qemuxml2argv-smartcard-host-certificates.args: Fix broken test. (cherry picked from commit 6f7e4ea3)
-
- 09 5月, 2013 4 次提交
-
-
由 Cole Robinson 提交于
This reverts commit 71e88fc5. Accidental double commit.
-
由 Cole Robinson 提交于
This reverts commit d23e735f. Accidental double commit.
-
由 Eric Blake 提交于
Commit c308a9ae was incomplete; it resolved the configure failure, but not a later build failure. * src/util/virnetdevbridge.c: Include pre-req header. * configure.ac (AC_CHECK_HEADERS): Prefer standard in.h over non-standard ip6.h. (cherry picked from commit 1bf661ca) (cherry picked from commit 2c7638fd) Conflicts: src/util/virnetdevbridge.c
-
由 Cole Robinson 提交于
I got this scary warning during ./configure on rawhide: checking linux/if_bridge.h usability... no checking linux/if_bridge.h presence... yes configure: WARNING: linux/if_bridge.h: present but cannot be compiled configure: WARNING: linux/if_bridge.h: check for missing prerequisite headers? configure: WARNING: linux/if_bridge.h: see the Autoconf documentation configure: WARNING: linux/if_bridge.h: section "Present But Cannot Be Compiled" configure: WARNING: linux/if_bridge.h: proceeding with the compiler's result configure: WARNING: ## ------------------------------------- ## configure: WARNING: ## Report this to libvir-list@redhat.com ## configure: WARNING: ## ------------------------------------- ## checking for linux/if_bridge.h... no * configure.ac (AC_CHECK_HEADERS): Provide struct in6_addr, since linux/if_bridge.h uses it without declaring it. (cherry picked from commit c308a9ae) (cherry picked from commit 7ae53f15) (cherry picked from commit 879f28a9) Conflicts: configure.ac
-
- 08 5月, 2013 1 次提交
-
-
由 Eric Blake 提交于
Several people have reported that if the .gnulib submodule is dirty, then 'make' will go into an infinite loop attempting to rerun bootstrap, because that never cleans up the dirty submodule. By default, we should halt and make the user investigate, but if the user doesn't know why or care that the submodule is dirty, I also added the ability to 'make CLEAN_SUBMODULE=1' to get things going again. Also, while testing this, I noticed that when a submodule update was needed, 'make' would first run autoreconf, then bootstrap (which reruns autoreconf); adding a strategic dependency allows for less work. * .gnulib: Update to latest, for maint.mk improvements. * cfg.mk (_autogen): Also hook maint.mk, to run before autoreconf. * autogen.sh (bootstrap): Refuse to run if gnulib is dirty, unless user requests discarding gnulib changes. (cherry picked from commit c5f16220) Conflicts: .gnulib
-
- 06 5月, 2013 6 次提交
-
-
由 Jiri Denemark 提交于
Commit 64297313 added three direct references to nl_handle_* instead of using our aliases which hide differences between libnl-3 and libnl-1. (cherry picked from commit d9d39e62)
-
由 Christophe Fergeau 提交于
Commit 9298bfbc introduced code to detect if netcf is linked with libnl1, and to prefer libnl1 over libnl3 when this is the case. This behaviour can be disabled by setting LIBNL_CFLAGS to any value, including the empty string. However, configure.ac sets LIBNL_CFLAGS to "" before attempting libnl detection, so the libnl1 detection code is always disabled. This caused issues on my f17 system where netcf is linked with libnl1 but libvirt got built with libnl3. This commit removes the setting of the LIBNL_* variables to "" as this does not appear to be needed. After this change, libnl1 is used when building libvirt on my f17 system. (cherry picked from commit f6c29515)
-
由 Eric Blake 提交于
Recent spec file changes ensure that in distro situations, netcf and libvirt will link against the same libnl in order to avoid dumping core. But for every-day development, if you use F17 and have the libnl3-devel headers available, libvirt was blindly linking against libnl3 even though F17 netcf still links against libnl1, making testing a self-built binary on F17 impossible. By making configure a little bit smarter, we can avoid this situation - we merely skip the probe of libnl-3 if we can prove that netcf is still using libnl-1. I intentionally wrote the test so that we still favor libnl-3 if netcf is not installed or if we couldn't use ldd to determine things. Defaults being what they are, someone will invariably complain that our smarts were wrong. Never fear - in that case, just run ./configure LIBNL_CFLAGS=..., where the fact that you set LIBNL_CFLAGS (even to the empty string) will go back to probing for libnl-3, regardless of netcf's choice. * configure.ac (LIBNL): Don't probe libnl3 if netcf doesn't use it. (cherry picked from commit 9298bfbc)
-
由 Serge Hallyn 提交于
configure.ac: check for libnl-3 in addition to libnl-1 src/Makefile.am: link against libnl when needed src/util/virnetlink.c: support libnl3 api. To minimize impact on code flow, wrap the differences under the virNetlink* namespace. Unfortunately libnl3 moves netlink/msg.h to /usr/include/libnl3/netlink/msg.h, so the LIBNL_CFLAGS need to be added to a bunch of places where they weren't needed with libnl1. Signed-off-by: NSerge Hallyn <serge.hallyn@canonical.com> Signed-off-by: NEric Blake <eblake@redhat.com> (cherry picked from commit 60fb8a22) Conflicts: src/Makefile.am - dbus changes not backported
-
由 Eric Blake 提交于
Specific to v0.9.11. This is the opposite of commit dfa1e1dd, and done for the purposes of minimal code changes to allow compilation of libxl on Fedora 17 which still has experimental libxl 4.1, while still being able to compile the branch (minus libxl code) on Fedora 18 and later. Signed-off-by: NEric Blake <eblake@redhat.com>
-
由 Jim Fehlig 提交于
In Xen 4.2, xs.h is deprecated in favor of xenstore.h. xs.h now contains #warning xs.h is deprecated use xenstore.h instead #include <xenstore.h> which fails compilation when warnings are treated as errors. Introduce a configure-time check for xenstore.h and if found, use it instead of xs.h. (cherry picked from commit 416eca18)
-
- 27 3月, 2013 3 次提交
-
-
由 Michal Privoznik 提交于
Since we switched from direct host migration scheme to the one, where we connect to the destination and then just pass a FD to a qemu, we have uncovered a qemu bug. Qemu expects migration FD to block. However, we are passing a nonblocking one which results in cryptic error messages like: qemu: warning: error while loading state section id 2 load of migration failed The bug is already known to Qemu folks, but we should workaround already released Qemus. Patch has been originally proposed by Stefan Hajnoczi <stefanha@gmail.com> (cherry picked from commit ceb31795)
-
由 Eric Blake 提交于
Commit c308a9ae was incomplete; it resolved the configure failure, but not a later build failure. * src/util/virnetdevbridge.c: Include pre-req header. * configure.ac (AC_CHECK_HEADERS): Prefer standard in.h over non-standard ip6.h. (cherry picked from commit 1bf661ca) Conflicts: src/util/virnetdevbridge.c
-
由 Cole Robinson 提交于
I got this scary warning during ./configure on rawhide: checking linux/if_bridge.h usability... no checking linux/if_bridge.h presence... yes configure: WARNING: linux/if_bridge.h: present but cannot be compiled configure: WARNING: linux/if_bridge.h: check for missing prerequisite headers? configure: WARNING: linux/if_bridge.h: see the Autoconf documentation configure: WARNING: linux/if_bridge.h: section "Present But Cannot Be Compiled" configure: WARNING: linux/if_bridge.h: proceeding with the compiler's result configure: WARNING: ## ------------------------------------- ## configure: WARNING: ## Report this to libvir-list@redhat.com ## configure: WARNING: ## ------------------------------------- ## checking for linux/if_bridge.h... no * configure.ac (AC_CHECK_HEADERS): Provide struct in6_addr, since linux/if_bridge.h uses it without declaring it. (cherry picked from commit c308a9ae)
-
- 29 1月, 2013 3 次提交
-
-
由 Cole Robinson 提交于
-
由 Daniel P. Berrange 提交于
When running virDomainDestroy, we need to make sure that no other background thread cleans up the domain while we're doing our work. This can happen if we release the domain object while in the middle of work, because the monitor might detect EOF in this window. For this reason we have a 'beingDestroyed' flag to stop the monitor from doing its normal cleanup. Unfortunately this flag was only being used to protect qemuDomainBeginJob, and not qemuProcessKill This left open a race condition where either libvirtd could crash, or alternatively report bogus error messages about the domain already having been destroyed to the caller Signed-off-by: NDaniel P. Berrange <berrange@redhat.com> (cherry picked from commit 81621f3e) Conflicts: src/qemu/qemu_driver.c
-
由 Peter Krempa 提交于
This patch resolves CVE-2013-0170: https://bugzilla.redhat.com/show_bug.cgi?id=893450 When reading and dispatching of a message failed the message was freed but wasn't removed from the message queue. After that when the connection was about to be closed the pointer for the message was still present in the queue and it was passed to virNetMessageFree which tried to call the callback function from an uninitialized pointer. This patch removes the message from the queue before it's freed. * rpc/virnetserverclient.c: virNetServerClientDispatchRead: - avoid use after free of RPC messages (cherry picked from commit 46532e3e)
-
- 09 1月, 2013 3 次提交
-
-
由 Laine Stump 提交于
This is an adjustment to the fix for https://bugzilla.redhat.com/show_bug.cgi?id=889319 to account for two bonehead mistakes I made. commit ac2797cf attempted to fix a problem with netlink in newer kernels requiring an extra attribute with a filter flag set in order to receive an IFLA_VFINFO_LIST from netlink. Unfortunately, the #ifdef that protected against compiling it in on systems without the new flag went a bit too far, assuring that the new code would *never* be compiled, and even if it had, the code was incorrect. The first problem was that, while some IFLA_* enum values are also their existence at compile time, IFLA_EXT_MASK *isn't* #defined, so checking to see if it's #defined is not a valid method of determining whether or not to add the attribute. Fortunately, the flag that is being set (RTEXT_FILTER_VF) *is* #defined, and it is never present if IFLA_EXT_MASK isn't, so it's sufficient to just check for that flag. And to top it off, due to the code not actually compiling when I thought it did, I didn't realize that I'd been given the wrong arglist to nla_put() - you can't just send a const value to nla_put, you have to send it a pointer to memory containing what you want to add to the message, along with the length of that memory. This time I've actually sent the patch over to the other machine that's experiencing the problem, applied it to the branch being used (0.10.2) and verified that it works properly, i.e. it does fix the problem it's supposed to fix. :-/ (cherry picked from commit 7c366506)
-
由 Laine Stump 提交于
This patch fixes the lack of error messages when libvirt fails to find VFINFO in a returned netlinke response message. https://bugzilla.redhat.com/show_bug.cgi?id=827519#c10 is an example of the error message that was previously logged when the IFLA_VFINFO_LIST object was missing from the netlink response. The reason for this failure is detailed in https://bugzilla.redhat.com/show_bug.cgi?id=889319 Even though that root problem has been fixed, the experience of finding the root cause shows us how important it is to properly log an error message in these cases. This patch *seems* to replace the entire function, but really most of the changes are due to moving code that was previously inside an if() statement out to the top level of the function (the original if() was reversed and made to log an error and return). (cherry picked from commit 846770e5) Conflicts: src/util/virnetdev.c: virNetDevError was replaced with virReportError post-0.9.11. Also memcpy of mac addr was replaced with a call to virMacAddrSetRaw.
-
由 Laine Stump 提交于
This patch resolves: https://bugzilla.redhat.com/show_bug.cgi?id=889319 When assigning an SRIOV virtual function to a guest using "intelligent PCI passthrough" (<interface type='hostdev'>, which sets the MAC address and vlan tag of the VF before passing its info to qemu), libvirt first learns the current MAC address and vlan tag by sending an NLM_F_REQUEST message for the VF's PF (physical function) to the kernel via a NETLINK_ROUTE socket (see virNetDevLinkDump()); the response message's IFLA_VFINFO_LIST section is examined to extract the info for the particular VF being assigned. This worked fine with kernels up until kernel commit 115c9b81928360d769a76c632bae62d15206a94a (first appearing in upstream kernel 3.3) which changed the ABI to not return IFLA_VFINFO_LIST in the response until a newly introduced IFLA_EXT_MASK field was included in the request, with the (newly introduced, of course) RTEXT_FILTER_VF flag set. The justification for this ABI change was that new fields had been added to the VFINFO, causing NLM_F_REQUEST messages to fail on systems with large numbers of VFs if the requesting application didn't have a large enough buffer for all the info. The idea is that most applications doing an NLM_F_REQUEST don't care about VFINFO anyway, so eliminating it from the response would lower the requirements on buffer size. Apparently, the people who pushed this patch made the mistaken assumption that iproute2 (the "ip" command) was the only package that used IFLA_VFINFO_LIST, so it wouldn't break anything else (and they made sure that iproute2 was fixed. The logic of this "fix" is debatable at best (one could claim that the proper fix would be for the applications in question to be fixed so that they properly sized the buffer, which is what libvirt does (purely by virtue of using libnl), but it is what it is and we have to deal with it. In order for <interface type='hostdev'> to work properly on systems with a kernel 3.3 or later, libvirt needs to add the afore-mentioned IFLA_EXT_MASK field with RTEXT_FILTER_VF set. Of course we also need to continue working on systems with older kernels, so that one bit of code is compiled conditionally. The one time this could cause problems is if the libvirt binary was built on a system without IFLA_EXT_MASK which was subsequently updated to a kernel that *did* have it. That could be solved by manually providing the values of IFLA_EXT_MASK and RTEXT_FILTER_VF and adding it to the message anyway, but I'm uncertain what that might actually do on a system that didn't support the message, so for the time being we'll just fail in that case (which will very likely never happen anyway). (cherry picked from commit ac2797cf) Conflicts: src/util/virnetdev.c: parameters of virNetlinkCommand were changed post 0.9.11.
-
- 14 12月, 2012 1 次提交
-
-
由 Laine Stump 提交于
This patch resolves the problem reported in: https://bugzilla.redhat.com/show_bug.cgi?id=886663 The source of the problem was the fix for CVE 2011-3411: https://bugzilla.redhat.com/show_bug.cgi?id=833033 which was originally committed upstream in commit 753ff83a. That commit improperly removed the "--except-interface lo" from dnsmasq commandlines when --bind-dynamic was used (based on comments in the latter bug). It turns out that the problem reported in the CVE could be eliminated without removing "--except-interface lo", and removing it actually caused each instance of dnsmasq to listen on localhost on port 53, which created a new problem: If another instance of dnsmasq using "bind-interfaces" (instead of "bind-dynamic") had already been started (or if another instance started later used "bind-dynamic"), this wouldn't have any immediately visible ill effects, but if you tried to start another dnsmasq instance using "bind-interfaces" *after* starting any libvirt networks, the new dnsmasq would fail to start, because there was already another process listening on port 53. This patch changes the network driver to *always* add "except-interface=lo" to dnsmasq conf files, regardless of whether we use bind-dynamic or bind-interfaces. This way no libvirt dnsmasq instances are listening on localhost (and the CVE is still fixed). The actual code change is miniscule, but must be propogated through all of the test files as well. (This is *not* a cherry-pick of the upstream commit that fixes the bug (commit d66eb786), because subsequent to the CVE fix, another patch changed the network driver to put dnsmasq options in a conf file rather than directly on the dnsmasq commandline preserving the same options), so a cherry-pick is just one very large conflict.)
-
- 10 12月, 2012 7 次提交
-
-
由 Cole Robinson 提交于
-
由 Vladislav Bogdanov 提交于
(cherry picked from commit 81af5336) Conflicts: src/qemu/qemu_command.c tests/qemuxml2argvdata/qemuxml2argv-bios.args tests/qemuxml2argvdata/qemuxml2argv-blkiotune-device.args tests/qemuxml2argvdata/qemuxml2argv-blkiotune.args tests/qemuxml2argvdata/qemuxml2argv-boot-menu-disable-drive-bootindex.args tests/qemuxml2argvdata/qemuxml2argv-console-virtio-s390.args tests/qemuxml2argvdata/qemuxml2argv-cpu-eoi-disabled.args tests/qemuxml2argvdata/qemuxml2argv-cpu-eoi-enabled.args tests/qemuxml2argvdata/qemuxml2argv-cputune.args tests/qemuxml2argvdata/qemuxml2argv-disk-blockio.args tests/qemuxml2argvdata/qemuxml2argv-disk-copy_on_read.args tests/qemuxml2argvdata/qemuxml2argv-disk-drive-network-rbd-auth.args tests/qemuxml2argvdata/qemuxml2argv-disk-drive-network-rbd.args tests/qemuxml2argvdata/qemuxml2argv-disk-geometry.args tests/qemuxml2argvdata/qemuxml2argv-disk-ide-drive-split.args tests/qemuxml2argvdata/qemuxml2argv-disk-ide-wwn.args tests/qemuxml2argvdata/qemuxml2argv-disk-ioeventfd.args tests/qemuxml2argvdata/qemuxml2argv-disk-scsi-disk-split.args tests/qemuxml2argvdata/qemuxml2argv-disk-scsi-disk-wwn.args tests/qemuxml2argvdata/qemuxml2argv-disk-virtio-s390.args tests/qemuxml2argvdata/qemuxml2argv-eoi-disabled.args tests/qemuxml2argvdata/qemuxml2argv-eoi-enabled.args tests/qemuxml2argvdata/qemuxml2argv-event_idx.args tests/qemuxml2argvdata/qemuxml2argv-graphics-spice.args tests/qemuxml2argvdata/qemuxml2argv-graphics-vnc.args tests/qemuxml2argvdata/qemuxml2argv-hyperv.args tests/qemuxml2argvdata/qemuxml2argv-kvmclock+eoi-disabled.args tests/qemuxml2argvdata/qemuxml2argv-machine-core-off.args tests/qemuxml2argvdata/qemuxml2argv-machine-core-on.args tests/qemuxml2argvdata/qemuxml2argv-memtune.args tests/qemuxml2argvdata/qemuxml2argv-metadata.args tests/qemuxml2argvdata/qemuxml2argv-minimal-s390.args tests/qemuxml2argvdata/qemuxml2argv-minimal.args tests/qemuxml2argvdata/qemuxml2argv-misc-disable-s3.args tests/qemuxml2argvdata/qemuxml2argv-misc-disable-suspends.args tests/qemuxml2argvdata/qemuxml2argv-misc-enable-s4.args tests/qemuxml2argvdata/qemuxml2argv-misc-uuid.args tests/qemuxml2argvdata/qemuxml2argv-net-virtio-s390.args tests/qemuxml2argvdata/qemuxml2argv-numad-auto-memory-vcpu-cpuset.args tests/qemuxml2argvdata/qemuxml2argv-numad-auto-memory-vcpu-no-cpuset-and-placement.args tests/qemuxml2argvdata/qemuxml2argv-numad-auto-vcpu-static-numatune.args tests/qemuxml2argvdata/qemuxml2argv-numad-static-memory-auto-vcpu.args tests/qemuxml2argvdata/qemuxml2argv-numad.args tests/qemuxml2argvdata/qemuxml2argv-reboot-timeout-disabled.args tests/qemuxml2argvdata/qemuxml2argv-reboot-timeout-enabled.args tests/qemuxml2argvdata/qemuxml2argv-seclabel-dynamic-baselabel.args tests/qemuxml2argvdata/qemuxml2argv-seclabel-dynamic-override.args tests/qemuxml2argvdata/qemuxml2argv-seclabel-dynamic.args tests/qemuxml2argvdata/qemuxml2argv-seclabel-none.args tests/qemuxml2argvdata/qemuxml2argv-seclabel-static-relabel.args tests/qemuxml2argvdata/qemuxml2argv-seclabel-static.args tests/qemuxml2argvdata/qemuxml2argv-smbios.args tests/qemuxml2argvdata/qemuxml2argv-virtio-lun.args
-
由 Vladislav Bogdanov 提交于
(cherry picked from commit 8f708761)
-
由 Stefan Hajnoczi 提交于
The string comparison logic was inverted and matched the first drive that does *not* have the name we search for. Signed-off-by: NStefan Hajnoczi <stefanha@redhat.com> (cherry picked from commit 23d47b33)
-
由 Stefan Hajnoczi 提交于
The QEMU -drive id= begins with libvirt's QEMU host drive prefix ("drive-"), which is stripped off in several places two convert between host ("-drive") and guest ("-device") device names. In the case of BlkIoTune it is unnecessary to strip the QEMU host drive prefix because we operate on "info block"/"query-block" output that uses host drive names. Stripping the prefix incorrectly caused string comparisons to fail since we were comparing the guest device name against the host device name. Signed-off-by: NStefan Hajnoczi <stefanha@redhat.com> (cherry picked from commit 04ee70bf)
-
由 Michal Privoznik 提交于
If debugging is enabled, the debug messages are sent to stderr. Moreover, if a command has catching of stderr set, the messages gets mixed with stdout output (assuming both outputs are stored in the same variable). The resulting string then doesn't necessarily have to start with desired prefix then. This bug exposes itself when parsing dnsmasq output: 2012-12-06 11:18:11.445+0000: 18491: error : dnsmasqCapsSetFromBuffer:664 : internal error cannot parse /usr/sbin/dnsmasq version number in '2012-12-06 11:11:02.232+0000: 18492: debug : virFileClose:72 : Closed fd 22' We can clearly see that the output of dnsmasq --version doesn't start with expected "Dnsmasq version " string but a libvirt debug output. (cherry picked from commit ff33f807)
-
由 Michal Privoznik 提交于
If the debugging is enabled, the virCommand subsystem catches debug messages in the command output as well. In that case, we can't assume the string corresponding to command's stdout will start with specific prefix. But the prefix can be moved deeper in the string. This bug shows itself when parsing dnsmasq output: 2012-12-06 11:18:11.445+0000: 18491: error : dnsmasqCapsSetFromBuffer:664 : internal error cannot parse /usr/sbin/dnsmasq version number in '2012-12-06 11:11:02.232+0000: 18492: debug : virFileClose:72 : Closed fd 22' We can clearly see that the output of dnsmasq --version doesn't start with expected "Dnsmasq version " string but a libvirt debug output. (cherry picked from commit 51144313)
-
- 04 12月, 2012 1 次提交
-
-
由 Laine Stump 提交于
This resolves: https://bugzilla.redhat.com/show_bug.cgi?id=881480 These three functions: virDomainNetGetActualBridgeName virDomainNetGetActualDirectDev virDomainNetGetActualDirectMode return attributes that are in a union whose contents are interpreted differently depending on the actual->type and so they should only return non-0 when actual->type is 'bridge' (in the first case) or 'direct' (in the other two cases, but I had neglected to do that, so ...DirectDev() was returning bridge.brname (which happens to share the same spot in the union with direct.linkdev) if actual->type was 'bridge', and ...BridgeName was returning direct.linkdev when actual->type was 'direct'. How does this involve Bug 881480 (which was about the inability to switch between two networks that both have "<forward mode='bridge'/> <bridge name='xxx'/>"? Whenever the return value of virDomainNetGetActualDirectDev() for the new and old network definitions doesn't match, qemuDomainChangeNet() requires a "complete reconnect" of the device, which qemu currently doesn't support. ...DirectDev() *should* have been returning NULL for old and new, but was instead returning the old and new bridge names, which differ. (The other two functions weren't causing any behavioral problems in virDomainChangeNet(), but their problem and fix was identical, so I included them in this same patch).
-
- 30 11月, 2012 3 次提交
-
-
由 Laine Stump 提交于
This bug resolves CVE-2012-3411, which is described in the following bugzilla report: https://bugzilla.redhat.com/show_bug.cgi?id=833033 The following report is specifically for libvirt on Fedora: https://bugzilla.redhat.com/show_bug.cgi?id=874702 In short, a dnsmasq instance run with the intention of listening for DHCP/DNS requests only on a libvirt virtual network (which is constructed using a Linux host bridge) would also answer queries sent from outside the virtualization host. This patch takes advantage of a new dnsmasq option "--bind-dynamic", which will cause the listening socket to be setup such that it will only receive those requests that actually come in via the bridge interface. In order for this behavior to actually occur, not only must "--bind-interfaces" be replaced with "--bind-dynamic", but also all "--listen-address" options must be replaced with a single "--interface" option. Fully: --bind-interfaces --except-interface lo --listen-address x.x.x.x ... (with --listen-address possibly repeated) is replaced with: --bind-dynamic --interface virbrX Of course libvirt can't use this new option if the host's dnsmasq doesn't have it, but we still want libvirt to function (because the great majority of libvirt installations, which only have mode='nat' networks using RFC1918 private address ranges (e.g. 192.168.122.0/24), are immune to this vulnerability from anywhere beyond the local subnet of the host), so we use the new dnsmasqCaps API to check if dnsmasq supports the new option and, if not, we use the "old" option style instead. In order to assure that this permissiveness doesn't lead to a vulnerable system, we do check for non-private addresses in this case, and refuse to start the network if both a) we are using the old-style options, and b) the network has a publicly routable IP address. Hopefully this will provide the proper balance of not being disruptive to those not practically affected, and making sure that those who *are* affected get their dnsmasq upgraded. (--bind-dynamic was added to dnsmasq in upstream commit 54dd393f3938fc0c19088fbd319b95e37d81a2b0, which was included in dnsmasq-2.63) (cherry picked from commit 753ff83a) Conflicts: src/network/bridge_driver.c * needed to change virReportError() to the older networkReportError() tests/networkxml2argvdata/nat-network-dns-txt-record.argv * this test file has an example of an arg with embedded space, which gets sorrounded by '' in newer releases. Other items on the same line had been modified. tests/networkxml2argvdata/routed-network.argv * in the newer releases, this test file had an --addn-hosts arg that didn't exist on this branch. Again, it was in the surrounding context of the changes that had been made on master.
-
由 Laine Stump 提交于
This new function returns true if the given address is in the range of any "private" or "local" networks as defined in RFC1918 (IPv4) or RFC3484/RFC4193 (IPv6), otherwise they return false. These ranges are: 192.168.0.0/16 172.16.0.0/16 10.0.0.0/24 FC00::/7 FEC0::/10 (cherry picked from commit bf402e77) Conflicts: src/util/virsocketaddr.c src/util/virsocketaddr.h * both of these files had new functions that had been added at the same place virSocketAddrIsPrivate was being added, so the context on the branch didn't match.
-
由 Laine Stump 提交于
In order to optionally take advantage of new features in dnsmasq when the host's version of dnsmasq supports them, but still be able to run on hosts that don't support the new features, we need to be able to detect the version of dnsmasq running on the host, and possibly determine from the help output what options are in this dnsmasq. This patch implements a greatly simplified version of the capabilities code we already have for qemu. A dnsmasqCaps device can be created and populated either from running a program on disk, reading a file with the concatenated output of "dnsmasq --version; dnsmasq --help", or examining a buffer in memory that contains the concatenated output of those two commands. Simple functions to retrieve capabilities flags, the version number, and the path of the binary are also included. bridge_driver.c creates a single dnsmasqCaps object at driver startup, and disposes of it at driver shutdown. Any time it must be used, the dnsmasqCapsRefresh method is called - it checks the mtime of the binary, and re-runs the checks if the binary has changed. networkxml2argvtest.c creates 2 "artificial" dnsmasqCaps objects at startup - one "restricted" (doesn't support --bind-dynamic) and one "full" (does support --bind-dynamic). Some of the test cases use one and some the other, to make sure both code pathes are tested. (cherry picked from commit 719c2c76) Conflicts: src/network/bridge_driver.c * some new functions are missing in the backport, so they don't need to be modified. * Use dnsmasqCapsFree() instead of virObjectUnref() src/util/dnsmasq.c * eliminate use of virObject, since this version of libvirt doesn't yet have it * use networkReportError() instead of virReportError() * virBitmapAlloc() instead of virBitmapNew() src/util/dnsmasq.h * don't #include virobject.h * add prototype for dnsmasqCapsFree() src/libvirt_private.syms * export dnsmasqCapsFree
-
- 06 11月, 2012 1 次提交
-
-
由 Eric Blake 提交于
In Fedora 16, we quit enabling cgconfig because systemd set up default cgroups that were good enough for our use. But in F17, when we switched to systemd, we reverted and started up cgconfig again. See also the tail of this thread: https://www.redhat.com/archives/libvir-list/2012-October/msg01657.html * libvirt.spec.in (with_systemd): Rely on systemd for cgroups. (cherry picked from commit b61eadf3)
-
- 28 10月, 2012 4 次提交
-
-
由 Cole Robinson 提交于
-
由 Cole Robinson 提交于
https://bugzilla.redhat.com/show_bug.cgi?id=636832 (cherry picked from commit 9a297578) Conflicts: src/qemu/qemu_driver.c
-
由 Cole Robinson 提交于
When restoring selinux labels after a VM is stopped, any non-standard path that doesn't have a default selinux label causes the process to stop and exit early. This isn't really an error condition IMO. Of course the selinux API could be erroring for some other reason but hopefully that's rare enough to not need explicit handling. Common example here is storing disk images in a non-standard location like under /mnt. (cherry picked from commit 767be8be)
-
由 Cole Robinson 提交于
If building on a 64bit host, rename the affected tapsets to <name>-64.stp. This is similar to what the python package does in fedora. https://bugzilla.redhat.com/show_bug.cgi?id=831425 (cherry picked from commit 18d0632d) Conflicts: libvirt.spec.in
-