September 2019 - Devel - oVirt List Archives

the virtual machine crushed and I cant shutdown the vm successfully
by zhouhao＠vip.friendtimes.net 17 Sep '19

17 Sep '19

The trouble bothered me for a long time;Some times my vm will crush and I cant shutdown it,I had to reboot the ovirt-node to slove it; the vm's error below The ovirt-node's error below The vm's threading on the ovirt-node, the IO ratio is 100% and the vm's process change to defunct I can not kill it,every time I had to shutdown the ovirt-node on the engine website ,the vm's status always in the way to shutdown ,even if I wait for it for hours; It either failed or is shutting down and the "power off" cant shutdown the vm too. ---------------------------------------------------------------- The other infomation about my ovirt-node node-version： node hardware zhouhao(a)vip.friendtimes.net

2 2

[oVirt] [CQ weekly status] [13-09-2019]
by Dusan Fodor 14 Sep '19

14 Sep '19

Hi, This mail is to provide the current status of CQ and allow people to review status before and after the weekend. Please refer to below colour map for further information on the meaning of the colours. *CQ-4.3*: GREEN (#3) No failure this week. *CQ-Master:* RED (#1) Last failure was on 12-09 was for ovirt-engine on adding storage domain. The issue is under investigation under thread "random failures for add_master_storage_domain". Current running jobs for 4.3 [1] and master [2] can be found here: [1] https://jenkins.ovirt.org/view/Change%20queue%20jobs/job/ovirt -4.3_change-queue-tester/ [2] http://jenkins.ovirt.org/view/Change%20queue%20jobs/job/ovirt -master_change-queue-tester/ Have a nice week! Dusan ------------------------------------------------------------------------------------------------------------------- COLOUR MAP Green = job has been passing successfully ** green for more than 3 days may suggest we need a review of our test coverage 1. 1-3 days GREEN (#1) 2. 4-7 days GREEN (#2) 3. Over 7 days GREEN (#3) Yellow = intermittent failures for different projects but no lasting or current regressions ** intermittent would be a healthy project as we expect a number of failures during the week ** I will not report any of the solved failures or regressions. 1. Solved job failures YELLOW (#1) 2. Solved regressions YELLOW (#2) Red = job has been failing ** Active Failures. The colour will change based on the amount of time the project/s has been broken. Only active regressions would be reported. 1. 1-3 days RED (#1) 2. 4-7 days RED (#2) 3. Over 7 days RED (#3) _______________________________________________ Devel mailing list -- devel(a)ovirt.org To unsubscribe send an email to devel-leave(a)ovirt.org Privacy Statement: https://www.ovirt.org/site/privacy-policy/ oVirt Code of Conduct: https://www.ovirt .org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/devel@ovirt .org/message/YCNCKRK3G4EJXA3OCYAUS4VMKRDA67F4/

1 0

[OST] Otopi error
by Ales Musil 12 Sep '19

12 Sep '19

Hi, I have seen otopi error in few last builds [1]: *04:18:56* Version: otopi-1.9.0_master (otopi-1.9.0-0.0.master.20190908102607.git6eb2c28.el7)*04:18:56* [ ERROR ] "after" parameter of method "otopi.plugins.gr_he_common.network.bridge.Plugin._detect_bridges" refers to a method name "ohosted.core.require.answerfile", but no method with this name exists*04:18:56* [ ERROR ] "before" parameter of method "otopi.plugins.gr_he_common.vm.boot_disk.Plugin._customization_ansible" refers to a method name "ohosted.configuration.ovf", but no method with this name exists*04:18:56* [ ERROR ] "after" parameter of method "otopi.plugins.gr_he_common.vm.boot_disk.Plugin._customization_ansible" refers to a method name "ohosted.upgrade.check.spm.host", but no method with this name exists*04:18:56* [ ERROR ] "after" parameter of method "otopi.plugins.gr_he_common.vm.cpu.Plugin._customization" refers to a method name "ohosted.configuration.ovf", but no method with this name exists*04:18:56* [ ERROR ] "after" parameter of method "otopi.plugins.gr_he_common.vm.cpu.Plugin._customization" refers to a method name "ohosted.vm.cpu.model.customization", but no method with this name exists*04:18:56* [ ERROR ] "before" parameter of method "otopi.plugins.gr_he_common.vm.memory.Plugin._customization" refers to a method name "ohosted.vm.cpu.model.customization", but no method with this name exists*04:18:56* [ ERROR ] "after" parameter of method "otopi.plugins.gr_he_common.vm.memory.Plugin._customization" refers to a method name "ohosted.configuration.ovf", but no method with this name exists*04:18:56* [ ERROR ] "after" parameter of method "otopi.plugins.gr_he_common.vm.cloud_init.Plugin._customization" refers to a method name "ohosted.configuration.ovf", but no method with this name exists*04:18:56* [ ERROR ] "after" parameter of method "otopi.plugins.gr_he_common.vm.cloud_init.Plugin._customization" refers to a method name "ohosted.upgrade.check.upgrade.ver", but no method with this name exists*04:18:56* [ ERROR ] "after" parameter of method "otopi.plugins.gr_he_common.vm.mac.Plugin._customization" refers to a method name "ohosted.configuration.ovf", but no method with this name exists*04:18:56* [ ERROR ] "after" parameter of method "otopi.plugins.gr_he_common.core.misc.Plugin._persist_files_start" refers to a method name "ohosted.engine.ha.start", but no method with this name exists*04:18:56* [ ERROR ] Failed to execute stage 'Environment setup': Found bad "before" or "after" parameters Any idea what might be wrong? Thank you. [1] https://jenkins.ovirt.org/job/ovirt-system-tests_he-basic-ipv6-suite-master… -- Ales Musil Associate Software Engineer - RHV Network Red Hat EMEA <https://www.redhat.com> amusil(a)redhat.com IM: amusil <https://red.ht/sig>

2 1

VM crushed and cant shutdown successfully,I shoud to reboot the ovirt-node machine
by zhouhao＠vip.friendtimes.net 12 Sep '19

12 Sep '19

VM crushed and cant shutdown successfully,It always on the way to shutdown，even if I wait it for 10 hours；Everytimes I shoud to reboot the ovirt-node machine This comes up 4 times, It appes both on the ovirt-noe 4.3 and 4.2; This bug appers when my VM is running at high load（seems memory and disk's w/r） My storage domain is local on host; When the bug appers,it could cost my node's io,looks like the picture below；But sometimes it will not The vm's threading on the ovirt-node, the IO ratio is 100% Everytime the vm's process will change to defunct I can not kill it,I had to shutdown the ovirt-node on the engine website ,the vm's status always in the way to shutdown ,even if I wait for it for hours; It either failed or is shutting down and the "power off" cant shutdown the vm too. the vm's error below The ovirt-node's error below ---------------------------------------------------------------- The other infomation about my ovirt-node node-version： node hardware zhouhao(a)vip.friendtimes.net

1 0

ovirt-vmconsole package issues
by Marcin Sobczyk 11 Sep '19

11 Sep '19

Hi, we get a lot of failures in the CI for el7 and fc29 regarding this package since this morning, i.e. for fc29: <https://jenkins.ovirt.org/blue/organizations/jenkins/vdsm_standard-check-pa…>[2019-09-11T07:55:42.107Z] [MIRROR] ovirt-vmconsole-1.0.7-3.fc29.noarch.rpm: Interrupted by header callback: Server reports Content-Length: 38712 but expected size is: 38804 <https://jenkins.ovirt.org/blue/organizations/jenkins/vdsm_standard-check-pa…>[2019-09-11T07:55:42.107Z] [MIRROR] ovirt-vmconsole-1.0.7-3.fc29.noarch.rpm: Interrupted by header callback: Server reports Content-Length: 38712 but expected size is: 38804 <https://jenkins.ovirt.org/blue/organizations/jenkins/vdsm_standard-check-pa…>[2019-09-11T07:55:42.107Z] [MIRROR] ovirt-vmconsole-1.0.7-3.fc29.noarch.rpm: Interrupted by header callback: Server reports Content-Length: 38712 but expected size is: 38804 <https://jenkins.ovirt.org/blue/organizations/jenkins/vdsm_standard-check-pa…>[2019-09-11T07:55:42.107Z] [MIRROR] ovirt-vmconsole-1.0.7-3.fc29.noarch.rpm: Interrupted by header callback: Server reports Content-Length: 38712 but expected size is: 38804 <https://jenkins.ovirt.org/blue/organizations/jenkins/vdsm_standard-check-pa…>[2019-09-11T07:55:42.107Z] [FAILED] ovirt-vmconsole-1.0.7-3.fc29.noarch.rpm: No more mirrors to try - All mirrors were already tried without success <https://jenkins.ovirt.org/blue/organizations/jenkins/vdsm_standard-check-pa…>[2019-09-11T07:55:42.107Z] Error: Error downloading packages: <https://jenkins.ovirt.org/blue/organizations/jenkins/vdsm_standard-check-pa…>[2019-09-11T07:55:42.107Z] Cannot download noarch/ovirt-vmconsole-1.0.7-3.fc29.noarch.rpm: All mirrors were tried Can someone take a look at this? Thanks, Marcin

3 2

Change Data Centre type from Local to Shared and vice versa
by scott.fitzgerald＠oracle.com 11 Sep '19

11 Sep '19

Hi all, How does one change a Data Centre type between Local/Shared through the SDK? Assume it's done through the systemService, but can't seem to find it. Cheers.

3 7

Reinitialize Data Center with corrupted Master Domain
by scott.fitzgerald＠oracle.com 11 Sep '19

11 Sep '19

Hi all, In the system I currently have a Data Center with a corrupted Master Domain, and a spare, unattached Domain. How do I use the SDK to reinitialize the Data Center by attaching the unattached Domain? Simply reattaching it doesn't seem to register as a proper re initialization, despite the system showing an active status for the data center after the attachment. Cheers.

2 2

[VDSM] storage python 3 tests status
by Nir Soffer 10 Sep '19

10 Sep '19

Sharing progress on python 3 work. ## 2 weeks ago git checkout @{two.weeks.ago} tox -e storage-py37 ... 1448 passed, 103 skipped, 100 deselected, 322 xfailed, 236 warnings in 71.40 seconds ## Today git checkout tox -e storage-py37 ... 1643 passed, 103 skipped, 100 deselected, 105 xfailed, 82 xpassed, 107 warnings in 79.72 seconds Change: *passed: +195* *skips: 0* *xfail: -217* *xpass: +107* *warnings: -129* ## XPASS 107 xpass are most likely easy fix, just remove the xfail() mark from the test or parameter. Patches should not introduce new XPASS, you should remove all xfail() marks that a patch fixes. To test that your patch do not introduce new XPASS, add this option to tox.ini: [pytest] xfail_strict = True This converts XPASS to FAIL. These modules need to be fixed: $ egrep '^storage.+_test.py.+X' storage-py37.out storage/filevolume_test.py ...XXXxXXXXxXXX [ 19%] storage/formatconverter_test.py XXXXXxxss [ 20%] storage/merge_test.py XXXXXXxxxxXXxXxxxxxXxxxxxx [ 38%] storage/nbd_test.py ssssssssssssX. [ 49%] storage/sd_manifest_test.py XXXXXXXXXxxxxxxxxxxxxxxxxxxxxxxx............ [ 65%] storage/sdm_amend_volume_test.py xXxXxXxX [ 66%] storage/sdm_copy_data_test.py xXXxxxxXXXXXxxxXXXxxXXxxXXx [ 67%] storage/sdm_merge_test.py xxxxXXX [ 79%] storage/sdm_update_volume_test.py xXxXxxXXxxXXxXxXxXxX....... [ 81%] storage/testlib_test.py xXXXxxXXXXXXXXxxxxxxxxxxxxxXxXxXxX.......... [ 87%] storage/volume_metadata_test.py ..........................X............. [ 90%] ## xfail We must fix these xfail before we can run OST. If we start running OST we will waste days debugging OST. Debugging failing tests is 1000X times faster. $ egrep '^storage.+_test.py.+x' storage-py37.out storage/blocksd_test.py ........x..........sssssssssss............ [ 4%] storage/blockvolume_test.py ...........xxxxxxxxx [ 5%] storage/fileutil_test.py ..xx....ss............................ [ 19%] storage/filevolume_test.py ...XXXxXXXXxXXX [ 19%] storage/formatconverter_test.py XXXXXxxss [ 20%] storage/merge_test.py XXXXXXxxxxXXxXxxxxxXxxxxxx [ 38%] storage/sd_manifest_test.py XXXXXXXXXxxxxxxxxxxxxxxxxxxxxxxx............ [ 65%] storage/sdm_amend_volume_test.py xXxXxXxX [ 66%] storage/sdm_copy_data_test.py xXXxxxxXXXXXxxxXXXxxXXxxXXx [ 67%] storage/sdm_merge_test.py xxxxXXX [ 79%] storage/sdm_update_volume_test.py xXxXxxXXxxXXxXxXxXxX....... [ 81%] storage/testlib_test.py xXXXxxXXXXXXXXxxxxxxxxxxxxxXxXxXxX.......... [ 87%] ## Skips Skips should be used only when test cannot run on specific environment, but I think we have some wrong skips that should have been xfail. $ egrep '^storage.+_test.py.+s' storage-py37.out storage/backends_test.py ss [ 2%] storage/blockdev_test.py ssss....s [ 2%] storage/blocksd_test.py ........x..........sssssssssss............ [ 4%] storage/devicemapper_test.py s. [ 9%] storage/fileutil_test.py ..xx....ss............................ [ 19%] storage/formatconverter_test.py XXXXXxxss [ 20%] storage/loopback_test.py ssss [ 31%] storage/lvm_test.py ....................ssssssssssssssssssss [ 33%] storage/lvmfilter_test.py .....ss.......... [ 35%] storage/managedvolume_test.py ssssssssssssssssss.... [ 36%] storage/misc_test.py .................sssssssss...............ssss...... [ 41%] storage/mount_test.py .........ss........ssssss [ 47%] storage/nbd_test.py ssssssssssssX. [ 49%] storage/udev_multipath_test.py .......................s [ 88%] ## Warnings See "warnings summary" in pytest output. Looks less useful, report issues in packages we use instead of issues in our code. But this may be an issue using old versions of packages. See attached results created with: tox -e storage-py37 > storage-py37.out 2>&1 Nir

2 3

oVirt conference 2019 - Rome - October 4th
by Sandro Bonazzola 10 Sep '19

10 Sep '19

The oVirt Italian community <https://www.facebook.com/groups/ovirt.italia/> and Extraordy <https://www.extraordy.com/> in collaboration with Red Hat <https://www.redhat.com>, Oracle <https://www.oracle.com>, and Storware <https://storware.eu/> are pleased to invite you at oVirt Conference 2019 in Rome on October 4th 2019! Tickets are available at https://www.eventbrite.it/e/biglietti-ovirt-conference-2019-innovate-the-da… Thanks -- Sandro Bonazzola MANAGER, SOFTWARE ENGINEERING, EMEA R&D RHV Red Hat EMEA <https://www.redhat.com/> sbonazzo(a)redhat.com <https://www.redhat.com/>*Red Hat respects your work life balance. Therefore there is no need to answer this email out of your office hours.*

1 0

Ovirt Manager - FATAL: the database system is in recovery mode
by Sameer Sardar 10 Sep '19

10 Sep '19

PACKAGE_NAME="ovirt-engine" PACKAGE_VERSION="3.6.2.6" PACKAGE_DISPLAY_VERSION="3.6.2.6-1.el6" OPERATING SYSTEM="Centos 6.7" Its been running error-free for over 3 years now. Over the past few weeks, The Ovirt manager application has been frequently losing connection with its own database residing on the same server. It is throwing up errors saying: “Caused by org.postgresql.util.PSQLException: FATAL: the database system is in recovery mode”. The only means we have found to recover from this is to hard reboot the server, after which it works fine for a couple of days before throwing up these errors again. Here are some logs : Caused by: org.postgresql.util.PSQLException: FATAL: the database system is in recovery mode at org.postgresql.core.v3.ConnectionFactoryImpl.doAuthentication(ConnectionFactoryImpl.java:293) at org.postgresql.core.v3.ConnectionFactoryImpl.openConnectionImpl(ConnectionFactoryImpl.java:108) at org.postgresql.core.ConnectionFactory.openConnection(ConnectionFactory.java:66) at org.postgresql.jdbc2.AbstractJdbc2Connection.<init>(AbstractJdbc2Connection.java:125) at org.postgresql.jdbc3.AbstractJdbc3Connection.<init>(AbstractJdbc3Connection.java:30) at org.postgresql.jdbc3g.AbstractJdbc3gConnection.<init>(AbstractJdbc3gConnection.java:22) at org.postgresql.jdbc4.AbstractJdbc4Connection.<init>(AbstractJdbc4Connection.java:32) at org.postgresql.jdbc4.Jdbc4Connection.<init>(Jdbc4Connection.java:24) at org.postgresql.Driver.makeConnection(Driver.java:393) at org.postgresql.Driver.connect(Driver.java:267) at org.jboss.jca.adapters.jdbc.local.LocalManagedConnectionFactory.createLocalManagedConnection(LocalManagedConnectionFactory.java:322)

3 4