- 01 10月, 2018 9 次提交
-
-
由 Ján Tomko 提交于
Commit 7c08fcc4 added this one. Signed-off-by: NJán Tomko <jtomko@redhat.com> Reviewed-by: NErik Skultety <eskultet@redhat.com>
-
由 Ján Tomko 提交于
Signed-off-by: NJán Tomko <jtomko@redhat.com> Reviewed-by: NErik Skultety <eskultet@redhat.com>
-
由 Ján Tomko 提交于
Signed-off-by: NJán Tomko <jtomko@redhat.com>
-
由 Ján Tomko 提交于
Use one line per entry, to work better with line-based git history. Signed-off-by: NJán Tomko <jtomko@redhat.com> Reviewed-by: NErik Skultety <eskultet@redhat.com>
-
由 Ján Tomko 提交于
Signed-off-by: NJán Tomko <jtomko@redhat.com>
-
由 Daniel Veillard 提交于
Signed-off-by: NDaniel Veillard <veillard@redhat.com> - docs/news.xml: updated for release
-
由 Fabiano Fidêncio 提交于
Signed-off-by: NFabiano Fidêncio <fidencio@redhat.com>
-
由 Jim Fehlig 提交于
The preferred location for setting the nested CPU flag changed in Xen 4.10 and is advertised via the LIBXL_HAVE_BUILDINFO_NESTED_HVM define. Commit 95d19cd0 changed libxl to use the new preferred location but unconditionally changed the tests, causing 'make check' failures against Xen < 4.10 that do not contain the new location. Commit e94415d5 fixed the failures by only running the tests when LIBXL_HAVE_BUILDINFO_NESTED_HVM is defined. Since libvirt supports several versions of Xen that use the old nested location, it is prudent to test the flag is set correctly. This patch reintroduces the tests for the legacy location of the nested setting. Signed-off-by: NJim Fehlig <jfehlig@suse.com> Reviewed-by: NErik Skultety <eskultet@redhat.com>
-
由 Julio Faracco 提交于
The pointer related to uml_driver needs to be checked before its usage inside the function. Some attributes of the driver are being accessed while the pointer is NULL considering the current logic. Signed-off-by: NJulio Faracco <jcfaracco@gmail.com> Reviewed-by: NErik Skultety <eskultet@redhat.com>
-
- 29 9月, 2018 1 次提交
-
-
由 Pavel Hrdina 提交于
This reverts commit 1602aa28. There is no need to call virCgroupRemove() nor virCgroupFree() if virCgroupEnableMissingControllers() fails because it will not modify 'group' at all. The cleanup of directories is done in virCgroupMakeGroup(). Reviewed-by: NJohn Ferlan <jferlan@redhat.com> Reviewed-by: NFabiano Fidêncio <fidencio@redhat.com> Reviewed-by: NMarc Hartmayer <mhartmay@linux.ibm.com> Signed-off-by: NPavel Hrdina <phrdina@redhat.com>
-
- 27 9月, 2018 6 次提交
-
-
由 Jiri Denemark 提交于
Both ceph and gluster have been built on RHEL on all architectures for some time, there's no need to limit them to x86_64. Signed-off-by: NJiri Denemark <jdenemar@redhat.com> Reviewed-by: NPavel Hrdina <phrdina@redhat.com>
-
由 Jiri Denemark 提交于
RHEL-7 is the only system where gnutls is too old to support @LIBVIRT specifier. Signed-off-by: NJiri Denemark <jdenemar@redhat.com> Reviewed-by: NPavel Hrdina <phrdina@redhat.com>
-
由 Michal Privoznik 提交于
Turns out, there are couple of bugs that prevent this feature from being operational. Given how close to the release we are disable the feature temporarily. Hopefully, it can be enabled back after all the bugs are fixed. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com> Reviewed-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Pavel Hrdina 提交于
Cgroups are linux specific and we need to make sure that the code is compiled only on linux. On different OSes it fails the compilation: ../../src/util/vircgroupv1.c:65:19: error: variable has incomplete type 'struct mntent' struct mntent entry; ^ ../../src/util/vircgroupv1.c:65:12: note: forward declaration of 'struct mntent' struct mntent entry; ^ ../../src/util/vircgroupv1.c:74:12: error: implicit declaration of function 'getmntent_r' is invalid in C99 [-Werror,-Wimplicit-function-declaration] while (getmntent_r(mounts, &entry, buf, sizeof(buf)) != NULL) { ^ ../../src/util/vircgroupv1.c:814:39: error: use of undeclared identifier 'MS_NOSUID' if (mount("tmpfs", root, "tmpfs", MS_NOSUID|MS_NODEV|MS_NOEXEC, opts) < 0) { ^ ../../src/util/vircgroupv1.c:814:49: error: use of undeclared identifier 'MS_NODEV' if (mount("tmpfs", root, "tmpfs", MS_NOSUID|MS_NODEV|MS_NOEXEC, opts) < 0) { ^ ../../src/util/vircgroupv1.c:814:58: error: use of undeclared identifier 'MS_NOEXEC' if (mount("tmpfs", root, "tmpfs", MS_NOSUID|MS_NODEV|MS_NOEXEC, opts) < 0) { ^ ../../src/util/vircgroupv1.c:841:65: error: use of undeclared identifier 'MS_BIND' if (mount(src, group->legacy[i].mountPoint, "none", MS_BIND, ^ Reviewed-by: NJán Tomko <jtomko@redhat.com> Signed-off-by: NPavel Hrdina <phrdina@redhat.com>
-
由 Pavel Hrdina 提交于
All the system headers are used only if we are compiling on linux and they all are present otherwise we would have seen build errors because in our tests/vircgrouptest.c we use only __linux__ to check whether to skip the cgroup tests or not. Reviewed-by: NJán Tomko <jtomko@redhat.com> Signed-off-by: NPavel Hrdina <phrdina@redhat.com>
-
由 Pavel Hrdina 提交于
tests/vircgrouptest.c uses #ifdef __linux__ for a long time and no failure was reported so far so it's safe to assume that __linux__ is good enough to guard cgroup code. Reviewed-by: NJán Tomko <jtomko@redhat.com> Signed-off-by: NPavel Hrdina <phrdina@redhat.com>
-
- 26 9月, 2018 15 次提交
-
-
由 Jiri Denemark 提交于
The domxml-to-native virsh command accepts either --xml or --domain option followed by a file or domain name respectively. The --domain option is documented as required, which means an argument with no option is treated as --xml. Commit v4.3.0-127-gd86531da broke this by making --domain optional and thus an argument with no option was treated as --domain. https://bugzilla.redhat.com/show_bug.cgi?id=1633077Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Ján Tomko 提交于
Commit 95d19cd0 unconditionally adjusted the tests to account for the conditional move of the nested_hvm setting location. Run the affected tests only for the new setup (witnessed by LIBXL_HAVE_BUILDINFO_NESTED_HVM). Signed-off-by: NJán Tomko <jtomko@redhat.com> Reviewed-by: NErik Skultety <eskultet@redhat.com>
-
由 Lin Ma 提交于
Let's ignore the checking of interface type when we call the function qemuARPGetInterfaces to get IP from host's arp table. Signed-off-by: NLin Ma <lma@suse.com> Reviewed-by: NChen Hanxiao <chenhanxiao@gmail.com>
-
由 Michal Privoznik 提交于
It may happen that in the list of paths/disk sources to relabel there is a disk source. If that is the case, the path is NULL. In that case, we shouldn't try to lock the path. It's likely a network disk anyway and therefore there is nothing to lock. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com> Reviewed-by: NErik Skultety <eskultet@redhat.com>
-
由 Michal Privoznik 提交于
This shouldn't be needed per-se. Security manager shouldn't disappear during transactions - it's immutable. However, it doesn't hurt to grab a reference either - transaction code uses it after all. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com> Reviewed-by: NMarc Hartmayer <mhartmay@linux.ibm.com> Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
-
由 Michal Privoznik 提交于
This array is allocated in virSecuritySELinuxContextListAppend() but never freed. This commit is essentially the same as ca250269. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com> Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
-
由 Marc Hartmayer 提交于
Use the mnemonic macros of libdbus for 1 (TRUE) and 0 (FALSE). Signed-off-by: NMarc Hartmayer <mhartmay@linux.ibm.com> Reviewed-by: NBjoern Walk <bwalk@linux.ibm.com> Reviewed-by: NBoris Fiuczynski <fiuczy@linux.ibm.com> Reviewed-by: NStefan Zimmermann <stzi@linux.ibm.com> Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
-
由 Marc Hartmayer 提交于
Report a debug message if dbus_watch_handle() returns FALSE. dbus_watch_handle() returns FALSE if there wasn't enough memory for reading or writing. Signed-off-by: NMarc Hartmayer <mhartmay@linux.ibm.com> Reviewed-by: NBjoern Walk <bwalk@linux.ibm.com> Reviewed-by: NBoris Fiuczynski <fiuczy@linux.ibm.com> Reviewed-by: NStefan Zimmermann <stzi@linux.ibm.com> Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
-
由 Marc Hartmayer 提交于
As documented at https://dbus.freedesktop.org/doc/api/html/group__DBusConnection.html#ga2522ac5075dfe0a1535471f6e045e1ee the creator of a non-shared D-Bus connection has to release the last reference after closing for freeing. Signed-off-by: NMarc Hartmayer <mhartmay@linux.ibm.com> Reviewed-by: NBjoern Walk <bwalk@linux.ibm.com> Reviewed-by: NBoris Fiuczynski <fiuczy@linux.ibm.com> Reviewed-by: NStefan Zimmermann <stzi@linux.ibm.com> Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
-
由 Marc Hartmayer 提交于
Grab a ref for info->bus (a DBus connection) as long as the while loop is running. With the grabbed reference it is ensured that info->bus isn't freed as long as the while loop is executed. This is necessary as it's allowed to drop the last ref for the bus connection in a handler. There was already a bug of this kind in libdbus itself: https://bugs.freedesktop.org/show_bug.cgi?id=15635. Signed-off-by: NMarc Hartmayer <mhartmay@linux.ibm.com> Reviewed-by: NBoris Fiuczynski <fiuczy@linux.ibm.com> Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
-
由 Jiri Denemark 提交于
The only place where VIR_DOMAIN_EVENT_RESUMED should be generated is the RESUME event handler to make sure we don't generate duplicate events or state changes. In the worse case the duplicity can revert or cover changes done by other event handlers. For example, after QEMU sent RESUME, BLOCK_IO_ERROR, and STOP events we could happily mark the domain as running and report VIR_DOMAIN_EVENT_RESUMED to registered clients. https://bugzilla.redhat.com/show_bug.cgi?id=1612943Signed-off-by: NJiri Denemark <jdenemar@redhat.com> Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
-
由 Jiri Denemark 提交于
Thanks to the previous commit the RESUME event handler knows what reason should be used when changing the domain state to VIR_DOMAIN_RUNNING, but the emitted VIR_DOMAIN_EVENT_RESUMED event still uses a generic VIR_DOMAIN_EVENT_RESUMED_UNPAUSED detail. Luckily, the event detail can be easily deduced from the running reason, which saves us from having to pass one more value to the handler. Signed-off-by: NJiri Denemark <jdenemar@redhat.com> Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
-
由 Jiri Denemark 提交于
Whenever we get the RESUME event from QEMU, we change the state of the affected domain to VIR_DOMAIN_RUNNING with VIR_DOMAIN_RUNNING_UNPAUSED reason. This is fine if the domain is resumed unexpectedly, but when we sent "cont" to QEMU we usually have a better reason for the state change. The better reason is used in qemuProcessStartCPUs which also sets the domain state to running if qemuMonitorStartCPUs reports success. Thus we may end up with two state updates in a row, but the final reason is correct. This patch is a preparation for dropping the state change done in qemuMonitorStartCPUs for which we need to pass the actual running reason to the RESUME event handler and use it there instead of VIR_DOMAIN_RUNNING_UNPAUSED. Signed-off-by: NJiri Denemark <jdenemar@redhat.com> Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
-
由 Jiri Denemark 提交于
This patch replaces some rather generic VIR_DOMAIN_RUNNING_UNPAUSED reasons when changing domain state to running with more specific ones. All of them are done when libvirtd reconnects to an existing domain after being restarted and sees an unfinished migration or save. Signed-off-by: NJiri Denemark <jdenemar@redhat.com> Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
-
由 Jiri Denemark 提交于
VIR_DOMAIN_EVENT_RESUMED_FROM_SNAPSHOT was defined but not used anywhere in our event generation code. This fixes qemuDomainRevertToSnapshot to properly report why the domain was resumed. Signed-off-by: NJiri Denemark <jdenemar@redhat.com> Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
-
- 25 9月, 2018 9 次提交
-
-
由 Mark Asselstine 提交于
A deadlock situation can occur when autostarting a LXC domain 'guest' due to two threads attempting to take opposing locks while holding opposing locks (AB BA problem). Thread A takes and holds the 'vm' lock while attempting to take the 'client' lock, meanwhile, thread B takes and holds the 'client' lock while attempting to take the 'vm' lock. The potential for this can be seen as follows: Thread A: virLXCProcessAutostartDomain (takes vm lock) --> virLXCProcessStart --> virLXCProcessConnectMonitor --> virLXCMonitorNew --> virNetClientSetCloseCallback (wants client lock) Thread B: virNetClientIncomingEvent (takes client lock) --> virNetClientIOHandleInput --> virNetClientCallDispatch --> virNetClientCallDispatchMessage --> virNetClientProgramDispatch --> virLXCMonitorHandleEventInit --> virLXCProcessMonitorInitNotify (wants vm lock) Since these threads are scheduled independently and are preemptible it is possible for the deadlock scenario to occur where each thread locks their first lock but both will fail to get their second lock and just spin forever. You get something like: virLXCProcessAutostartDomain (takes vm lock) --> virLXCProcessStart --> virLXCProcessConnectMonitor --> virLXCMonitorNew <...> virNetClientIncomingEvent (takes client lock) --> virNetClientIOHandleInput --> virNetClientCallDispatch --> virNetClientCallDispatchMessage --> virNetClientProgramDispatch --> virLXCMonitorHandleEventInit --> virLXCProcessMonitorInitNotify (wants vm lock but spins) <...> --> virNetClientSetCloseCallback (wants client lock but spins) Neither thread ever gets the lock it needs to be able to continue while holding the lock that the other thread needs. The actual window for preemption which can cause this deadlock is rather small, between the calls to virNetClientProgramNew() and execution of virNetClientSetCloseCallback(), both in virLXCMonitorNew(). But it can be seen in real world use that this small window is enough. By moving the call to virNetClientSetCloseCallback() ahead of virNetClientProgramNew() we can close any possible chance of the deadlock taking place. There should be no other implications to the move since the close callback (in the unlikely event was called) will spin on the vm lock. The remaining work that takes place between the old call location of virNetClientSetCloseCallback() and the new location is unaffected by the move. Signed-off-by: NMark Asselstine <mark.asselstine@windriver.com> Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Pavel Hrdina 提交于
With the introduction of cgroup v2 there are new names used with cgroups based on which version is used: - legacy: cgroup v1 - unified: cgroup v2 - hybrid: cgroup v1 and cgroup v2 Let's use 'legacy' instead of 'cgroupv1' or 'controllers' in our code. Reviewed-by: NFabiano Fidêncio <fidencio@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com> Signed-off-by: NPavel Hrdina <phrdina@redhat.com>
-
由 Pavel Hrdina 提交于
Reviewed-by: NFabiano Fidêncio <fidencio@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com> Signed-off-by: NPavel Hrdina <phrdina@redhat.com>
-
由 Pavel Hrdina 提交于
Reviewed-by: NFabiano Fidêncio <fidencio@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com> Signed-off-by: NPavel Hrdina <phrdina@redhat.com>
-
由 Pavel Hrdina 提交于
Reviewed-by: NFabiano Fidêncio <fidencio@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com> Signed-off-by: NPavel Hrdina <phrdina@redhat.com>
-
由 Pavel Hrdina 提交于
Reviewed-by: NFabiano Fidêncio <fidencio@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com> Signed-off-by: NPavel Hrdina <phrdina@redhat.com>
-
由 Pavel Hrdina 提交于
Reviewed-by: NFabiano Fidêncio <fidencio@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com> Signed-off-by: NPavel Hrdina <phrdina@redhat.com>
-
由 Pavel Hrdina 提交于
Reviewed-by: NFabiano Fidêncio <fidencio@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com> Signed-off-by: NPavel Hrdina <phrdina@redhat.com>
-
由 Pavel Hrdina 提交于
Reviewed-by: NFabiano Fidêncio <fidencio@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com> Signed-off-by: NPavel Hrdina <phrdina@redhat.com>
-