- 28 10月, 2012 3 次提交
-
-
由 Martin Kletzander 提交于
In commit 9674f2c6, I forgot to change selabel_lookup with the other functions, so this one-liner does exactly that. (cherry picked from commit 6676c1fc)
-
由 Guannan Ren 提交于
BZ:https://bugzilla.redhat.com/show_bug.cgi?id=851981 When using macvtap, a character device gets first created by kernel with name /dev/tapN, its selinux context is: system_u:object_r:device_t:s0 Shortly, when udev gets notification when new file is created in /dev, it will then jump in and relabel this file back to the expected default context: system_u:object_r:tun_tap_device_t:s0 There is a time gap happened. Sometimes, it will have migration failed, AVC error message: type=AVC msg=audit(1349858424.233:42507): avc: denied { read write } for pid=19926 comm="qemu-kvm" path="/dev/tap33" dev=devtmpfs ino=131524 scontext=unconfined_u:system_r:svirt_t:s0:c598,c908 tcontext=system_u:object_r:device_t:s0 tclass=chr_file This patch will label the tapfd device before qemu process starts: system_u:object_r:tun_tap_device_t:MCS(MCS from seclabel->label) (cherry picked from commit ae368ebf)
-
由 Martin Kletzander 提交于
We are currently able to work only with non-translated SELinux contexts, but we are using functions that work with translated contexts throughout the code. This patch swaps all SELinux context translation relative calls with their raw sisters to avoid parsing problems. The problems can be experienced with mcstrans for example. The difference is that if you have translations enabled (yum install mcstrans; service mcstrans start), fgetfilecon_raw() will get you something like 'system_u:object_r:virt_image_t:s0', whereas fgetfilecon() will return 'system_u:object_r:virt_image_t:SystemLow' that we cannot parse. I was trying to confirm that the _raw variants were here since the dawn of time, but the only thing I see now is that it was imported together in the upstream repo [1] from svn, so before 2008. Thanks Laurent Bigonville for finding this out. [1] http://oss.tresys.com/git/selinux.git (cherry picked from commit 9674f2c6)
-
- 24 10月, 2012 1 次提交
-
-
由 Benjamin Cama 提交于
I hit this problem recently when trying to create a bridge with an IPv6 address on a 3.2 kernel: dnsmasq (and, further, radvd) would not bind to the given address, waiting 20s and then giving up with -EADDRNOTAVAIL (resp. exiting immediately with "error parsing or activating the config file", without libvirt noticing it, BTW). This can be reproduced with (I think) any kernel >= 2.6.39 and the following XML (to be used with "virsh net-create"): <network> <name>test-bridge</name> <bridge name='testbr0' /> <ip family='ipv6' address='fd00::1' prefix='64'> </ip> </network> (it happens even when you have an IPv4, too) The problem is that since commit [1] (which, ironically, was made to “help IPv6 autoconfiguration”) the linux bridge code makes bridges behave like “real” devices regarding carrier detection. This makes the bridges created by libvirt, which are started without any up devices, stay with the NO-CARRIER flag set, and thus prevents DAD (Duplicate address detection) from happening, thus letting the IPv6 address flagged as “tentative”. Such addresses cannot be bound to (see RFC 2462), so dnsmasq fails binding to it (for radvd, it detects that "interface XXX is not RUNNING", thus that "interface XXX does not exist, ignoring the interface" (sic)). It seems that this behavior was enhanced somehow with commit [2] by avoiding setting NO-CARRIER on empty bridges, but I couldn't reproduce this behavior on my kernel. Anyway, with the “dummy tap to set MAC address” trick, this wouldn't work. To fix this, the idea is to get the bridge's attached device to be up so that DAD can happen (deactivating DAD altogether is not a good idea, I think). Currently, libvirt creates a dummy TAP device to set the MAC address of the bridge, keeping it down. But even if we set this device up, it is not RUNNING as soon as the tap file descriptor attached to it is closed, thus still preventing DAD. So, we must modify the API a bit, so that we can get the fd, keep the tap device persistent, run the daemons, and close it after DAD has taken place. After that, the bridge will be flagged NO-CARRIER again, but the daemons will be running, even if not happy about the device's state (but we don't really care about the bridge's daemons doing anything when no up interface is connected to it). Other solutions that I envisioned were: * Keeping the *-nic interface up: this would waste an fd for each bridge during all its life. May be acceptable, I don't really know. * Stop using the dummy tap trick, and set the MAC address directly on the bridge: it is possible since quite some time it seems, even if then there is the problem of the bridge not being RUNNING when empty, contrary to what [2] says, so this will need fixing (and this fix only happened in 3.1, so it wouldn't work for 2.6.39) * Using the --interface option of dnsmasq, but I saw somewhere that it's not used by libvirt for backward compatibility. I am not sure this would solve this problem, though, as I don't know how dnsmasq binds itself to it with this option. This is why this patch does what's described earlier. This patch also makes radvd start even if the interface is “missing” (i.e. it is not RUNNING), as it daemonizes before binding to it, and thus sometimes does it after the interface has been brought down by us (by closing the tap fd), and then originally stops. This also makes it stop yelling about it in the logs when the interface is down at a later time. [1] http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commit;h=1faa4356a3bd89ea11fb92752d897cff3a20ec0e [2] http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commit;h=b64b73d7d0c480f75684519c6134e79d50c1b341 (cherry picked from commit db488c79)
-
- 19 10月, 2012 27 次提交
-
-
由 Jiri Denemark 提交于
When p2p migration fails early because qemuMigrationIsAllowed or qemuMigrationIsSafe say migration should be cancelled, we fail to clear the migration-out async job. As a result of that, further APIs called for the same domain may fail with Timed out during operation: cannot acquire state change lock. Reported by Guido Winkelmann. (cherry picked from commit 837993d8)
-
由 Cole Robinson 提交于
On F17 at least, this command fails: $ sudo /usr/sbin/lvcreate --name sparsetest -L 0K --virtualsize 16384K vgvirt Unable to create new logical volume with no extents Which is unfortunate since allocation=0 is what virt-manager tries to use by default. Rather than telling the user 'don't do that', let's just give them the smallest allocation possible if alloc=0 is requested. https://bugzilla.redhat.com/show_bug.cgi?id=866481 (cherry picked from commit 9f0e9cba)
-
由 Cole Robinson 提交于
Before: $ sudo virsh vol-create-as --pool vgvirt sparsetest --capacity 16M --allocation 0 error: Failed to create vol sparsetest error: internal error Child process (/usr/sbin/lvchange -aln vgvirt/sparsetest) unexpected exit status 5: One or more specified logical volume(s) not found. After: $ sudo virsh vol-create-as --pool vgvirt sparsetest --capacity 16M --allocation 0 error: Failed to create vol sparsetest error: internal error Child process (/usr/sbin/lvcreate --name sparsetest -L 0K --virtualsize 16384K vgvirt) unexpected exit status 5: Unable to create new logical volume with no extents (cherry picked from commit 01df6f2b)
-
由 Peter Krempa 提交于
libssh2 unfortunately doesn't support symbol versioning so RPM can't figure out what version is needed for the currently installed libvirt package. This patch adds a runtime requirement, so that the correct version of libssh2 can be installed along with libvirt. (cherry picked from commit cb4f41b8)
-
由 Peter Krempa 提交于
Libssh2 transport support was enabled lately but the spec file wasn't updated to take this into account. This caused libvirt to be built without libssh2 support in Red Hat based OSes. (cherry picked from commit 1e25c54f)
-
由 Martin Kletzander 提交于
There was a crash possible when both <boot dev... and <boot order... were specified due to virDomainDefParseBootXML() erroring out before setting *tmp (which was free'd in cleanup). As a fix, I created this cleanup that uses one pointer for all the temporary stored XPath strings and values, plus this pointer is correctly initialized to NULL. (cherry picked from commit 280b8c9e)
-
由 Guido Günther 提交于
This fixes problems on platforms where sizeof(long) != sizeof(long long) like ia32. (cherry picked from commit d78035d0)
-
由 Zeeshan Ali (Khattak) 提交于
(cherry picked from commit 0ec6aebb)
-
由 Cole Robinson 提交于
Done with: sed -i -e "s/no pool with matching uuid/no storage pool with matching uuid/g" src/storage/storage_driver.c sed -i -e 's/"%s", _("no storage pool with matching uuid")/_("no storage pool with matching uuid %s"), obj->uuid/g' src/storage/storage_driver.c sed -i -e 's/"%s", _("storage pool is not active")/_("storage pool '%s' is not active"), pool->def->name/g' src/storage/storage_driver.c And a couple fixups before, during, and after, and a manual inspection pass to make sure nothing was wonky. (cherry picked from commit 3af8280b)
-
由 Daniel P. Berrange 提交于
When adding variants of parameter setting APIs which accepted flags, the existing APIs were all adapted internally to pass VIR_DOMAIN_AFFECT_CURRENT to the new API. The QEMU impl qemuSetSchedularParameters was an exception, which instead used VIR_DOMAIN_AFFECT_LIVE. Change this to match other compatibility scenarios, so that calling virDomainSetSchedularParameters(dom, params, nparams); Has the same semantics as virDomainSetSchedularParametersFlags(dom, params, nparams, 0); And virDomainSetSchedularParametersFlags(dom, params, nparams, VIR_DOMAIN_AFFECT_CURRENT); Signed-off-by: NDaniel P. Berrange <berrange@redhat.com> (cherry picked from commit 4da9b2c1)
-
由 Michal Privoznik 提交于
With our latest s/[a-z]+ReportError/virReportError/ rewrite (47ab34e2) we forgot to update arm part of the code. (cherry picked from commit 84a8917b)
-
由 Matthias Bolte 提交于
curl_global_init is not thread-safe. curl_easy_init might call curl_global_init when it was no called before. But curl_easy_init can be called from different threads by the ESX driver. Therefore, call curl_global_init from virInitialize to stop curl_easy_init from calling it. Reported by Benjamin Wang. (cherry picked from commit 458c4998)
-
由 Martin Kletzander 提交于
When both kvmclock and kvm_pv_eoi are configured (either disabled or enabled) libvirt will generate invalid CPU specification due to the fact that even though kvmclock causes the CPU to be specified, it doesn't set have_cpu flag to true (and the new kvm_pv_eoi as well). This patch fixes the issue and adds a test exactly for that to show that it is fixed correctly (and also to keep it that way in the future of course). (cherry picked from commit 5d692cc7)
-
由 Matthias Bolte 提交于
libcurl uses a SIGALRM in combination with sigsetjmp/siglongjmp to be able to abort a DNS lookup when it takes too long. The problem with this in a multi-threaded application is that the signal handler for SIGALRM and the call to siglongjmp can be executed on a thread that is different from the one that initially did the SIGALRM setup and the call to sigsetjmp. In the reported case this triggered a segfault. Disable libcurl's use of signals to avoid this situation. This has the disadvantage of losing the ability to abort synchronous DNS lookups which might result in libcurl getting stuck in a DNS lookup in the worst case. When libcurl was build with an asynchronous DNS backend such as c-ares then there is no problem because the timeout mechanism works without signals here anyway. Reported by Benjamin Wang. (cherry picked from commit 0821ea6b)
-
由 Viktor Mihajlovski 提交于
The output buffer for virFileReadAll was too small for systems with more than 30 CPUs which leads to a log entry and incorrect behavior. The new size will be sufficient for the current architectural limits. Signed-off-by: NViktor Mihajlovski <mihajlov@linux.vnet.ibm.com> (cherry picked from commit 4bdc8606)
-
由 Eric Blake 提交于
I noticed that in two places, we require util-linux, and in a third, we require util-linux-ng. On Fedora (I tested F15 through rawhide), util-linux-ng is obsoleted by util-linux; on RHEL 6, util-linux is obsoleted by util-linux-ng. That is, on either platform, either name will get you the correct package installed (where the preferred name on fedora is util-linux, and on RHEL 6 is util-linux-ng). But on RHEL 5, there is no util-linux-ng * libvirt.spec.in (Requires): Use util-linux, not util-linux-ng. (cherry picked from commit a9087ad1)
-
由 Eric Blake 提交于
Use of the wrong attribute name caused the table of contents to be useless. Fix suggested by Daniel P. Berrange. * docs/migration.html.in: Use correct anchoring attribute. (cherry picked from commit eeb8c924)
-
由 Kyle Mestery 提交于
Correct the check for the return value of virStrcpyStatic() when copying port-profile names. Fixes Open vSwitch ports which utilize port-profiles from network definitions. Signed-off-by: NKyle Mestery <kmestery@cisco.com> (cherry picked from commit 83aebf6d)
-
由 Eric Blake 提交于
Commit c579d6b3 added a sledgehammer to silence spurious warnings from gcc 4.2, but in the process, it also silenced useful warnings from gcc 4.3 through 4.5. As a result, a bug slipped in to commit 0caccb58. Tested with FreeBSD (gcc 4.2.1), RHEL 6.3 (gcc 4.4), and F17 (gcc 4.7.2), where the former didn't trip on spurious warnings, and where the latter two detected a revert of 2b804cfa. * m4/virt-compile-warnings.m4 (-Wno-format): Probe for the actual spurious message, to once again allow gcc 4.4 to use -Wformat. (cherry picked from commit 814a8dea)
-
由 Peter Krempa 提交于
When doing snapshots, the filesystem freeze function used the agent entering function that expects the qemud_driver unlocked. This might cause a deadlock of the qemu driver if the agent does not respond. The only call path of this function has the qemud_driver locked, so this patch changes the entering functions to those expecting the driver locked. (cherry picked from commit e0316b5e)
-
由 Michal Privoznik 提交于
There was an inverted return value in lxcCgroupControllerActive(). The function assumes cgroups are active and do couple of checks to prove that. If any of them fails, false is returned. Therefore, at the end, after all checks are done we must return true, not false. (cherry picked from commit 0dddd680)
-
由 Eric Blake 提交于
Commit f1a43a8e missed one side of an #if/#else. * src/util/processinfo.c (virProcessInfoGetAffinity): Use correct bitmap operation. (cherry picked from commit 9038ac65)
-
由 Dave Allan 提交于
Clarify that domains with numeric names can only be identified by their domain id. (cherry picked from commit 13c69cd0)
-
由 Daniel J Walsh 提交于
Currently if you build on a machine that does not support SELinux we end up with the default mount point being /selinux, since this is moved to /sys/fs/selinux, we should start defaulting there. I believe this is causing a bug in libvirt-lxc when /selinux does not exists, even though /sys/fs/selinux exists. (cherry picked from commit aa696e18)
-
由 Chuck Short 提交于
Minimal CPU "parser" for armhf to avoid compile time warning. Signed-off-by: NChuck Short <chuck.short@canonical.com> (cherry picked from commit 2d0a777b)
-
由 Guannan Ren 提交于
The result is indeterminate for NULL argument to python functions as follows. It's better to return negative value in these situations. PyObject_IsTrue will segfault if the argument is NULL PyFloat_AsDouble(NULL) is -1.000000 PyLong_AsUnsignedLongLong(NULL) is 0.000000 (cherry picked from commit 4c6be02a)
-
由 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)
-
- 18 10月, 2012 9 次提交
-
-
由 Daniel P. Berrange 提交于
For historical compat we use 'itanium' as the arch name, so if the QEMU binary suffix is 'ia64' we need to translate it Signed-off-by: NDaniel P. Berrange <berrange@redhat.com> (cherry picked from commit 3887afbb)
-
由 Daniel P. Berrange 提交于
If the qemuAgentClose method is called from a place which holds the domain lock, it is theoretically possible to get a deadlock in the agent destroy callback. This has not been observed, but the equivalent code in the QEMU monitor destroy callback has seen a deadlock. Remove the redundant locking while unrefing the object and the bogus assignment Signed-off-by: NDaniel P. Berrange <berrange@redhat.com> (cherry picked from commit 362d0477)
-
由 Daniel P. Berrange 提交于
Some users report (very rarely) seeing a deadlock in the QEMU monitor callbacks Thread 10 (Thread 0x7fcd11e20700 (LWP 26753)): #0 0x00000030d0e0de4d in __lll_lock_wait () from /lib64/libpthread.so.0 #1 0x00000030d0e09ca6 in _L_lock_840 () from /lib64/libpthread.so.0 #2 0x00000030d0e09ba8 in pthread_mutex_lock () from /lib64/libpthread.so.0 #3 0x00007fcd162f416d in virMutexLock (m=<optimized out>) at util/threads-pthread.c:85 #4 0x00007fcd1632c651 in virDomainObjLock (obj=<optimized out>) at conf/domain_conf.c:14256 #5 0x00007fcd0daf05cc in qemuProcessHandleMonitorDestroy (mon=0x7fcccc0029e0, vm=0x7fcccc00a850) at qemu/qemu_process.c:1026 #6 0x00007fcd0db01710 in qemuMonitorDispose (obj=0x7fcccc0029e0) at qemu/qemu_monitor.c:249 #7 0x00007fcd162fd4e3 in virObjectUnref (anyobj=<optimized out>) at util/virobject.c:139 #8 0x00007fcd0db027a9 in qemuMonitorClose (mon=<optimized out>) at qemu/qemu_monitor.c:860 #9 0x00007fcd0daf61ad in qemuProcessStop (driver=driver@entry=0x7fcd04079d50, vm=vm@entry=0x7fcccc00a850, reason=reason@entry=VIR_DOMAIN_SHUTOFF_DESTROYED, flags=flags@entry=0) at qemu/qemu_process.c:4057 #10 0x00007fcd0db323cf in qemuDomainDestroyFlags (dom=<optimized out>, flags=<optimized out>) at qemu/qemu_driver.c:1977 #11 0x00007fcd1637ff51 in virDomainDestroyFlags ( domain=domain@entry=0x7fccf00c1830, flags=1) at libvirt.c:2256 At frame #10 we are holding the domain lock, we call into qemuProcessStop() to cleanup QEMU, which triggers the monitor to close, which invokes qemuProcessHandleMonitorDestroy() which tries to obtain the domain lock again. This is a non-recursive lock, hence hang. Since qemuMonitorPtr is a virObject, the unref call in qemuProcessHandleMonitorDestroy no longer needs mutex protection. The assignment of priv->mon = NULL, can be instead done by the caller of qemuMonitorClose(), thus removing all need for locking. Signed-off-by: NDaniel P. Berrange <berrange@redhat.com> (cherry picked from commit 25f582e3)
-
由 Daniel P. Berrange 提交于
If QEMU quits immediately after we opened the monitor it was possible we would skip the clearing of the SELinux process socket context Signed-off-by: NDaniel P. Berrange <berrange@redhat.com> (cherry picked from commit 0b62c073)
-
由 Daniel P. Berrange 提交于
When calling qemuProcessKill from the virDomainDestroy impl in QEMU, do not ignore the return value. This ensures that if QEMU fails to respond to SIGKILL, the caller will know about the failure. Signed-off-by: NDaniel P. Berrange <berrange@redhat.com> (cherry picked from commit f1b4021b)
-
由 Daniel P. Berrange 提交于
Depending on the scenario in which LXC containers exit, it is possible for the EOF callback of the LXC monitor to deadlock the driver. #0 0x00000038a0a0de4d in __lll_lock_wait () from /lib64/libpthread.so.0 #1 0x00000038a0a09ca6 in _L_lock_840 () from /lib64/libpthread.so.0 #2 0x00000038a0a09ba8 in pthread_mutex_lock () from /lib64/libpthread.so.0 #3 0x00007f4bd9579d55 in virMutexLock (m=<optimized out>) at util/threads-pthread.c:85 #4 0x00007f4bcacc7597 in lxcDriverLock (driver=0x7f4bc40c8290) at lxc/lxc_conf.h:81 #5 virLXCProcessMonitorEOFNotify (mon=<optimized out>, vm=0x7f4bb4000b00) at lxc/lxc_process.c:581 #6 0x00007f4bd9645c91 in virNetClientCloseLocked (client=client@entry=0x7f4bb4009e60) at rpc/virnetclient.c:554 #7 0x00007f4bd96460f8 in virNetClientIOEventLoopPassTheBuck (thiscall=0x0, client=0x7f4bb4009e60) at rpc/virnetclient.c:1306 #8 virNetClientIOEventLoopPassTheBuck (client=0x7f4bb4009e60, thiscall=0x0) at rpc/virnetclient.c:1287 #9 0x00007f4bd96467a2 in virNetClientCloseInternal (reason=3, client=0x7f4bb4009e60) at rpc/virnetclient.c:589 #10 virNetClientCloseInternal (client=0x7f4bb4009e60, reason=3) at rpc/virnetclient.c:561 #11 0x00007f4bcacc4a82 in virLXCMonitorClose (mon=0x7f4bb4000a00) at lxc/lxc_monitor.c:201 #12 0x00007f4bcacc55ac in virLXCProcessCleanup (reason=<optimized out>, vm=0x7f4bb4000b00, driver=0x7f4bc40c8290) at lxc/lxc_process.c:240 #13 virLXCProcessStop (driver=0x7f4bc40c8290, vm=vm@entry=0x7f4bb4000b00, reason=reason@entry=VIR_DOMAIN_SHUTOFF_DESTROYED) at lxc/lxc_process.c:735 #14 0x00007f4bcacc5bd2 in virLXCProcessAutoDestroyDom (payload=<optimized out>, name=0x7f4bb4003c80, opaque=0x7fff41af2df0) at lxc/lxc_process.c:94 #15 0x00007f4bd9586649 in virHashForEach (table=0x7f4bc409b270, iter=iter@entry=0x7f4bcacc5ab0 <virLXCProcessAutoDestroyDom>, data=data@entry=0x7fff41af2df0) at util/virhash.c:514 #16 0x00007f4bcacc52d7 in virLXCProcessAutoDestroyRun (driver=driver@entry=0x7f4bc40c8290, conn=conn@entry=0x7f4bb8000ab0) at lxc/lxc_process.c:120 #17 0x00007f4bcacca628 in lxcClose (conn=0x7f4bb8000ab0) at lxc/lxc_driver.c:128 #18 0x00007f4bd95e67ab in virReleaseConnect (conn=conn@entry=0x7f4bb8000ab0) at datatypes.c:114 When the driver calls virLXCMonitorClose, there is really no need for the EOF callback to be invoked in this case, since the caller can easily handle events itself. In changing this, the monitor needs to take a deep copy of the callback list, not merely a reference. Also adds debug statements in various places to aid troubleshooting Signed-off-by: NDaniel P. Berrange <berrange@redhat.com> (cherry picked from commit 36c1fc18)
-
由 Jim Fehlig 提交于
Xen upstream c/s 24102:dc8e55c9 bumped the sysctl version to 9. Support this sysctl version in the xen_hypervisor sub-driver. (cherry picked from commit 371ddc98)
-
由 Eric Blake 提交于
Jim Fehlig reported a compilation error with older gcc 4.3.4: libvirt.c: In function 'virDomainGetEmulatorPinInfo': libvirt.c:9111: error: logical '&&' with non-zero constant will always evaluate as true [-Wlogical-op] It looks like someone programmed via too much copy-and-paste. * src/libvirt.c (virDomainGetEmulatorPinInfo): Multiplying by 1 is a no-op, and thus will never overflow. (cherry picked from commit 3da355e8)
-
由 Dmitry Guryanov 提交于
Signed-off-by: NDmitry Guryanov <dguryanov@parallels.com> (cherry picked from commit adae5cf7)
-