September 2018 - CI - libvirt List Archives

[Libvirt-ci] Still Failing: libvirt/libvirt#1724 (master - e94415d)
by Travis CI 26 Sep '18

26 Sep '18

Build Update for libvirt/libvirt ------------------------------------- Build: #1724 Status: Still Failing Duration: 19 mins and 50 secs Commit: e94415d (master) Author: Ján Tomko Message: tests: libxl: skip tests with nested_hvm Commit 95d19cd 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: Ján Tomko <jtomko(a)redhat.com> Reviewed-by: Erik Skultety <eskultet(a)redhat.com> View the changeset: https://github.com/libvirt/libvirt/compare/79e0e62e78ea...e94415d5a578 View the full build log and details: https://travis-ci.org/libvirt/libvirt/builds/433546256?utm_medium=notificat… -- You can unsubscribe from build emails from the libvirt/libvirt repository going to https://travis-ci.org/account/preferences/unsubscribe?repository=4872032&ut…. Or unsubscribe from *all* email updating your settings at https://travis-ci.org/account/preferences/unsubscribe?utm_medium=notificati…. Or configure specific recipients for build notifications in your .travis.yml file. See https://docs.travis-ci.com/user/notifications.

1 0

[Libvirt-ci] Still Failing: libvirt/libvirt#1723 (master - 79e0e62)
by Travis CI 26 Sep '18

26 Sep '18

Build Update for libvirt/libvirt ------------------------------------- Build: #1723 Status: Still Failing Duration: 18 mins and 50 secs Commit: 79e0e62 (master) Author: Lin Ma Message: qemu: Remove network type limitation for qemuARPGetInterfaces 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: Lin Ma <lma(a)suse.com> Reviewed-by: Chen Hanxiao <chenhanxiao(a)gmail.com> View the changeset: https://github.com/libvirt/libvirt/compare/cd33eaa2513a...79e0e62e78ea View the full build log and details: https://travis-ci.org/libvirt/libvirt/builds/433493747?utm_medium=notificat… -- You can unsubscribe from build emails from the libvirt/libvirt repository going to https://travis-ci.org/account/preferences/unsubscribe?repository=4872032&ut…. Or unsubscribe from *all* email updating your settings at https://travis-ci.org/account/preferences/unsubscribe?utm_medium=notificati…. Or configure specific recipients for build notifications in your .travis.yml file. See https://docs.travis-ci.com/user/notifications.

1 0

[Libvirt-ci] Failed: libvirt/libvirt#1722 (v4.8.0-rc1 - cd33eaa)
by Travis CI 26 Sep '18

26 Sep '18

Build Update for libvirt/libvirt ------------------------------------- Build: #1722 Status: Failed Duration: 18 mins and 17 secs Commit: cd33eaa (v4.8.0-rc1) Author: Michal Privoznik Message: security: Don't try to lock NULL paths 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: Michal Privoznik <mprivozn(a)redhat.com> Reviewed-by: Erik Skultety <eskultet(a)redhat.com> View the changeset: https://github.com/libvirt/libvirt/compare/v4.8.0-rc1 View the full build log and details: https://travis-ci.org/libvirt/libvirt/builds/433485562?utm_medium=notificat… -- You can unsubscribe from build emails from the libvirt/libvirt repository going to https://travis-ci.org/account/preferences/unsubscribe?repository=4872032&ut…. Or unsubscribe from *all* email updating your settings at https://travis-ci.org/account/preferences/unsubscribe?utm_medium=notificati…. Or configure specific recipients for build notifications in your .travis.yml file. See https://docs.travis-ci.com/user/notifications.

1 0

[Libvirt-ci] Still Failing: libvirt/libvirt#1721 (master - cd33eaa)
by Travis CI 26 Sep '18

26 Sep '18

Build Update for libvirt/libvirt ------------------------------------- Build: #1721 Status: Still Failing Duration: 17 mins and 49 secs Commit: cd33eaa (master) Author: Michal Privoznik Message: security: Don't try to lock NULL paths 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: Michal Privoznik <mprivozn(a)redhat.com> Reviewed-by: Erik Skultety <eskultet(a)redhat.com> View the changeset: https://github.com/libvirt/libvirt/compare/9580c091635d...cd33eaa2513a View the full build log and details: https://travis-ci.org/libvirt/libvirt/builds/433414202?utm_medium=notificat… -- You can unsubscribe from build emails from the libvirt/libvirt repository going to https://travis-ci.org/account/preferences/unsubscribe?repository=4872032&ut…. Or unsubscribe from *all* email updating your settings at https://travis-ci.org/account/preferences/unsubscribe?utm_medium=notificati…. Or configure specific recipients for build notifications in your .travis.yml file. See https://docs.travis-ci.com/user/notifications.

1 0

[Libvirt-ci] Still Failing: libvirt/libvirt#1720 (master - 9580c09)
by Travis CI 26 Sep '18

26 Sep '18

Build Update for libvirt/libvirt ------------------------------------- Build: #1720 Status: Still Failing Duration: 18 mins and 31 secs Commit: 9580c09 (master) Author: Marc Hartmayer Message: virdbus: Use the mnemonic macros for dbus_bool_t values Use the mnemonic macros of libdbus for 1 (TRUE) and 0 (FALSE). Signed-off-by: Marc Hartmayer <mhartmay(a)linux.ibm.com> Reviewed-by: Bjoern Walk <bwalk(a)linux.ibm.com> Reviewed-by: Boris Fiuczynski <fiuczy(a)linux.ibm.com> Reviewed-by: Stefan Zimmermann <stzi(a)linux.ibm.com> Reviewed-by: John Ferlan <jferlan(a)redhat.com> View the changeset: https://github.com/libvirt/libvirt/compare/e6d77a75c4bf...9580c091635d View the full build log and details: https://travis-ci.org/libvirt/libvirt/builds/433213453?utm_medium=notificat… -- You can unsubscribe from build emails from the libvirt/libvirt repository going to https://travis-ci.org/account/preferences/unsubscribe?repository=4872032&ut…. Or unsubscribe from *all* email updating your settings at https://travis-ci.org/account/preferences/unsubscribe?utm_medium=notificati…. Or configure specific recipients for build notifications in your .travis.yml file. See https://docs.travis-ci.com/user/notifications.

1 0

[Libvirt-ci] Still Failing: libvirt/libvirt#1719 (master - e6d77a7)
by Travis CI 25 Sep '18

25 Sep '18

Build Update for libvirt/libvirt ------------------------------------- Build: #1719 Status: Still Failing Duration: 18 mins and 31 secs Commit: e6d77a7 (master) Author: Jiri Denemark Message: qemu: Avoid duplicate resume events and state changes 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=1612943 Signed-off-by: Jiri Denemark <jdenemar(a)redhat.com> Reviewed-by: John Ferlan <jferlan(a)redhat.com> View the changeset: https://github.com/libvirt/libvirt/compare/7882c6eca53f...e6d77a75c4bf View the full build log and details: https://travis-ci.org/libvirt/libvirt/builds/433098800?utm_medium=notificat… -- You can unsubscribe from build emails from the libvirt/libvirt repository going to https://travis-ci.org/account/preferences/unsubscribe?repository=4872032&ut…. Or unsubscribe from *all* email updating your settings at https://travis-ci.org/account/preferences/unsubscribe?utm_medium=notificati…. Or configure specific recipients for build notifications in your .travis.yml file. See https://docs.travis-ci.com/user/notifications.

1 0

[Libvirt-ci] Still Failing: libvirt/libvirt#1718 (master - 7882c6e)
by Travis CI 25 Sep '18

25 Sep '18

Build Update for libvirt/libvirt ------------------------------------- Build: #1718 Status: Still Failing Duration: 19 mins and 18 secs Commit: 7882c6e (master) Author: Mark Asselstine Message: lxc_monitor: Avoid AB / BA lock race 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: Mark Asselstine <mark.asselstine(a)windriver.com> Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com> View the changeset: https://github.com/libvirt/libvirt/compare/65ba48d26745...7882c6eca53f View the full build log and details: https://travis-ci.org/libvirt/libvirt/builds/433006111?utm_medium=notificat… -- You can unsubscribe from build emails from the libvirt/libvirt repository going to https://travis-ci.org/account/preferences/unsubscribe?repository=4872032&ut…. Or unsubscribe from *all* email updating your settings at https://travis-ci.org/account/preferences/unsubscribe?utm_medium=notificati…. Or configure specific recipients for build notifications in your .travis.yml file. See https://docs.travis-ci.com/user/notifications.

1 0

[Libvirt-ci] Still Failing: libvirt/libvirt#1717 (master - 65ba48d)
by Travis CI 25 Sep '18

25 Sep '18

Build Update for libvirt/libvirt ------------------------------------- Build: #1717 Status: Still Failing Duration: 18 mins and 14 secs Commit: 65ba48d (master) Author: Pavel Hrdina Message: vircgroup: rename controllers to legacy 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: Fabiano Fidêncio <fidencio(a)redhat.com> Reviewed-by: Ján Tomko <jtomko(a)redhat.com> Signed-off-by: Pavel Hrdina <phrdina(a)redhat.com> View the changeset: https://github.com/libvirt/libvirt/compare/8b62008d2bc5...65ba48d26745 View the full build log and details: https://travis-ci.org/libvirt/libvirt/builds/432924634?utm_medium=notificat… -- You can unsubscribe from build emails from the libvirt/libvirt repository going to https://travis-ci.org/account/preferences/unsubscribe?repository=4872032&ut…. Or unsubscribe from *all* email updating your settings at https://travis-ci.org/account/preferences/unsubscribe?utm_medium=notificati…. Or configure specific recipients for build notifications in your .travis.yml file. See https://docs.travis-ci.com/user/notifications.

1 0

[Libvirt-ci] Still Failing: libvirt/libvirt#1716 (master - 8b62008)
by Travis CI 25 Sep '18

25 Sep '18

Build Update for libvirt/libvirt ------------------------------------- Build: #1716 Status: Still Failing Duration: 21 mins and 2 secs Commit: 8b62008 (master) Author: Pavel Hrdina Message: vircgrouptest: call virCgroupNewSelf instead virCgroupDetectMounts This will be required once cgroup v2 is introduced. The cgroup detection is not simple and we will have multiple backends so we should not just jump into the middle of the detection code. In order to use virCgroupNewSelf we need to create all the remaining data files: - {name}.cgroups represents /proc/cgroups, it is a list of cgroup controllers compiled into kernel - {name}.self.cgroup represents /proc/self/cgroup, it describes cgroups to which the process belongs For "no-cgroups" we need to modify the expected behavior because virCgroupNewSelf() will fail if there are no controllers available. Reviewed-by: Fabiano Fidêncio <fidencio(a)redhat.com> Reviewed-by: Ján Tomko <jtomko(a)redhat.com> Signed-off-by: Pavel Hrdina <phrdina(a)redhat.com> View the changeset: https://github.com/libvirt/libvirt/compare/95d19cd01591...8b62008d2bc5 View the full build log and details: https://travis-ci.org/libvirt/libvirt/builds/432887567?utm_medium=notificat… -- You can unsubscribe from build emails from the libvirt/libvirt repository going to https://travis-ci.org/account/preferences/unsubscribe?repository=4872032&ut…. Or unsubscribe from *all* email updating your settings at https://travis-ci.org/account/preferences/unsubscribe?utm_medium=notificati…. Or configure specific recipients for build notifications in your .travis.yml file. See https://docs.travis-ci.com/user/notifications.

1 0

[Libvirt-ci] Broken: libvirt/libvirt#1715 (master - 95d19cd)
by Travis CI 25 Sep '18

25 Sep '18

Build Update for libvirt/libvirt ------------------------------------- Build: #1715 Status: Broken Duration: 20 mins and 17 secs Commit: 95d19cd (master) Author: Marek Marczykowski-Górecki Message: libxl: prefer new location of nested_hvm in libxl_domain_build_info If available, use b_info->nested_hvm instead of b_info->u.hvm.nested_hvm. This will make nested HVM config available also for PVH domains. Signed-off-by: Marek Marczykowski-Górecki <marmarek(a)invisiblethingslab.com> Reviewed-by: Jim Fehlig <jfehlig(a)suse.com> View the changeset: https://github.com/libvirt/libvirt/compare/996f101431a2...95d19cd01591 View the full build log and details: https://travis-ci.org/libvirt/libvirt/builds/432772301?utm_medium=notificat… -- You can unsubscribe from build emails from the libvirt/libvirt repository going to https://travis-ci.org/account/preferences/unsubscribe?repository=4872032&ut…. Or unsubscribe from *all* email updating your settings at https://travis-ci.org/account/preferences/unsubscribe?utm_medium=notificati…. Or configure specific recipients for build notifications in your .travis.yml file. See https://docs.travis-ci.com/user/notifications.

1 0