April 2015 - Devel - oVirt List Archives

Maintainer rights on vdsm - ovirt-3.5-gluster
by Sahina Bose 17 Nov '15

17 Nov '15

Hi! On the vdsm branch "ovirt-3.5-gluster", could you provide merge rights to Bala (barumuga(a)redhat.com) ? thanks sahina

4 11

[ovirt-users] oVirt 3.6 new feature: Affinity Group Enforcement Service
by Tomer Saban 25 May '15

25 May '15

Greetings users and developers, I'm developing a new feature "Affinity Rules Enforcement Service"; In summary, =========== If an anti-affinity policy is applied to VMs that are currently running on the same hypervisor, the engine will not automatically migrate one of them off once the policy is applied. The Affinity Rules Enforcement Service will periodically check that affinity rules are being enforced and will migrate VMs if necessary in order to comply with those rules. You're welcome to review the feature page: http://www.ovirt.org/Affinity_Group_Enforcement_Service The feature page is responding to RFE https://bugzilla.redhat.com/show_bug.cgi?id=1112332 Your comments appreciated. Thanks, Tomer

2 2

Jenkins and gerrit emails
by David Caro 13 May '15

13 May '15

--CSNFvL6ilyiKL/Hs Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi everyone, While messing with the gerrit flags I have found a way to minimize effectiv= ely the emails from Jenkins reviews (something that annoyed a lot of you) and to still give information on gerrit about what is going on. Now you will not get any emails on starting jobs, and only the owner should= get emails on finished jobs. But all those events are registered on the gerrit comments. Let me know if that does not work for you and why and we'll try to adapt to= get the best solution for everyone. :q :wqa --=20 David Caro Red Hat S.L. Continuous Integration Engineer - EMEA ENG Virtualization R&D Tel.: +420 532 294 605 Email: dcaro(a)redhat.com Web: www.redhat.com RHT Global #: 82-62605 --CSNFvL6ilyiKL/Hs Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJVQndWAAoJEEBxx+HSYmnDntkH/3io/BwY7OoeI4dKzrBPaxMi CG9NMlh+4z/LK3H75jRHNexllCwmdNt1ac53am97d8HXMty4NiII0gxgQI30SAgR CFDY38swPdPwvGJZegF4ipE4XjzG7Sv43WCoPB2p/o6SZ1QYCVAgf01IWAxC8hlo xvs9/K8VgdGcpP4+nMTWvI0WewVw0hJ4Co7VXU4tdhAbGnJhZsh/SuOUfDtYX9tV kY+Va3kUczSozMftoU5wxToTgBzbI/elRMEDU9hu20HtGM2eChKU1Q9p5GU58IIY IW4nZARCC4hVU5b1M68ERGSrbMGDMJrZ1VAhloUSMg9Euob5D7aemWS2QQrf4Qo= =DAxT -----END PGP SIGNATURE----- --CSNFvL6ilyiKL/Hs--

2 2

Gluster locking the DC
by Christopher Pereira 07 May '15

07 May '15

Hi, 1) FYI: https://bugzilla.redhat.com/show_bug.cgi?id=1217576 I will need some help from a Gluster expert to debug this issue, since I don't know Gluster internals. On a replica-3 cluster with best practices, it's very frustrating to see the whole DC going down because of a FS lock. 2) Should we at some point freeze gluster updates and stick to a stable version, or are we following new features required by oVirt? I feel Gluster very unstable yet, but maybe it's just me. I guess that if a "stat" operation (mount, lsof, etc) of a gluster volume is locking, it's the layer below sanlock, right? I don't think that sanlock should be able to lock Gluster, does it? 3) My feature request: Sanlock+Gluster unit-tests written by the sanlock authors to stress and exploit all Gluster weaknesses. PS: The good news is that [1] and other related issues were finally fixed. [1] https://bugzilla.redhat.com/show_bug.cgi?id=1201355 Best regards, Christopher.

2 2

[vdsm] VmDevices rework
by Martin Polednik 04 May '15

04 May '15

Hello everyone, I have started working on line of patches that deal with current state of VM devices in VDSM. There is a wiki page at [1] describing the issues, phases and final goals for this work. Additionally, there is formal naming system for code related to devices. I would love to hear your opinions and comments about this effort! (and please note that this is very long term work) [1] http://www.ovirt.org/Feature/VmDevices_rework mpolednik

2 3

"Please activate the master Storage Domain first"
by Christopher Pereira 04 May '15

04 May '15

This is a multi-part message in MIME format. --------------020201080903010807000608 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit The DC storage master domain is on a (unrecoverable) storage on a remote dead host. Engine is automatically setting another storage as the "Data (Master)". Seconds later, the unrecoverable storage is marked as "Data (Master)" again. There is no way to start the Datacenter. Both storages are gluster. The old (unrecoverable) one worked fine as a master. Any hint? Logs: Thread-32620::DEBUG::2015-04-28 16:34:02,508::task::592::Storage.TaskManager.Task::(_updateState) Task=`bf487090-8d62-4b42-bfde-93574a8e1486`::moving from state init -> state preparing Thread-32620::INFO::2015-04-28 16:34:02,508::logUtils::48::dispatcher::(wrapper) Run and protect: getAllTasksStatuses(spUUID=None, options=None) Thread-32620::ERROR::2015-04-28 16:34:02,508::task::863::Storage.TaskManager.Task::(_setError) Task=`bf487090-8d62-4b42-bfde-93574a8e1486`::Unexpected error Traceback (most recent call last): File "/usr/share/vdsm/storage/task.py", line 870, in _run return fn(*args, **kargs) File "/usr/share/vdsm/logUtils.py", line 49, in wrapper res = f(*args, **kwargs) File "/usr/share/vdsm/storage/hsm.py", line 2202, in getAllTasksStatuses raise se.SpmStatusError() SpmStatusError: Not SPM: () Thread-32620::DEBUG::2015-04-28 16:34:02,508::task::882::Storage.TaskManager.Task::(_run) Task=`bf487090-8d62-4b42-bfde-93574a8e1486`::Task._run: bf487090-8d62-4b42-bfd e-93574a8e1486 () {} failed - stopping task Thread-32620::DEBUG::2015-04-28 16:34:02,508::task::1214::Storage.TaskManager.Task::(stop) Task=`bf487090-8d62-4b42-bfde-93574a8e1486`::stopping in state preparing (for ce False) Thread-32620::DEBUG::2015-04-28 16:34:02,508::task::990::Storage.TaskManager.Task::(_decref) Task=`bf487090-8d62-4b42-bfde-93574a8e1486`::ref 1 aborting True Thread-32620::INFO::2015-04-28 16:34:02,508::task::1168::Storage.TaskManager.Task::(prepare) Task=`bf487090-8d62-4b42-bfde-93574a8e1486`::aborting: Task is aborted: 'No t SPM' - code 654 Thread-32620::DEBUG::2015-04-28 16:34:02,508::task::1173::Storage.TaskManager.Task::(prepare) Task=`bf487090-8d62-4b42-bfde-93574a8e1486`::Prepare: aborted: Not SPM Thread-32620::DEBUG::2015-04-28 16:34:02,508::task::990::Storage.TaskManager.Task::(_decref) Task=`bf487090-8d62-4b42-bfde-93574a8e1486`::ref 0 aborting True Thread-32620::DEBUG::2015-04-28 16:34:02,508::task::925::Storage.TaskManager.Task::(_doAbort) Task=`bf487090-8d62-4b42-bfde-93574a8e1486`::Task._doAbort: force False Thread-32620::DEBUG::2015-04-28 16:34:02,508::resourceManager::977::Storage.ResourceManager.Owner::(cancelAll) Owner.cancelAll requests {} Thread-32620::DEBUG::2015-04-28 16:34:02,508::task::592::Storage.TaskManager.Task::(_updateState) Task=`bf487090-8d62-4b42-bfde-93574a8e1486`::moving from state preparing -> state aborting Thread-32620::DEBUG::2015-04-28 16:34:02,508::task::547::Storage.TaskManager.Task::(__state_aborting) Task=`bf487090-8d62-4b42-bfde-93574a8e1486`::_aborting: recover policy none Thread-32620::DEBUG::2015-04-28 16:34:02,508::task::592::Storage.TaskManager.Task::(_updateState) Task=`bf487090-8d62-4b42-bfde-93574a8e1486`::moving from state aborting -> state failed Thread-32620::DEBUG::2015-04-28 16:34:02,508::resourceManager::940::Storage.ResourceManager.Owner::(releaseAll) Owner.releaseAll requests {} resources {} Thread-32620::DEBUG::2015-04-28 16:34:02,508::resourceManager::977::Storage.ResourceManager.Owner::(cancelAll) Owner.cancelAll requests {} Thread-32620::ERROR::2015-04-28 16:34:02,509::dispatcher::76::Storage.Dispatcher::(wrapper) {'status': {'message': 'Not SPM: ()', 'code': 654}} Thread-32620::DEBUG::2015-04-28 16:34:02,509::stompReactor::158::yajsonrpc.StompServer::(send) Sending response --------------020201080903010807000608 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit <html> <head> <meta http-equiv="content-type" content="text/html; charset=utf-8"> </head> <body bgcolor="#FFFFFF" text="#000000"> The DC storage master domain is on a (unrecoverable) storage on a remote dead host. Engine is automatically setting another storage as the "Data (Master)". Seconds later, the unrecoverable storage is marked as "Data (Master)" again. There is no way to start the Datacenter. Both storages are gluster. The old (unrecoverable) one worked fine as a master. Any hint? Logs: <blockquote>Thread-32620::DEBUG::2015-04-28 16:34:02,508::task::592::Storage.TaskManager.Task::(_updateState) Task=`bf487090-8d62-4b42-bfde-93574a8e1486`::moving from state init -> state preparing Thread-32620::INFO::2015-04-28 16:34:02,508::logUtils::48::dispatcher::(wrapper) Run and protect: getAllTasksStatuses(spUUID=None, options=None) Thread-32620::ERROR::2015-04-28 16:34:02,508::task::863::Storage.TaskManager.Task::(_setError) Task=`bf487090-8d62-4b42-bfde-93574a8e1486`::Unexpected error Traceback (most recent call last): File "/usr/share/vdsm/storage/task.py", line 870, in _run return fn(*args, **kargs) File "/usr/share/vdsm/logUtils.py", line 49, in wrapper res = f(*args, **kwargs) File "/usr/share/vdsm/storage/hsm.py", line 2202, in getAllTasksStatuses raise se.SpmStatusError() SpmStatusError: Not SPM: () Thread-32620::DEBUG::2015-04-28 16:34:02,508::task::882::Storage.TaskManager.Task::(_run) Task=`bf487090-8d62-4b42-bfde-93574a8e1486`::Task._run: bf487090-8d62-4b42-bfd e-93574a8e1486 () {} failed - stopping task Thread-32620::DEBUG::2015-04-28 16:34:02,508::task::1214::Storage.TaskManager.Task::(stop) Task=`bf487090-8d62-4b42-bfde-93574a8e1486`::stopping in state preparing (for ce False) Thread-32620::DEBUG::2015-04-28 16:34:02,508::task::990::Storage.TaskManager.Task::(_decref) Task=`bf487090-8d62-4b42-bfde-93574a8e1486`::ref 1 aborting True Thread-32620::INFO::2015-04-28 16:34:02,508::task::1168::Storage.TaskManager.Task::(prepare) Task=`bf487090-8d62-4b42-bfde-93574a8e1486`::aborting: Task is aborted: 'No t SPM' - code 654 Thread-32620::DEBUG::2015-04-28 16:34:02,508::task::1173::Storage.TaskManager.Task::(prepare) Task=`bf487090-8d62-4b42-bfde-93574a8e1486`::Prepare: aborted: Not SPM Thread-32620::DEBUG::2015-04-28 16:34:02,508::task::990::Storage.TaskManager.Task::(_decref) Task=`bf487090-8d62-4b42-bfde-93574a8e1486`::ref 0 aborting True Thread-32620::DEBUG::2015-04-28 16:34:02,508::task::925::Storage.TaskManager.Task::(_doAbort) Task=`bf487090-8d62-4b42-bfde-93574a8e1486`::Task._doAbort: force False Thread-32620::DEBUG::2015-04-28 16:34:02,508::resourceManager::977::Storage.ResourceManager.Owner::(cancelAll) Owner.cancelAll requests {} Thread-32620::DEBUG::2015-04-28 16:34:02,508::task::592::Storage.TaskManager.Task::(_updateState) Task=`bf487090-8d62-4b42-bfde-93574a8e1486`::moving from state preparing -> state aborting Thread-32620::DEBUG::2015-04-28 16:34:02,508::task::547::Storage.TaskManager.Task::(__state_aborting) Task=`bf487090-8d62-4b42-bfde-93574a8e1486`::_aborting: recover policy none Thread-32620::DEBUG::2015-04-28 16:34:02,508::task::592::Storage.TaskManager.Task::(_updateState) Task=`bf487090-8d62-4b42-bfde-93574a8e1486`::moving from state aborting -> state failed Thread-32620::DEBUG::2015-04-28 16:34:02,508::resourceManager::940::Storage.ResourceManager.Owner::(releaseAll) Owner.releaseAll requests {} resources {} Thread-32620::DEBUG::2015-04-28 16:34:02,508::resourceManager::977::Storage.ResourceManager.Owner::(cancelAll) Owner.cancelAll requests {} Thread-32620::ERROR::2015-04-28 16:34:02,509::dispatcher::76::Storage.Dispatcher::(wrapper) {'status': {'message': 'Not SPM: ()', 'code': 654}} Thread-32620::DEBUG::2015-04-28 16:34:02,509::stompReactor::158::yajsonrpc.StompServer::(send) Sending response </blockquote> </body> </html> --------------020201080903010807000608--

4 9

Jenkins upgrade today
by David Caro 30 Apr '15

30 Apr '15

--p2kqVDKq5asng8Dg Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi! Today I will be upgrading jenkins to the latest stable version, the upgrade will start at 17:00 CEST (18:00 IST) and will take around 30min. I will set jenkins to not accept new jobs 30 minutes before that to let any pending jobs finish, but any job that does not finish in that time, will be aborted, if that happens feel free to retrigger your patch at [1]. Cheers! [1] http://jenkins.ovirt.org/gerrit_manual_trigger/ --=20 David Caro Red Hat S.L. Continuous Integration Engineer - EMEA ENG Virtualization R&D Tel.: +420 532 294 605 Email: dcaro(a)redhat.com Web: www.redhat.com RHT Global #: 82-62605 --p2kqVDKq5asng8Dg Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJVQKJOAAoJEEBxx+HSYmnDPYYIAJxbfzwUzAYAbQ64t6iOfy6q Cnb7e02hTu6FoBhlW5ERgmNEtJF+e9xoBG4doE73Zc/oDAhACZ29Wdo1gEGrA3B4 ASwuJ7WR4ZW8JlRGSSITXtado9iCe5kDR7UUgz1s37K334pKDsfuj62l/zeR7pFL dUJSkbQs0Iyc7ZafoD3KPi55+V1bt94lC8I0CreM3RJhP4Y1+I7xePJE2nAJzcp1 KKDQY71al3IUHXd6UiLlWRsy4h8c/8J4u47oRjh8qNXYXQlPSbg2VgI1g20Xgfyc PkUU2hk0FkFsEBzHX6+uUQGowydmmmexEQ/xVus1zxxJDK6U/NSyGrZFLfNtNqo= =C9MQ -----END PGP SIGNATURE----- --p2kqVDKq5asng8Dg--

2 5

Re: [ovirt-devel] [ovirt-users] oVirt HA.
by Sven Kieske 30 Apr '15

30 Apr '15

On 29/04/15 21:53, Dan Yasny wrote: > There is always room for improvement, but think about it: ever since SolidICE, there has been a demand to minimize the amount of hardware used in a minimalistic setup, thus the hosted engine project. And now that we have it, all of a sudden, we need to provide a way to make multiple engines work in active/passive mode? If that capability is provided, I'm sure a new demand will arise, asking for active/active engines, infinitely scalable, and so on. of course you wan't active/active clusters for an enterprise product, rather sooner than later > > The question really is, where the line is drawn. The engine downtime can be a few minutes, it's not that critical in setups of hundreds of hosts. oVirt's raison d'etre is to make VMs run, everything else is just plumbing around that. I disagree: ovirt is a provider of critical infrastructure (vms and their management) for modern it business. imagine a large organisation just using ovirt for their virtualization, with lots of different departments which at will can spawn their own vms, maybe even from different countrys with different time zones (just like red hat ;) ). of course, if just the engine service is down for some reason and you can just restart it with an outage of some seconds, or maybe a minute - fine. but everything above a minute could become critical for large orgs relying on the ability to spawn vms at any given time. or imagine critical HA vms running on ovirt: you can't migrate them, when the engine is not running. you might not even want a downtime of a single second for them, that's why you implemented things like live migration in the first place. the bottom line is: if you manage critical infrastructure, the tools to manage this infrastructure have to be as reliable as the infrastructure itself. -- Mit freundlichen Grüßen / Regards Sven Kieske Systemadministrator Mittwald CM Service GmbH & Co. KG Königsberger Straße 6 32339 Espelkamp T: +49-5772-293-100 F: +49-5772-293-333 https://www.mittwald.de Geschäftsführer: Robert Meyer St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen

3 3

Validation issue with IntegerEntityModelTextBoxEditor
by Ramesh 30 Apr '15

30 Apr '15

Hi, We have a validation issue with IntegerEntityModelTextBoxEditor. It converts non numeric values as null to the model. As a result IntegerValidation.validate() will be success always even in case of non integer value. Any suggestion to fix this issue?. Regards, Ramesh

5 6

"Could not find working O_DIRECT alignment. Try cache.direct=off"
by Christopher Pereira 30 Apr '15

30 Apr '15

virDomainCreateXML() is returning "Could not find working O_DIRECT alignment. Try cache.direct=off". This image was working some days ago with a previous version. Did the image get corrupted or could this be related to a recent change in oVirt? --- Logs --- Thread-694::INFO::2015-04-30 03:32:49,512::vm::1765::vm.Vm::(_run) vmId=`bc99ded7-edc9-4bc5-bca5-a61a286757d2`::<?xml version="1.0" encoding="utf-8"?> <domain type="kvm"> <name>Test 31</name> <uuid>bc99ded7-edc9-4bc5-bca5-a61a286757d2</uuid> <memory>12582912</memory> <currentMemory>12582912</currentMemory> <vcpu current="4">16</vcpu> <devices> <channel type="unix"> <target name="com.redhat.rhevm.vdsm" type="virtio"/> <source mode="bind" path="/var/lib/libvirt/qemu/channels/bc99ded7-edc9-4bc5-bca5-a61a286757d2.com.redhat.rhevm.vdsm"/> </channel> <channel type="unix"> <target name="org.qemu.guest_agent.0" type="virtio"/> <source mode="bind" path="/var/lib/libvirt/qemu/channels/bc99ded7-edc9-4bc5-bca5-a61a286757d2.org.qemu.guest_agent.0"/> </channel> <input bus="ps2" type="mouse"/> <sound model="ich6"/> <memballoon model="virtio"> <address bus="0x00" domain="0x0000" function="0x0" slot="0x06" type="pci"/> </memballoon> <controller index="0" ports="16" type="virtio-serial"> <address bus="0x00" domain="0x0000" function="0x0" slot="0x04" type="pci"/> </controller> <video> <address bus="0x00" domain="0x0000" function="0x0" slot="0x02" type="pci"/> <model heads="1" type="cirrus" vram="32768"/> </video> <graphics autoport="yes" listen="0" passwd="*****" passwdValidTo="1970-01-01T00:00:01" port="-1" type="vnc"/> <interface type="bridge"> <address bus="0x00" domain="0x0000" function="0x0" slot="0x03" type="pci"/> <mac address="00:1a:4a:16:01:51"/> <model type="virtio"/> <source bridge=";vdsmdummy;"/> <filterref filter="vdsm-no-mac-spoofing"/> <link state="up"/> </interface> <disk device="cdrom" snapshot="no" type="file"> <address bus="1" controller="0" target="0" type="drive" unit="0"/> <source file="" startupPolicy="optional"/> <target bus="ide" dev="hdc"/> <readonly/> <serial/> </disk> <disk device="disk" snapshot="no" type="file"> <address bus="0x00" domain="0x0000" function="0x0" slot="0x05" type="pci"/> <source file="/rhev/data-center/00000001-0001-0001-0001-00000000007e/3233144b-7be1-445f-9ea6-6aebbacbb93f/images/5a7db80d-f037-4dcb-8059-6706a2b62b19/db63659c-c9a9-4f4f-887f-3443a008a27e"/> <target bus="virtio" dev="vda"/> <serial>5a7db80d-f037-4dcb-8059-6706a2b62b19</serial> <boot order="1"/> <driver cache="none" error_policy="stop" io="threads" name="qemu" type="raw"/> </disk> </devices> <os> <type arch="x86_64" machine="rhel6.5.0">hvm</type> <smbios mode="sysinfo"/> </os> <sysinfo type="smbios"> <system> <entry name="manufacturer">oVirt</entry> <entry name="product">oVirt Node</entry> <entry name="version">7-1.1503.el7.centos.2.8</entry> <entry name="serial">4C4C4544-0042-4B10-8058-B2C04F5A5A31</entry> <entry name="uuid">bc99ded7-edc9-4bc5-bca5-a61a286757d2</entry> </system> </sysinfo> <clock adjustment="3600" offset="variable"> <timer name="rtc" tickpolicy="catchup"/> <timer name="pit" tickpolicy="delay"/> <timer name="hpet" present="no"/> </clock> <features> <acpi/> </features> <cpu match="exact"> <model>SandyBridge</model> <topology cores="1" sockets="16" threads="1"/> </cpu> </domain> Thread-694::ERROR::2015-04-30 03:32:49,978::vm::741::vm.Vm::(_startUnderlyingVm) vmId=`bc99ded7-edc9-4bc5-bca5-a61a286757d2`::The vm start process failed Traceback (most recent call last): File "/usr/share/vdsm/virt/vm.py", line 689, in _startUnderlyingVm self._run() File "/usr/share/vdsm/virt/vm.py", line 1800, in _run self._connection.createXML(domxml, flags), File "/usr/lib/python2.7/site-packages/vdsm/libvirtconnection.py", line 126, in wrapper ret = f(*args, **kwargs) File "/usr/lib64/python2.7/site-packages/libvirt.py", line 3427, in createXML if ret is None:raise libvirtError('virDomainCreateXML() failed', conn=self) libvirtError: internal error: process exited while connecting to monitor: 2015-04-30T06:32:49.783554Z qemu-kvm: -drive file=/rhev/data-center/00000001-0001-0001-0001-00000000007e/3233144b-7be1-445f-9ea6-6aebbacbb93f/images/5a7db80d-f037-4dcb-8059-6706a2b62b19/db63659c-c9a9-4f4f-887f-3443a008a27e,if=none,id=drive-virtio-disk0,format=raw,serial=5a7db80d-f037-4dcb-8059-6706a2b62b19,cache=none,werror=stop,rerror=stop,aio=threads: could not open disk image /rhev/data-center/00000001-0001-0001-0001-00000000007e/3233144b-7be1-445f-9ea6-6aebbacbb93f/images/5a7db80d-f037-4dcb-8059-6706a2b62b19/db63659c-c9a9-4f4f-887f-3443a008a27e: Could not find working O_DIRECT alignment. Try cache.direct=off. --- Related BZ : https://bugzilla.redhat.com/show_bug.cgi?id=1184363

1 0

Could sanlock manage leases on a separate replica 3 gluster volume?
by Christopher Pereira 30 Apr '15

30 Apr '15

Could sanlock manage leases on a special separate replica 3 gluster volume? Would this avoid using replica 3 for the rest of the data?

2 1

Re: [ovirt-devel] [ovirt-users] oVirt HA.
by Sven Kieske 30 Apr '15

30 Apr '15

On 28/04/15 16:20, Dan Yasny wrote: > HA does not mean multiple running instances of the same service. It means > if the service is gone, it will automatically be restored on a working > server. That is a pretty narrow definition of HA, which is not shared by most parts of the community (and the world), leading to much confusion of users on this very ML. HA in general means your service downtime gets minimized, today mostly realized through load balancing and clustering software services. just restarting a service (in this case ovirt-engine vm) on a different host is not what todays user expect under the term "HA" imho. in theory it should be possible as a design goal to make multiple ovirt-engine share one remote data base (remote database support is already there). I think this would be a huge feature for ovirt, but also requires quite some design and coding to be done. thus adding the devel list. -- Mit freundlichen Grüßen / Regards Sven Kieske Systemadministrator Mittwald CM Service GmbH & Co. KG Königsberger Straße 6 32339 Espelkamp T: +49-5772-293-100 F: +49-5772-293-333 https://www.mittwald.de Geschäftsführer: Robert Meyer St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen

3 2

Annoucing the 1st oVirt infra hackathon - join the fun!
by Eyal Edri 29 Apr '15

29 Apr '15

Hi to all dev & infra members of the oVirt project. As you know (or not :) , the infra team handles many resources and systems that supports the oVirt project. Some are visible like gerrit or jenkins, and some are in the background like puppet, foreman, data-centers maintenance, monitoring, jenkins job builder and many more.. As an effort to reduce open issues and tickets [1], we decided to do the 1st infra hackathon so we can join forces for a single concentrated day and try to resolve as many tickets as possible. We've created a Google sheet for it [2], so anyone from the community can volunteer and help out, even if he's not an infra member! This is also a great opportunity for new community members that wish to join the team or just get dirty with some "devops" tasks... Each task has a 'verifier' column which includes all infra members or people from the ovirt project who can assist with code review, help, verification. [3] If you see a task in [1] and feel like you'd want to take it on, feel free to add it to [2] if it's not there. An exact date will be published soon, but might be as early as next week, so make sure to write your name on a task if you're interested! note: infra team availability during the hackathon might be limited, and only urgent issues will be handled. happy hacking, oVirt Infra Team [1] https://fedorahosted.org/ovirt/report/1 [2] http://goo.gl/QtWVJ3 [3] if you think you can help as a reviewer, please add your name in sheet2.

1 0

[ACTION NEEDED][QE] oVirt 3.6.0 status
by Sandro Bonazzola 29 Apr '15

29 Apr '15

Hi, here's an update on 3.6 status on integration / rel-eng side The tracker bug for 3.6.0 [1] currently shows no blockers. Repository closure is currently broken on Fedora 20 and CentOS 6 due to a missing required dependency on recent libvirt and vdsm rpm dropping el6 support. VDSM builds for EL6 are no more available on master snapshot. ACTION: jenkins job owners: please review jenkins jobs relying on VDSM to be available on EL6. There are 535 bugs [2] targeted to 3.6.0. NEW ASSIGNED POST Total abrt+infra 2 0 0 1 docs 10 0 0 10 external 1 0 0 1 gluster 30 36 20 86 i18n 2 0 0 2 infra 44 3 8 55 integration 35 2 9 46 network 46 1 8 55 node 26 2 3 31 ovirt-node-plugin-vdsm 1 0 0 1 sla 45 3 2 50 spice 1 0 0 1 storage 73 7 5 85 ux 27 0 3 30 virt 63 6 11 80 Total 406 60 69 535 Features submission is now CLOSED as per current release schedule. ACTION: review features tracked in the google doc[3] On Integration side: * Progress on backup / restore RFEs * Fixing regressions in Hosted Engine deployment on additional hosts On Release engineering side: * Working with infra team fixing jenkins issues ACTION: community members are welcome to join QE effort[4] by testing nightly master snapshot[5] on test systems [1] https://bugzilla.redhat.com/1155425 [2] https://bugzilla.redhat.com/buglist.cgi?quicksearch=target_release%3A3.6.0%… [3] http://goo.gl/9X3G49 [4] http://www.ovirt.org/OVirt_Quality_Assurance [5] http://www.ovirt.org/Install_nightly_snapshot -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com

1 0

[QE][ACTION REQUIRED] oVirt 3.5.3 status
by Sandro Bonazzola 29 Apr '15

29 Apr '15

Hi, We have no blockers for 3.5.3[1] and no blocking dependencies. We still have 11 bugs in MODIFIED and 2 on QA[2]: MODIFIED ON_QA Total gluster 1 0 1 infra 3 2 5 integration 1 0 1 sla 1 0 1 storage 5 0 5 Total 11 2 13 ACTION: Testers: you're welcome to verify bugs currently ON_QA. ACTION: Testers: please add yourself to the test page [5] We have 7 bugs currently targeted to 3.5.3[3]: Whiteboard NEW POST Total external 1 0 1 infra 0 1 1 network 0 1 1 node 0 2 2 ppc 0 1 1 storage 0 1 1 Total 1 6 7 ACTION: Maintainers / Assignee: to review the bugs targeted to 3.5.3 and mark them as blockers or postpone to 3.5.4. ACTION: Maintainers: to fill release notes for 3.5.3, the page has been created and updated here [4] A release management entry has been added for tracking the schedule of 3.5.3[6] and tentative schedule has been proposed as follow: 2015-05-27 Release candidate 2015-06-09 General availability [1] https://bugzilla.redhat.com/1198142 [2] http://goo.gl/WqkJnn [3] https://bugzilla.redhat.com/buglist.cgi?quicksearch=product%3Aovirt%20targe… [4] http://www.ovirt.org/OVirt_3.5.3_Release_Notes [5] http://www.ovirt.org/Testing/oVirt_3.5.3_Testing [6] http://www.ovirt.org/OVirt_3.5.z_Release_Management#oVirt_3.5.3 -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com

1 0

VDSM - sampling.py - remove() called without previous add()
by Christopher Pereira 29 Apr '15

29 Apr '15

This is a multi-part message in MIME format. --------------060105040505080104010504 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Hi, In sampling.py, remove() is being called without calling add() before, which throws: JsonRpc (StompReactor)::DEBUG::2015-04-28 17:35:55,061::stompReactor::94::Broker.StompAdapter::(handle_frame) Handling message <StompFrame command=u'SEND'> Thread-37401::DEBUG::2015-04-28 17:35:55,062::__init__::445::jsonrpc.JsonRpcServer::(_serveRequest) Calling 'VM.destroy' in bridge with {u'vmID': u'6ec9c0a0-2879-4bfe-9a79-92471881ebfe'} JsonRpcServer::DEBUG::2015-04-28 17:35:55,062::__init__::482::jsonrpc.JsonRpcServer::(serve_requests) Waiting for request Thread-37401::INFO::2015-04-28 17:35:55,062::API::334::vds::(destroy) vmContainerLock acquired by vm 6ec9c0a0-2879-4bfe-9a79-92471881ebfe Thread-37401::DEBUG::2015-04-28 17:35:55,062::vm::3513::vm.Vm::(destroy) vmId=`6ec9c0a0-2879-4bfe-9a79-92471881ebfe`::destroy Called Thread-37401::INFO::2015-04-28 17:35:55,062::vm::3444::vm.Vm::(releaseVm) vmId=`6ec9c0a0-2879-4bfe-9a79-92471881ebfe`::Release VM resources Thread-37401::WARNING::2015-04-28 17:35:55,062::vm::375::vm.Vm::(_set_lastStatus) vmId=`6ec9c0a0-2879-4bfe-9a79-92471881ebfe`::trying to set state to Powering down when already Down Thread-37401::ERROR::2015-04-28 17:35:55,063::__init__::469::jsonrpc.JsonRpcServer::(_serveRequest) Internal server error Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/yajsonrpc/__init__.py", line 464, in _serveRequest res = method(**params) File "/usr/share/vdsm/rpc/Bridge.py", line 273, in _dynamicMethod result = fn(*methodArgs) File "/usr/share/vdsm/API.py", line 339, in destroy res = v.destroy() File "/usr/share/vdsm/virt/vm.py", line 3515, in destroy result = self.doDestroy() File "/usr/share/vdsm/virt/vm.py", line 3533, in doDestroy return self.releaseVm() File "/usr/share/vdsm/virt/vm.py", line 3448, in releaseVm sampling.stats_cache.remove(self.id) File "/usr/share/vdsm/virt/sampling.py", line 428, in remove if vmid in self._vm_last_timestamp.keys(): KeyError: u'6ec9c0a0-2879-4bfe-9a79-92471881ebfe' Thread-37401::DEBUG::2015-04-28 17:35:55,063::stompReactor::158::yajsonrpc.StompServer::(send) Sending response In file '/usr/share/vdsm/virt/sampling.py': def add(self, vmid): """ Warm up the cache for the given VM. This is to avoid races during the first sampling and the first reporting, which may result in a VM wrongly reported as unresponsive. """ with self._lock: self._vm_last_timestamp[vmid] = self._clock() def remove(self, vmid): """ Remove any data from the cache related to the given VM. """ with self._lock: * if vmid in self._vm_last_timestamp.keys():**<----------------- I patched here as a workarround ** del self._vm_last_timestamp[vmid]* --------------060105040505080104010504 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit <html> <head> <meta http-equiv="content-type" content="text/html; charset=utf-8"> </head> <body bgcolor="#FFFFFF" text="#000000"> Hi, In sampling.py, remove() is being called without calling add() before, which throws: <blockquote>JsonRpc (StompReactor)::DEBUG::2015-04-28 17:35:55,061::stompReactor::94::Broker.StompAdapter::(handle_frame) Handling message <StompFrame command=u'SEND'> Thread-37401::DEBUG::2015-04-28 17:35:55,062::__init__::445::jsonrpc.JsonRpcServer::(_serveRequest) Calling 'VM.destroy' in bridge with {u'vmID': u'6ec9c0a0-2879-4bfe-9a79-92471881ebfe'} JsonRpcServer::DEBUG::2015-04-28 17:35:55,062::__init__::482::jsonrpc.JsonRpcServer::(serve_requests) Waiting for request Thread-37401::INFO::2015-04-28 17:35:55,062::API::334::vds::(destroy) vmContainerLock acquired by vm 6ec9c0a0-2879-4bfe-9a79-92471881ebfe Thread-37401::DEBUG::2015-04-28 17:35:55,062::vm::3513::vm.Vm::(destroy) vmId=`6ec9c0a0-2879-4bfe-9a79-92471881ebfe`::destroy Called Thread-37401::INFO::2015-04-28 17:35:55,062::vm::3444::vm.Vm::(releaseVm) vmId=`6ec9c0a0-2879-4bfe-9a79-92471881ebfe`::Release VM resources Thread-37401::WARNING::2015-04-28 17:35:55,062::vm::375::vm.Vm::(_set_lastStatus) vmId=`6ec9c0a0-2879-4bfe-9a79-92471881ebfe`::trying to set state to Powering down when already Down Thread-37401::ERROR::2015-04-28 17:35:55,063::__init__::469::jsonrpc.JsonRpcServer::(_serveRequest) Internal server error Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/yajsonrpc/__init__.py", line 464, in _serveRequest res = method(**params) File "/usr/share/vdsm/rpc/Bridge.py", line 273, in _dynamicMethod result = fn(*methodArgs) File "/usr/share/vdsm/API.py", line 339, in destroy res = v.destroy() File "/usr/share/vdsm/virt/vm.py", line 3515, in destroy result = self.doDestroy() File "/usr/share/vdsm/virt/vm.py", line 3533, in doDestroy return self.releaseVm() File "/usr/share/vdsm/virt/vm.py", line 3448, in releaseVm sampling.stats_cache.remove(self.id) File "/usr/share/vdsm/virt/sampling.py", line 428, in remove if vmid in self._vm_last_timestamp.keys(): KeyError: u'6ec9c0a0-2879-4bfe-9a79-92471881ebfe' Thread-37401::DEBUG::2015-04-28 17:35:55,063::stompReactor::158::yajsonrpc.StompServer::(send) Sending response </blockquote> In file '/usr/share/vdsm/virt/sampling.py': def add(self, vmid): """ Warm up the cache for the given VM. This is to avoid races during the first sampling and the first reporting, which may result in a VM wrongly reported as unresponsive. """ with self._lock: self._vm_last_timestamp[vmid] = self._clock() def remove(self, vmid): """ Remove any data from the cache related to the given VM. """ with self._lock: if vmid in self._vm_last_timestamp.keys(): <----------------- I patched here as a workarround del self._vm_last_timestamp[vmid] </body> </html> --------------060105040505080104010504--

3 4

Orphaning ovirt-node in Fedora
by Fabian Deutsch 29 Apr '15

29 Apr '15

Hey, historically we maintained the ovirt-node package in Fedora. But due to the nature of ovirt-node the package is not directly usable in Fedora. To prevent an accidental use of the package and because there is no other value in maintaining it there, I plan to orphan this package in Fedora. Is anybody objecting to this? If not, then I'll orphan it in one week. We can always bring it back if it becomes necessary. but I do not see a reason why this should happen. Greetings fabian

2 2

libvirtError: unsupported configuration: timer hypervclock doesn't support setting of timer tickpolicy
by Christopher Pereira 29 Apr '15

29 Apr '15

This is a multi-part message in MIME format. --------------050805010200030806000304 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit It seems like we need to upgrade libvirt dependencies in master repo: Thread-78::ERROR::2015-04-29 06:23:04,584::vm::741::vm.Vm::(_startUnderlyingVm) vmId=`6ec9c0a0-2879-4bfe- 9a79-92471881ebfe`::The vm start process failed Traceback (most recent call last): File "/usr/share/vdsm/virt/vm.py", line 689, in _startUnderlyingVm self._run() File "/usr/share/vdsm/virt/vm.py", line 1800, in _run self._connection.createXML(domxml, flags), File "/usr/lib/python2.7/site-packages/vdsm/libvirtconnection.py", line 126, in wrapper ret = f(*args, **kwargs) File "/usr/lib64/python2.7/site-packages/libvirt.py", line 3427, in createXML if ret is None:raise libvirtError('virDomainCreateXML() failed', conn=self) libvirtError: unsupported configuration: timer hypervclock doesn't support setting of timer tickpolicy To reproduce, start a "Windows 2008 R2 x64" VM (no problem with Windows 2012). Glad to see that hv_ optimization flags are being supported, since they boost Windows VM performance using inhouse MS Hypervisor optimizations. --------------050805010200030806000304 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit <html> <head> <meta http-equiv="content-type" content="text/html; charset=utf-8"> </head> <body bgcolor="#FFFFFF" text="#000000"> It seems like we need to upgrade libvirt dependencies in master repo: <blockquote>Thread-78::ERROR::2015-04-29 06:23:04,584::vm::741::vm.Vm::(_startUnderlyingVm) vmId=`6ec9c0a0-2879-4bfe- 9a79-92471881ebfe`::The vm start process failed Traceback (most recent call last): File "/usr/share/vdsm/virt/vm.py", line 689, in _startUnderlyingVm self._run() File "/usr/share/vdsm/virt/vm.py", line 1800, in _run self._connection.createXML(domxml, flags), File "/usr/lib/python2.7/site-packages/vdsm/libvirtconnection.py", line 126, in wrapper ret = f(*args, **kwargs) File "/usr/lib64/python2.7/site-packages/libvirt.py", line 3427, in createXML if ret is None:raise libvirtError('virDomainCreateXML() failed', conn=self) libvirtError: unsupported configuration: timer hypervclock doesn't support setting of timer tickpolicy </blockquote> To reproduce, start a "Windows 2008 R2 x64" VM (no problem with Windows 2012). Glad to see that hv_ optimization flags are being supported, since they boost Windows VM performance using inhouse MS Hypervisor optimizations. </body> </html> --------------050805010200030806000304--

2 5

Engine Broken - The column name gluster_tuned_profile was not found in this ResultSet
by Christopher Pereira 28 Apr '15

28 Apr '15

Hi, something broke Engine's Database in master: 2015-04-28 05:53:15,959 ERROR [org.ovirt.engine.core.bll.InitBackendServicesOnStartupBean] (MSC service thread 1-4) [] Failed to initialize backend: org.jboss.weld.exceptions.WeldException: WELD-000049 Unable to invoke [method] @PostConstruct private org.ovirt.engine.core.vdsbroker.ResourceManager.init() on org.ovirt.engine.core.vdsbroker.ResourceManager@38e3648c at org.jboss.weld.bean.AbstractClassBean.defaultPostConstruct(AbstractClassBean.java:518) [weld-core-1.1.5.AS71.Final.jar:2012-02-10 15:31] at org.jboss.weld.bean.ManagedBean$ManagedBeanInjectionTarget.postConstruct(ManagedBean.java:174) [weld-core-1.1.5.AS71.Final.jar:2012-02-10 15:31] at org.jboss.weld.bean.ManagedBean.create(ManagedBean.java:291) [weld-core-1.1.5.AS71.Final.jar:2012-02-10 15:31] at org.jboss.weld.context.AbstractContext.get(AbstractContext.java:107) [weld-core-1.1.5.AS71.Final.jar:2012-02-10 15:31] at org.jboss.weld.manager.BeanManagerImpl.getReference(BeanManagerImpl.java:616) [weld-core-1.1.5.AS71.Final.jar:2012-02-10 15:31] at org.jboss.weld.manager.BeanManagerImpl.getReference(BeanManagerImpl.java:643) [weld-core-1.1.5.AS71.Final.jar:2012-02-10 15:31] at org.ovirt.engine.core.di.Injector.instanceOf(Injector.java:73) [vdsbroker.jar:] at org.ovirt.engine.core.di.Injector.get(Injector.java:58) [vdsbroker.jar:] at org.ovirt.engine.core.bll.InitBackendServicesOnStartupBean.create(InitBackendServicesOnStartupBean.java:75) [bll.jar:] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_79] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_79] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_79] at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_79] at org.jboss.as.ee.component.ManagedReferenceLifecycleMethodInterceptorFactory$ManagedReferenceLifecycleMethodInterceptor.processInvocation(ManagedReferenceLifecycleMethodInterceptorFactory.java:130) [jboss-as-ee-7.1.1.Final.jar:7.1.1.Final] at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final] at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final] at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final] at org.jboss.as.weld.injection.WeldInjectionInterceptor.processInvocation(WeldInjectionInterceptor.java:73) [jboss-as-weld-7.1.1.Final.jar:7.1.1.Final] at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final] at org.jboss.as.ee.component.ManagedReferenceInterceptorFactory$ManagedReferenceInterceptor.processInvocation(ManagedReferenceInterceptorFactory.java:95) [jboss-as-ee-7.1.1.Final.jar:7.1.1.Final] at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final] at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final] at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final] at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50) [jboss-as-ee-7.1.1.Final.jar:7.1.1.Final] at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final] at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:228) [jboss-as-ejb3-7.1.1.Final.jar:7.1.1.Final] at org.jboss.as.ejb3.tx.CMTTxInterceptor.requiresNew(CMTTxInterceptor.java:333) [jboss-as-ejb3-7.1.1.Final.jar:7.1.1.Final] at org.jboss.as.ejb3.tx.SingletonLifecycleCMTTxInterceptor.processInvocation(SingletonLifecycleCMTTxInterceptor.java:56) [jboss-as-ejb3-7.1.1.Final.jar:7.1.1.Final] at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final] at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41) [jboss-as-ejb3-7.1.1.Final.jar:7.1.1.Final] at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final] at org.jboss.as.ee.component.TCCLInterceptor.processInvocation(TCCLInterceptor.java:45) [jboss-as-ee-7.1.1.Final.jar:7.1.1.Final] at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final] at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final] at org.jboss.as.ee.component.BasicComponent.constructComponentInstance(BasicComponent.java:161) [jboss-as-ee-7.1.1.Final.jar:7.1.1.Final] at org.jboss.as.ee.component.BasicComponent.createInstance(BasicComponent.java:85) [jboss-as-ee-7.1.1.Final.jar:7.1.1.Final] at org.jboss.as.ejb3.component.singleton.SingletonComponent.getComponentInstance(SingletonComponent.java:116) [jboss-as-ejb3-7.1.1.Final.jar:7.1.1.Final] at org.jboss.as.ejb3.component.singleton.SingletonComponent.start(SingletonComponent.java:130) [jboss-as-ejb3-7.1.1.Final.jar:7.1.1.Final] at org.jboss.as.ee.component.ComponentStartService.start(ComponentStartService.java:44) [jboss-as-ee-7.1.1.Final.jar:7.1.1.Final] at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811) at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_79] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_79] at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_79] Caused by: java.lang.reflect.InvocationTargetException at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_79] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_79] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_79] at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_79] at org.jboss.weld.util.reflection.SecureReflections$13.work(SecureReflections.java:264) [weld-core-1.1.5.AS71.Final.jar:2012-02-10 15:31] at org.jboss.weld.util.reflection.SecureReflectionAccess.run(SecureReflectionAccess.java:52) [weld-core-1.1.5.AS71.Final.jar:2012-02-10 15:31] at org.jboss.weld.util.reflection.SecureReflectionAccess.runAsInvocation(SecureReflectionAccess.java:137) [weld-core-1.1.5.AS71.Final.jar:2012-02-10 15:31] at org.jboss.weld.util.reflection.SecureReflections.invoke(SecureReflections.java:260) [weld-core-1.1.5.AS71.Final.jar:2012-02-10 15:31] at org.jboss.weld.introspector.jlr.WeldMethodImpl.invoke(WeldMethodImpl.java:174) [weld-core-1.1.5.AS71.Final.jar:2012-02-10 15:31] at org.jboss.weld.bean.AbstractClassBean.defaultPostConstruct(AbstractClassBean.java:516) [weld-core-1.1.5.AS71.Final.jar:2012-02-10 15:31] ... 43 more Caused by: org.springframework.jdbc.BadSqlGrammarException: PreparedStatementCallback; bad SQL grammar [select * from getvdsgroupbyvdsgroupid(?, ?, ?)]; nested exception is org.postgresql.util.PSQLException: The column name gluster_tuned_profile was not found in this ResultSet. at org.springframework.jdbc.support.SQLStateSQLExceptionTranslator.doTranslate(SQLStateSQLExceptionTranslator.java:98) [spring-jdbc.jar:3.1.1.RELEASE] at org.springframework.jdbc.support.AbstractFallbackSQLExceptionTranslator.translate(AbstractFallbackSQLExceptionTranslator.java:72) [spring-jdbc.jar:3.1.1.RELEASE] at org.springframework.jdbc.support.AbstractFallbackSQLExceptionTranslator.translate(AbstractFallbackSQLExceptionTranslator.java:80) [spring-jdbc.jar:3.1.1.RELEASE] at org.springframework.jdbc.support.AbstractFallbackSQLExceptionTranslator.translate(AbstractFallbackSQLExceptionTranslator.java:80) [spring-jdbc.jar:3.1.1.RELEASE] at org.springframework.jdbc.core.JdbcTemplate.execute(JdbcTemplate.java:603) [spring-jdbc.jar:3.1.1.RELEASE] at org.springframework.jdbc.core.JdbcTemplate.query(JdbcTemplate.java:637) [spring-jdbc.jar:3.1.1.RELEASE] at org.springframework.jdbc.core.JdbcTemplate.query(JdbcTemplate.java:666) [spring-jdbc.jar:3.1.1.RELEASE] at org.springframework.jdbc.core.JdbcTemplate.query(JdbcTemplate.java:706) [spring-jdbc.jar:3.1.1.RELEASE] at org.ovirt.engine.core.dal.dbbroker.PostgresDbEngineDialect$PostgresSimpleJdbcCall.executeCallInternal(PostgresDbEngineDialect.java:154) [dal.jar:] at org.ovirt.engine.core.dal.dbbroker.PostgresDbEngineDialect$PostgresSimpleJdbcCall.doExecute(PostgresDbEngineDialect.java:120) [dal.jar:] at org.springframework.jdbc.core.simple.SimpleJdbcCall.execute(SimpleJdbcCall.java:181) [spring-jdbc.jar:3.1.1.RELEASE] at org.ovirt.engine.core.dal.dbbroker.SimpleJdbcCallsHandler.executeImpl(SimpleJdbcCallsHandler.java:147) [dal.jar:] at org.ovirt.engine.core.dal.dbbroker.SimpleJdbcCallsHandler.executeReadList(SimpleJdbcCallsHandler.java:109) [dal.jar:] at org.ovirt.engine.core.dal.dbbroker.SimpleJdbcCallsHandler.executeRead(SimpleJdbcCallsHandler.java:101) [dal.jar:] at org.ovirt.engine.core.dao.VdsGroupDAODbFacadeImpl.get(VdsGroupDAODbFacadeImpl.java:52) [dal.jar:] at org.ovirt.engine.core.dao.VdsGroupDAODbFacadeImpl.get(VdsGroupDAODbFacadeImpl.java:44) [dal.jar:] at org.ovirt.engine.core.vdsbroker.MonitoringStrategyFactory.getMonitoringStrategyForVds(MonitoringStrategyFactory.java:30) [vdsbroker.jar:] at org.ovirt.engine.core.vdsbroker.VdsManager.<init>(VdsManager.java:96) [vdsbroker.jar:] at org.ovirt.engine.core.vdsbroker.ResourceManager.AddVds(ResourceManager.java:229) [vdsbroker.jar:] at org.ovirt.engine.core.vdsbroker.ResourceManager.init(ResourceManager.java:160) [vdsbroker.jar:] ... 53 more Caused by: org.postgresql.util.PSQLException: The column name gluster_tuned_profile was not found in this ResultSet. at org.postgresql.jdbc2.AbstractJdbc2ResultSet.findColumn(AbstractJdbc2ResultSet.java:2542) at org.postgresql.jdbc2.AbstractJdbc2ResultSet.getString(AbstractJdbc2ResultSet.java:2385) at org.jboss.jca.adapters.jdbc.WrappedResultSet.getString(WrappedResultSet.java:1381) at org.ovirt.engine.core.dao.VdsGroupDAODbFacadeImpl$VdsGroupRowMapper.mapRow(VdsGroupDAODbFacadeImpl.java:306) [dal.jar:] at org.ovirt.engine.core.dao.VdsGroupDAODbFacadeImpl$VdsGroupRowMapper.mapRow(VdsGroupDAODbFacadeImpl.java:256) [dal.jar:] at org.springframework.jdbc.core.RowMapperResultSetExtractor.extractData(RowMapperResultSetExtractor.java:92) [spring-jdbc.jar:3.1.1.RELEASE] at org.springframework.jdbc.core.RowMapperResultSetExtractor.extractData(RowMapperResultSetExtractor.java:1) [spring-jdbc.jar:3.1.1.RELEASE] at org.springframework.jdbc.core.JdbcTemplate$1.doInPreparedStatement(JdbcTemplate.java:649) [spring-jdbc.jar:3.1.1.RELEASE] at org.springframework.jdbc.core.JdbcTemplate.execute(JdbcTemplate.java:587) [spring-jdbc.jar:3.1.1.RELEASE] ... 68 more Any hint?

2 2

[ANN] oVirt 3.5.2 Final Release is now available
by Sandro Bonazzola 28 Apr '15

28 Apr '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 The oVirt team is pleased to announce that the oVirt 3.5.2 Final Release is now available as of April 28th 2015. oVirt is an open source alternative to VMware vSphere, and provides an excellent KVM management interface for multi-node virtualization. oVirt is available now for Fedora 20, Red Hat Enterprise Linux 6.6, CentOS 6.6 (or similar) and Red Hat Enterprise Linux 7.1, CentOS 7.1 (or similar). This release of oVirt includes numerous bug fixes. See the release notes [1] for a list of the new features and bugs fixed. Please refer to release notes [1] for Installation / Upgrade instructions. A new oVirt Live and oVirt Node ISO will be available soon as well[2]. Please note that mirrors[3] may need usually one day before being synchronized. Please refer to the release notes for known issues in this release. [1] http://www.ovirt.org/OVirt_3.5.2_Release_Notes [2] http://resources.ovirt.org/pub/ovirt-3.5/iso/ [3] http://www.ovirt.org/Repository_mirrors#Current_mirrors - -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJVP0l9AAoJEHw3u57E4QAOQqQP/1xFK0hv63XnK3PuY4nvgHZI 8zYx4najqu/HraI1T8CNbNdA9gRsC41Wi8Rj6NmYYjYQYli2aVRCvCJQ2ZHMJ/4C Li4PjzRN/I5jUVXTnXXFZwBR5puormC6Xw5/0BWpZl1HY9kQfp0BQAN2xZRpPOAL d05YWwkhGRlY2QqbejD2/Srs7EeaBm6a72eso87VlF0cPqmOyEQHOsZW/+ePUr8m IsEvmiLs4AjVddcThAMwnpxoTyVuvAcKcNNuimnkOLqnVn0cvEUJQuBSzeasPU9u lMJMiavT3F1NgcO8nuxl+ouxDiPPD2k3sJYWishr4kSjlAh+nHD9AiUBvwKG6wtz MsL4CEURu+ufk2IRNsiVwheS+V7NDxePZ8FiDiv8I8Fi3cJNSTs8LL9sjGZnW/uz p1CfTXr21965yManVDXqhHOU5Z5v5cp9ZLbYMU4HkBDyF9r5U/fGt5wYzaTtHIQ9 9JsPoEmWzSWGBMPeouMEpWNKJJM0RZ1DpD11qoksjTQ/nIiMP8doBlvkvPBs9ZS6 WEwgLMxa/nGm5/nO/30VDKgHTVa/bFJnxe98D0hosFs3nyFGYvj1jT707b1d0srk aHd0WYv0+7tsJ/y4QJPKoesL61zmWmdrK2URNYiyIWGgNwQJJZuYVY1ckayx63kb DMpHcfZNlBNrss7FF5lr =A4ZO -----END PGP SIGNATURE-----

1 0

[ACTION REQUIRED] oVirt 3.5.3 branch created
by Sandro Bonazzola 27 Apr '15

27 Apr '15

Hi, oVirt 3.5.3 branch has been created on hash: * 31a0009 - webadmin: "Advanced Parameters" panel disappear when choosing to use hosts provider (30 hours ago) <Ravi Nori> All patches targeted to 3.5.3 will need to be cherry-picked on the 3.5.3 branch too. Thanks -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com

2 1

vdsm: python3 support?
by Dan Kenigsberg 27 Apr '15

27 Apr '15

Vdsm depends on Python 2, but the developers of Python 2 wants us (and everybody else) to move to the slightly-different language of Python 3. There is a lot to be fixed for this to happen: - depency on libraries with no python3 port: - mom - cpopen - m2crypto - use of implicit relative imports, mostly in the storage package - use of renamed/moved functions, methods and modules (e.g. dict.iteritems, io.StringIO, itertools.izip) - use of contextlib.nested - unsafe unicode treatment - and probably much more... Fixing it all would take a long time, and may introduce regressions. We must perform it gradually. The very first step is to use syntax that is compatible with both languages, and make sure we do not regress on that front. The remaining bit is our usages of raise E, V, T statement, which has been dropped in PEP-3109. https://gerrit.ovirt.org/#/c/40214/ suggests to replace it with six.reraise(), which adds a new run-time dependency to Vdsm. https://gerrit.ovirt.org/#/c/40215/ adds an attempt to python3-compile all vdsm code, so that we do not introduce new python2-only code. Please approve/comment!

3 2

Gerrit upgrade
by David Caro 27 Apr '15

27 Apr '15

--geqNt1NAoYRYy2Pr Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi everyone, we will be upgrading gerrit this evening, if everything goes well, we might even have oauth auth (google and github). The upgrade will start at 17:00 CEST (18:00 IST) and should take ~15 min, downtime should be minimal, but some restarts might be required and cache flushes, so don't expect it to work properly until finishedf, will let you know what's the result after. Thanks! --=20 David Caro Red Hat S.L. Continuous Integration Engineer - EMEA ENG Virtualization R&D Tel.: +420 532 294 605 Email: dcaro(a)redhat.com Web: www.redhat.com RHT Global #: 82-62605 --geqNt1NAoYRYy2Pr Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJVPkP5AAoJEEBxx+HSYmnD/4MIAJ5gqxWWqM4Zuzsde7zf9TrG e6kGUHOxOwkX6zi2COvgQp3msKU3j/6T0xEcbtoqNbJ/EGtxBkQA0Qoo5x9x94n8 uL/q58v0lpRD1R0jSAJF/4KCArwsdfeGeHvM5CwB8AxQBucparr+AO3DnlpdIuUQ 1Pn2TayyOQD+gFXttRs6lMXIBimbsSq103BpnX7rRGC0d06QPQy920yv5UPqzy51 n3eXRfjFWWPeSgjavf/Jbmrovcp1gfy2qw/b/RjhhVpSZBESTlpVNR+b+DaiK2CC fleQXbkD9A0P8QH5exhDtbgBpG01uYG816iw8H93HlKCA+PpAmXczF0jsuO6Wkg= =nL9V -----END PGP SIGNATURE----- --geqNt1NAoYRYy2Pr--

1 2

Change the default space requirements of oVirt Node
by Fabian Deutsch 24 Apr '15

24 Apr '15

Hey, to support some features in Node for el7 we will increase the default space requirements from ~2GB to ~10GB. This will only affect oVirt Node (el7) in oVirt 3.6. - fabian

1 0

Relocating the vdsm upgrade logic into a new or existing service at boot time
by Fabian Deutsch 24 Apr '15

24 Apr '15

Hey, the logic which is run on vdsm upgrades is located in the specfile, and thus run when the rpm get's an update. This is fine as long as rpm is involved (like when rpm or yum or dnf is used), but it becomes - and already is - an issue for flows where the upgrade happens without rpm, like on oVirt Node. On oVirt Node the image for booting the host is getting replaced, we currently mimic the upgrade process of the specfile. But this error prone - we had a lot of bugs around this area (remember the problems with the hooks?), and we need to watch out for changes in the upgrade logic. To simplify and especially unify the logic between Node and normal hosts, I'd like to discuss if the upgrade logic can be moved to a separate service or included in one of the existsing services. The simplest approach to me would be top create a new service which is started before libvirtd and vdsmd/supervdsmd to run some logic if an upgrade of vdsm is detected. This habit - to do the upgrade logic during boot - is actually not new and systemd provides some helpers (ConditionNeedsUpdate=) around this to ease the implementation. Thoughts? Greetings - fabian -- [1] http://0pointer.net/blog/projects/stateless.html [2] http://www.freedesktop.org/software/systemd/man/systemd.unit.html

2 3