- CI - libvirt List Archives

[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

[Libvirt-ci] Build failed in Jenkins: libvirt-dbus-check » libvirt-freebsd-10 #39
by ci＠centos.org 24 Sep '18

24 Sep '18

See <https://ci.centos.org/job/libvirt-dbus-check/systems=libvirt-freebsd-10/39/…> ------------------------------------------ [...truncated 3.85 KB...] Making check in data gmake[1]: Entering directory '/usr<https://ci.centos.org/job/libvirt-dbus-check/systems=libvirt-freebsd-10/ws/…'> gmake[1]: Nothing to be done for 'check'. gmake[1]: Leaving directory '/usr<https://ci.centos.org/job/libvirt-dbus-check/systems=libvirt-freebsd-10/ws/…'> Making check in docs gmake[1]: Entering directory '/usr<https://ci.centos.org/job/libvirt-dbus-check/systems=libvirt-freebsd-10/ws/…'> gmake[1]: Nothing to be done for 'check'. gmake[1]: Leaving directory '/usr<https://ci.centos.org/job/libvirt-dbus-check/systems=libvirt-freebsd-10/ws/…'> Making check in src gmake[1]: Entering directory '/usr<https://ci.centos.org/job/libvirt-dbus-check/systems=libvirt-freebsd-10/ws/…'> gmake[1]: Nothing to be done for 'check'. gmake[1]: Leaving directory '/usr<https://ci.centos.org/job/libvirt-dbus-check/systems=libvirt-freebsd-10/ws/…'> Making check in tests gmake[1]: Entering directory '/usr<https://ci.centos.org/job/libvirt-dbus-check/systems=libvirt-freebsd-10/ws/…'> /usr/local/bin/gmake test_util gmake[2]: Entering directory '/usr<https://ci.centos.org/job/libvirt-dbus-check/systems=libvirt-freebsd-10/ws/…'> CC test_util-test_util.o CCLD test_util gmake[2]: Leaving directory '/usr<https://ci.centos.org/job/libvirt-dbus-check/systems=libvirt-freebsd-10/ws/…'> /usr/local/bin/gmake check-TESTS gmake[2]: Entering directory '/usr<https://ci.centos.org/job/libvirt-dbus-check/systems=libvirt-freebsd-10/ws/…'> gmake[3]: Entering directory '/usr<https://ci.centos.org/job/libvirt-dbus-check/systems=libvirt-freebsd-10/ws/…'> PASS: test_util PASS: test_interface.py PASS: test_domain.py PASS: test_network.py FAIL: test_connect.py PASS: test_nodedev.py PASS: test_storage.py ============================================================================ Testsuite summary for libvirt-dbus 1.3.0 ============================================================================ # TOTAL: 7 # PASS: 6 # SKIP: 0 # XFAIL: 0 # FAIL: 1 # XPASS: 0 # ERROR: 0 ============================================================================ See tests/test-suite.log Please report to libvir-list(a)redhat.com ============================================================================ gmake[3]: *** [Makefile:766: test-suite.log] Error 1 gmake[3]: Leaving directory '/usr<https://ci.centos.org/job/libvirt-dbus-check/systems=libvirt-freebsd-10/ws/…'> gmake[2]: *** [Makefile:874: check-TESTS] Error 2 gmake[2]: Leaving directory '/usr<https://ci.centos.org/job/libvirt-dbus-check/systems=libvirt-freebsd-10/ws/…'> gmake[1]: *** [Makefile:990: check-am] Error 2 gmake[1]: Leaving directory '/usr<https://ci.centos.org/job/libvirt-dbus-check/systems=libvirt-freebsd-10/ws/…'> gmake: *** [Makefile:460: check-recursive] Error 1 + cat tests/test-suite.log ============================================== libvirt-dbus 1.3.0: tests/test-suite.log ============================================== # TOTAL: 7 # PASS: 6 # SKIP: 0 # XFAIL: 0 # FAIL: 1 # XPASS: 0 # ERROR: 0 .. contents:: :depth: 2 FAIL: test_connect.py ===================== ============================= test session starts ============================== platform freebsd10 -- Python 3.6.5, pytest-3.4.2, py-1.5.3, pluggy-0.6.0 rootdir: /usr<https://ci.centos.org/job/libvirt-dbus-check/systems=libvirt-freebsd-10/ws/,> inifile: collected 35 items ../../tests/test_connect.py ......E........E..................E [100%] ==================================== ERRORS ==================================== ___________ ERROR at setup of TestConnect.test_connect_list_domains ____________ self = <test_connect.TestConnect object at 0x809560710> request = <SubRequest 'libvirt_dbus_setup' for <Function 'test_connect_list_domains'>> @pytest.fixture(autouse=True) def libvirt_dbus_setup(self, request): """Start libvirt-dbus for each test function """ os.environ['LIBVIRT_DEBUG'] = '3' self.libvirt_dbus = subprocess.Popen([exe, '--session']) self.bus = dbus.SessionBus() for i in range(10): if self.bus.name_has_owner('org.libvirt'): break time.sleep(0.1) else: > raise TimeoutError('error starting libvirt-dbus') E TimeoutError: error starting libvirt-dbus ../../tests/libvirttest.py:44: TimeoutError ERROR at setup of TestConnect.test_connect_interface_lookup_by_property[InterfaceLookupByMAC-MAC] self = <test_connect.TestConnect object at 0x809504e48> @pytest.fixture def interface_create(self): """ Fixture to define dummy interface on the test driver This fixture should be used in the setup of every test manipulating with interfaces. """ path = self.connect.InterfaceDefineXML(xmldata.minimal_interface_xml, 0) obj = self.bus.get_object('org.libvirt', path) interface_obj = dbus.Interface(obj, 'org.libvirt.Interface') > interface_obj.Create(0) ../../tests/libvirttest.py:84: _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ /usr/local/lib/python3.6/site-packages/dbus/proxies.py:70: in __call__ return self._proxy_method(*args, **keywords) /usr/local/lib/python3.6/site-packages/dbus/proxies.py:145: in __call__ **keywords) _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ self = <dbus._dbus.SessionBus (session) at 0x8090b46d0> bus_name = dbus.String(':1.7') object_path = dbus.ObjectPath('/org/libvirt/Test/interface/11_3a22_3a33_3a44_3a55_3a66') dbus_interface = 'org.libvirt.Interface', method = 'Create', signature = 'u' args = (0,), timeout = -1.0, byte_arrays = False, kwargs = {} get_args_opts = {'byte_arrays': False} message = <dbus.lowlevel.MethodCallMessage path: /org/libvirt/Test/interface/11_3a22_3a33_3a44_3a55_3a66, iface: org.libvirt.Interface, member: Create dest: :1.7> def call_blocking(self, bus_name, object_path, dbus_interface, method, signature, args, timeout=-1.0, byte_arrays=False, **kwargs): """Call the given method, synchronously. :Since: 0.81.0 """ if object_path == LOCAL_PATH: raise DBusException('Methods may not be called on the reserved ' 'path %s' % LOCAL_PATH) if dbus_interface == LOCAL_IFACE: raise DBusException('Methods may not be called on the reserved ' 'interface %s' % LOCAL_IFACE) # no need to validate other args - MethodCallMessage ctor will do get_args_opts = dict(byte_arrays=byte_arrays) if is_py2: get_args_opts['utf8_strings'] = kwargs.get('utf8_strings', False) elif 'utf8_strings' in kwargs: raise TypeError("unexpected keyword argument 'utf8_strings'") message = MethodCallMessage(destination=bus_name, path=object_path, interface=dbus_interface, method=method) # Add the arguments to the function try: message.append(signature=signature, *args) except Exception as e: logging.basicConfig() _logger.error('Unable to set arguments %r according to ' 'signature %r: %s: %s', args, signature, e.__class__, e) raise # make a blocking call reply_message = self.send_message_with_reply_and_block( > message, timeout) E dbus.exceptions.DBusException: org.libvirt.Error: Requested operation is not valid /usr/local/lib/python3.6/site-packages/dbus/connection.py:651: DBusException ERROR at setup of TestConnect.test_connect_storage_vol_lookup_by_property[StorageVolLookupByPath-Path] self = <test_connect.TestConnect object at 0x809606160> @pytest.fixture def storage_volume_create(self): """ Fixture to create dummy storage volume on the test driver This fixture should be used in the setup of every test manipulating with test volume. """ _, test_storage_pool = self.get_test_storage_pool() interface_obj = dbus.Interface(test_storage_pool, 'org.libvirt.StoragePool') > path = interface_obj.StorageVolCreateXML(xmldata.minimal_storage_vol_xml, 0) ../../tests/libvirttest.py:122: _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ /usr/local/lib/python3.6/site-packages/dbus/proxies.py:70: in __call__ return self._proxy_method(*args, **keywords) /usr/local/lib/python3.6/site-packages/dbus/proxies.py:145: in __call__ **keywords) _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ self = <dbus._dbus.SessionBus (session) at 0x8090b46d0> bus_name = dbus.String(':1.7') object_path = dbus.ObjectPath('/org/libvirt/Test/storagepool/_35bb2ad9_388a_cdfe_461a_b8907f6e53fe') dbus_interface = 'org.libvirt.StoragePool', method = 'StorageVolCreateXML' signature = 'su' args = ('\n<volume>\n <name>sparse.img</name>\n <capacity unit="G">2</capacity>\n <target>\n <path>/var/lib/virt/images/sparse.img</path>\n </target>\n</volume>\n', 0) timeout = -1.0, byte_arrays = False, kwargs = {} get_args_opts = {'byte_arrays': False} message = <dbus.lowlevel.MethodCallMessage path: /org/libvirt/Test/storagepool/_35bb2ad9_388a_cdfe_461a_b8907f6e53fe, iface: org.libvirt.StoragePool, member: StorageVolCreateXML dest: :1.7> def call_blocking(self, bus_name, object_path, dbus_interface, method, signature, args, timeout=-1.0, byte_arrays=False, **kwargs): """Call the given method, synchronously. :Since: 0.81.0 """ if object_path == LOCAL_PATH: raise DBusException('Methods may not be called on the reserved ' 'path %s' % LOCAL_PATH) if dbus_interface == LOCAL_IFACE: raise DBusException('Methods may not be called on the reserved ' 'interface %s' % LOCAL_IFACE) # no need to validate other args - MethodCallMessage ctor will do get_args_opts = dict(byte_arrays=byte_arrays) if is_py2: get_args_opts['utf8_strings'] = kwargs.get('utf8_strings', False) elif 'utf8_strings' in kwargs: raise TypeError("unexpected keyword argument 'utf8_strings'") message = MethodCallMessage(destination=bus_name, path=object_path, interface=dbus_interface, method=method) # Add the arguments to the function try: message.append(signature=signature, *args) except Exception as e: logging.basicConfig() _logger.error('Unable to set arguments %r according to ' 'signature %r: %s: %s', args, signature, e.__class__, e) raise # make a blocking call reply_message = self.send_message_with_reply_and_block( > message, timeout) E dbus.exceptions.DBusException: org.libvirt.Error: operation failed: storage vol already exists /usr/local/lib/python3.6/site-packages/dbus/connection.py:651: DBusException ===================== 32 passed, 3 error in 14.54 seconds ====================== FAIL test_connect.py (exit status: 1) + exit 1 Build step 'Execute shell' marked build as failure

1 1