- Devel - oVirt List Archives

Exception request - Fedora 22 support
by Sandro Bonazzola 04 Jun '15

04 Jun '15

Hi, we're now near to feature freeze and just one week after Fedora 22 being released. Fedora 22 support is not completed yet and since it's still missing works on Jenkins and on integration side I don't think it will be ready for feature freeze. So I'm requesting exception for completing F22 support for 3.6. -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com

1 0

hibernate's internal PersistentBag sent to FE
by Tomas Jelinek 03 Jun '15

03 Jun '15

Hey all, since the org.ovirt.engine.core.common.job.Job/Step... has been moved to use the JPA we have a problem on frontend. The problem is that the @OneToMany annotations results in a List which is of type PersistentBag. When we send this to Frontend it fails during deserialization. It actually fails quite bad because the FE already has an ui-override of it which is not correct resulting in a ton of NPEs in development mode. So, there are 2 nasty fixes I have made where none of them should be merged but demonstrate the possibilities: 1: extend the FE to be able to work with the PersistentBag (https://gerrit.ovirt.org/#/c/41682/) not really good solution since the PersistenBag is an internal Hibernate class which is really not meant to be passed around 2: fix on the backend to not send the PersistentBag but an ArrayList. This is only a PoC fixed on a command we face the problem (https://gerrit.ovirt.org/#/c/41797/) Obviously this is not going to work for other commands accessing the same Job nor for other entities. So, the first option is generic but very very bad. The second option should be used but not sure how to do this in a cheep way (e.g. without using reflection to deep traverse everything sent back to frontend checking if it does not have a PersistentBag in it. Any better ideas? Thanx, Tomas

7 20

Fedora 22
by Greg Sheremeta 02 Jun '15

02 Jun '15

Anyone upgrade to F22 yet? Looking for tips on running engine after I upgrade. I assume I'll still have to install JDK 1.7 and JBoss 7. Thanks. Greg Sheremeta Red Hat, Inc. Sr. Software Engineer, RHEV Cell: 919-807-1086 gshereme(a)redhat.com

2 2

Engine rpm build fails
by Tolik Litvosky 01 Jun '15

01 Jun '15

Hi The jenkins fails to build it RPM packages http://jenkins.ovirt.org/job/ovirt-engine_master_create -rpms_merged/label=el7/3536/ The probable cause is: https://gerrit.ovirt.org/#/c/41405/ Can you please assist on fixing this. -- Best regards Tolik Litovsky RHEV-H Team Red Hat Red Hat: trustworthy, transformative technology. Powered by the community. Connect at redhat.com

5 6

[HELP] UI error after last rebase
by Eli Mesika 01 Jun '15

01 Jun '15

Hi I am getting this error on login: Operation Canceled Error while executing action: A Request to the Server failed: This application is out of date, please click the refresh button on your browser. ( The client cannot accept IoThreadsSupported ) I cleaned my browser cache .... Any ideas Thanks Eli Mesika

2 2

Termin gestrichen: oVirt Node weekly meeting - Mo 1. Jun. 2015 16:00 - 16:30 (fdeutsch@redhat.com)
by fdeutsch＠redhat.com 01 Jun '15

01 Jun '15

Dieser Termin wurde gestrichen und aus Ihrem Kalender entfernt. Titel: oVirt Node weekly meeting Hey, this is an invitation to the weekly oVirt Node devel meetings. Anyone interested or related to Node development is welcome. Wann: Mo 1. Jun. 2015 16:00 - 16:30 Berlin Wo: irc://irc.oftc.net#ovirt Kalender: fdeutsch(a)redhat.com Wer * Fabian Deutsch - Organisator * wdaniel(a)redhat.com * tlitovsk(a)redhat.com * devel(a)ovirt.org Einladung von Google Kalender: https://www.google.com/calendar/ Sie erhalten diese E-Mail unter devel(a)ovirt.org, da Sie ein Gast bei diesem Termin sind. Lehnen Sie diesen Termin ab, um keine weiteren Informationen zu diesem Termin zu erhalten. Sie können auch unter https://www.google.com/calendar/ ein Google-Konto erstellen und Ihre Benachrichtigungseinstellungen für Ihren gesamten Kalender steuern.

1 0

oVirt node 3.6 and CPU load indefinitely stuck on 100% while vdsmd indefinitely tries to restart
by Simone Tiraboschi 01 Jun '15

01 Jun '15

Hi, I tried to have hosted-engine deploying the engine appliance over oVirt node. I think it will be quite a common scenario. I tried with an oVirt node build from yesterday. Unfortunately I'm not able to conclude the setup cause oVirt node got the CPU load indefinitely stuck on 100% and so it's almost unresponsive. The issue seams to be related to vdsmd daemon witch couldn't really start and so it retries indefinitely using all the available CPU power (it also runs with niceless -20...). [root@node36 admin]# grep "Unit vdsmd.service entered failed state." /var/log/messages | wc -l 368 It tried 368 times in a row in a few minutes. With journalctl I can read: May 29 10:06:45 node36 systemd[1]: Unit vdsmd.service entered failed state. May 29 10:06:45 node36 systemd[1]: vdsmd.service holdoff time over, scheduling restart. May 29 10:06:45 node36 systemd[1]: Stopping Virtual Desktop Server Manager... May 29 10:06:45 node36 systemd[1]: Starting Virtual Desktop Server Manager... May 29 10:06:45 node36 vdsmd_init_common.sh[13697]: vdsm: Running mkdirs May 29 10:06:45 node36 vdsmd_init_common.sh[13697]: vdsm: Running configure_coredump May 29 10:06:45 node36 vdsmd_init_common.sh[13697]: vdsm: Running configure_vdsm_logs May 29 10:06:45 node36 vdsmd_init_common.sh[13697]: vdsm: Running wait_for_network May 29 10:06:45 node36 vdsmd_init_common.sh[13697]: vdsm: Running run_init_hooks May 29 10:06:46 node36 vdsmd_init_common.sh[13697]: vdsm: Running upgraded_version_check May 29 10:06:46 node36 vdsmd_init_common.sh[13697]: vdsm: Running check_is_configured May 29 10:06:46 node36 vdsmd_init_common.sh[13697]: vdsm: Running validate_configuration May 29 10:06:47 node36 vdsmd_init_common.sh[13697]: vdsm: Running prepare_transient_repository May 29 10:06:49 node36 vdsmd_init_common.sh[13697]: vdsm: Running syslog_available May 29 10:06:49 node36 vdsmd_init_common.sh[13697]: vdsm: Running nwfilter May 29 10:06:50 node36 vdsmd_init_common.sh[13697]: vdsm: Running dummybr May 29 10:06:51 node36 vdsmd_init_common.sh[13697]: vdsm: Running load_needed_modules May 29 10:06:51 node36 vdsmd_init_common.sh[13697]: vdsm: Running tune_system May 29 10:06:51 node36 vdsmd_init_common.sh[13697]: vdsm: Running test_space May 29 10:06:51 node36 vdsmd_init_common.sh[13697]: vdsm: Running test_lo May 29 10:06:51 node36 systemd[1]: Started Virtual Desktop Server Manager. May 29 10:06:51 node36 systemd[1]: vdsmd.service: main process exited, code=exited, status=1/FAILURE May 29 10:06:51 node36 vdsmd_init_common.sh[13821]: vdsm: Running run_final_hooks May 29 10:06:52 node36 systemd[1]: Unit vdsmd.service entered failed state. May 29 10:06:52 node36 systemd[1]: vdsmd.service holdoff time over, scheduling restart. May 29 10:06:52 node36 systemd[1]: Stopping Virtual Desktop Server Manager... May 29 10:06:52 node36 systemd[1]: Starting Virtual Desktop Server Manager... repeated a lot of times /var/log/vdsm/vdsm.log is empty. while [root@node36 admin]# /usr/share/vdsm/daemonAdapter -0 /dev/null -1 /dev/null -2 /dev/null /usr/share/vdsm/vdsm; echo $? 1 ciao, Simone

3 7

Unable to import templates
by Christopher Pereira 29 May '15

29 May '15

Hi, A user was unable to import a VM template from a gluster export storage because of various reasons, and since I'm afraid this could hit many users (losing many days waiting for import tasks to...fail) I would like to share the issues and some ideas with you: 1) Slowness: FYI, working with sparse files on GlusterFS mounts will be very slow until https://bugzilla.redhat.com/show_bug.cgi?id=1220173 is implemented. Maybe the same applies also to other network file-systems. 2) Engine Task timeout: The last times the user tried to import this template (using nightly builds), the task was apparently deleted by Engine because of timeout while the qemu-img process continued running (and consuming resources). I'm not sure, but I believe the tasks are deleted by Engine after 4 or 5 days no matter if the qemu-img process is still running (!?). Thus, slow import tasks will never finish. Can someone please confirm? Maybe we can improve something here to support long import tasks. 3) Wrong SPM: If $SRC is on host-1, $DST on host-2 and SPM is host-3, the image will be unnecessarily crossing host-3 and kill the cluster performance. I guess Engine should choose automatically the appropriate SPM host depending on the tasks (host-1 or host-2 in this case). But it seems like oVirt doesn't currently support changing the SPM when there are running tasks, based on the fact that the user gets a warning when trying to do it manually. 4) Convert Optimization: I see oVirt is running: /usr/bin/qemu-img convert -t none -T none -f raw $SRC -O raw $DST In this case, $SRC is in raw format and there are no backing chains. Shouldn't we do a simple 'cp --sparse=always' instead of a 'qemu-img convert' in this case? I guess qemu-img should be doing this optimization for us, but maybe this raw-to-raw conversion use case is just to silly and will not be considered by qemu-img maintainers.

4 4

[TICKET] build failed, gluster test, "Failed tests testSaveDetails(org.ovirt.engine.core.dao.gluster.GlusterGeoRepDaoTest)"
by Greg Sheremeta 28 May '15

28 May '15

""" The patch seems to break the DAO tests, please fix """ """ Results : 20:07:48 20:07:48 Failed tests: 20:07:48 testSaveDetails(org.ovirt.engine.core.dao.gluster.GlusterGeoRepDaoTest): expected:<org.ovirt.engine.core.common.businessentities.gluster.GlusterGeoRepSessionDetails@e51ed1a5> but was:<org.ovirt.engine.core.common.businessentities.gluster.GlusterGeoRepSessionDetails@918a47a5> """ I reran the build for this patch and it worked, but I'm not sure if that's because someone fixed it or it's a flaky test. Can someone from Gluster comment? http://jenkins.ovirt.org/job/ovirt-engine_master_dao-unit-tests_merged/1146… https://gerrit.ovirt.org/#/c/41298/ Greg Sheremeta Red Hat, Inc. Sr. Software Engineer, RHEV Cell: 919-807-1086 gshereme(a)redhat.com

2 2

please clear your browser cache next time you update to origin/master
by Greg Sheremeta 28 May '15

28 May '15

$subject Thanks, Greg Greg Sheremeta Red Hat, Inc. Sr. Software Engineer, RHEV Cell: 919-807-1086 gshereme(a)redhat.com

1 0