the virtual machine crushed and I cant shutdown the vm successfully
by zhouhao＠vip.friendtimes.net
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
4 years, 7 months
[oVirt] [CQ weekly status] [13-09-2019]
by Dusan Fodor
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/
4 years, 7 months
[OST] Otopi error
by Ales Musil
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-mast...
--
Ales Musil
Associate Software Engineer - RHV Network
Red Hat EMEA <https://www.redhat.com>
amusil(a)redhat.com IM: amusil
<https://red.ht/sig>
4 years, 7 months
VM crushed and cant shutdown successfully,I shoud to reboot the ovirt-node machine
by zhouhao＠vip.friendtimes.net
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
4 years, 7 months
Reinitialize Data Center with corrupted Master Domain
by scott.fitzgerald＠oracle.com
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.
4 years, 7 months
[VDSM] storage python 3 tests status
by Nir Soffer
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
4 years, 7 months
Ovirt Manager - FATAL: the database system is in recovery mode
by Sameer Sardar
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)
4 years, 7 months
