VDSM Storage tests @ Jenkins
by Vinzenz Feenstra
Hi,
Could we please disable the storage tests until they are really working?
These random failures are really creating more noise than being helpful.
Thanks.
--
Regards,
Vinzenz Feenstra | Senior Software Engineer
RedHat Engineering Virtualization R & D
Phone: +420 532 294 625
IRC: vfeenstr or evilissimo
Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com
10 years, 4 months
oVirt test day tomorrow
by dfediuck@redhat.com
Just a reminder that tomorrow we plan to have oVirt 3.4 2nd test day.
More details coming soon.
10 years, 4 months
FOSDEM slides + recordings available
by dfediuck@redhat.com
http://www.ovirt.org/FOSDEM_2014#Sessions
I will continue to update with recordings (and last slides) as it becomes available.
This is also a good chance to thank everyone involved.
People who practiced, spoke, volunteered for stand shifts, Video handling,
helping with the oVirt-live, carrying maps, laptops, handout-sheets, poster-sign
to/from UBL and other logistics. Special thanks to Joop, René, Jorick, Robert and
Alexander who joined us in ULB .
We got a big and very positive exposure for oVirt, which as you'll be able to hear
is getting a lot of community attention now.
See you in FOSDEM 2015 ;)
Doron
10 years, 4 months
suggested patch for python-pthreading
by ybronhei@redhat.com
according to coredumps we found in the scope of the bug [1] we opened [2] that suggested to override python's implementation of thread.allocate_lock
in each coredump we saw few threads stuck with the bt:
#16 0x00007fcb69288c93 in PyEval_CallObjectWithKeywords (func=0x2527820, arg=0x7fcb6972f050, kw=<value optimized out>) at Python/ceval.c:3663
#17 0x00007fcb692ba7ba in t_bootstrap (boot_raw=0x250a820) at Modules/threadmodule.c:428
#18 0x00007fcb68fa3851 in start_thread (arg=0x7fcb1bfff700) at pthread_create.c:301
#19 0x00007fcb6866694d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:115
in pystack the threads were stuck in /usr/lib64/python2.6/threading.py (513): __bootstrap_inner
in bootstrap_inner we use thread.allocate_lock which python-pthreading does not override.
we suggest the following commit:
>From 9d89e9be1a379b3d93b23dd54a381b9ca0973ebc Mon Sep 17 00:00:00 2001
From: Yaniv Bronhaim <ybronhei(a)redhat.com>
Date: Mon, 3 Feb 2014 19:24:30 +0200
Subject: [PATCH] Mocking thread.allocate_lock with Lock imp
Signed-off-by: Yaniv Bronhaim <ybronhei(a)redhat.com>
---
pthreading.py | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/pthreading.py b/pthreading.py
index 916ca7f..96df42c 100644
--- a/pthreading.py
+++ b/pthreading.py
@@ -132,6 +132,10 @@ def monkey_patch():
Thus, Queue and SocketServer can easily enjoy them.
"""
+ import thread
+
+ thread.allocate_lock = Lock
+
import threading
threading.Condition = Condition
--
1.8.3.1
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1022036
[2] https://bugzilla.redhat.com/show_bug.cgi?id=1060749
Thanks,
Yaniv Bronhaim.
10 years, 4 months
[ANN] oVirt 3.4.0 beta2 is now available
by Sandro Bonazzola
The oVirt team is pleased to announce that the 3.4.0 second beta release is now available for testing.
Release notes and information on the changes for this update are still being worked on and will be available soon on the wiki[1].
Please ensure to follow install instruction from release notes if you're going to test it.
The existing repository ovirt-3.4.0-prerelease has been updated for delivering this beta and future refreshes until release candidate.
A new oVirt Node build will be available soon as well.
You're welcome to join us testing this beta release in next week test day [2] scheduled for 2014-02-11!
[1] http://www.ovirt.org/OVirt_3.4.0_release_notes
[2] http://www.ovirt.org/OVirt_3.4_Test_Day
--
Sandro Bonazzola
Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com
10 years, 4 months
ovirt storage creation problems
by aditya mamidwar
hey
am facing following problem while creating new storage domain in ovirt.
PFA screenshot and log file details
--
-Aditya Mamidwar
10 years, 4 months
Re: [vdsm] [Users] NAT configuration
by iheim@redhat.com
On 02/05/2014 09:27 AM, Sven Kieske wrote:
> Well, I just tested this.
> and I can't connect to virsh with this information.
> I guess the mentioned user vdsm@rhevh might not be the actual one
> used in 3.3.2 anymore? (mail is from 2012 and mentions rhev, so..)
well, that's a question for vdsm-devel
>
> or can't libvirt manage multiple authenticated users?
> Because I registered my own using:
>
> saslpasswd2 -a libvirt USERNAME
>
> which still works.
>
> Am 05.02.2014 09:15, schrieb Sven Kieske:
>> It's actually step 5 :)
>>
>> Am 05.02.2014 07:50, schrieb Itamar Heim:
>>> (step 6 explains where the user/password for libvirt/virsh are.
>>
>
10 years, 4 months
New gerrit flags behavior
by dcaroest@redhat.com
Hi everyone!
With the latest gerrit upgrade it has become easier to add the propagation of
the Code Review and Verified flags when doing a trivial rebase or when no code
was changed, so I've enabled those features for all the projects!
The change should become effective right away, so let me know if you have any
issues.
Enjoy!
--
David Caro
Red Hat S.L.
Continuous Integration Engineer - EMEA ENG Virtualization R&D
Email: dcaro(a)redhat.com
Web: www.redhat.com
RHT Global #: 82-62605
10 years, 4 months
[QE] oVirt 3.4.0 beta status
by Sandro Bonazzola
Hi,
oVirt 3.4.0 beta has been released and is actually on QA.
We're going to tart composing oVirt 3.4.0 beta2 this Thursday 2014-02-06 09:00 UTC from 3.4 branches.
This build will be used for a second Test Day scheduled for 2014-02-11.
The bug tracker [1] shows the following bugs blocking the release:
Whiteboard Bug ID Status Summary
gluster 1038988 POST Gluster brick sync does not work when host has multiple interfaces
gluster 1059606 POST Errors in rebalance and remove-brick status and sync
integration 1054080 POST gracefully warn about unsupported upgrade from legacy releases
integration 1058018 POST upgrade from 3.3 overwrites exports with acl None
There are still 393 bugs [2] targeted to 3.4.0.
Excluding node and documentation bugs we still have 238 bugs [3] targeted to 3.4.0.
Please review them as soon as possible.
Maintainers:
- Please remember to rebuild your packages before 2014-02-06 09:00 UTC if you want them to be included in 3.4.0 beta.
- Please add the bugs to the tracker if you think that 3.4.0 should not be released without them fixed.
- Please provide ETA on blockers bugs
- Please update the target to 3.4.1 or any next release for bugs that won't be in 3.4.0:
it will ease gathering the blocking bugs for next releases.
- Please fill release notes, the page has been created here [4]
- Please update http://www.ovirt.org/OVirt_3.4_TestDay before 2014-02-11
For those who want to help testing the bugs, I suggest to add yourself as QA contact for the bug.
Please also be prepared for upcoming oVirt 3.4.0 Test Day on 2014-02-11!
Thanks to all people already testing 3.4.0 beta!
[1] https://bugzilla.redhat.com/1024889
[2] http://red.ht/1eIRZXM
[3] http://red.ht/1auBU3r
[4] http://www.ovirt.org/OVirt_3.4.0_release_notes
--
Sandro Bonazzola
Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com
10 years, 4 months
Re: [vdsm] [Users] Migration failed (previous migrations succeded)
by iheim@redhat.com
On 01/31/2014 09:30 AM, Sven Kieske wrote:
> Hi,
>
> is there any documentation regarding all
> allowed settings in the vdsm.conf?
>
> I didn't find anything related in the rhev docs
that's a question for vdsm mailing list - cc-ing...
>
> Am 30.01.2014 21:43, schrieb Itamar Heim:
>> On 01/30/2014 10:37 PM, Markus Stockhausen wrote:
>>>>> Von: Itamar Heim [iheim(a)redhat.com]
>>>>> Gesendet: Donnerstag, 30. Januar 2014 21:25
>>>>> An: Markus Stockhausen; ovirt-users
>>>>> Betreff: Re: [Users] Migration failed (previous migrations succeded)
>>>>>
>>>>>
>>>>> Now I' getting serious problems. During the migration the VM was
>>>>> doing a rather slow download at 1,5 MB/s. So the memory changed
>>>>> by 15 MB per 10 seconds. No wonder that a check every 10 seconds
>>>>> was not able to see any progress. Im scared what will happen if I
>>>>> want to migrate a medium loaded system runing a database.
>>>>>
>>>>> Any tip for a parametrization?
>>>>>
>>>>> Markus
>>>>>
>>>>
>>>> what's the bandwidth? default is up to 30MB/sec, to allow up to 3 VMs to
>>>> migrate on 1Gb without congesting it.
>>>> you could raise that if you have 10GB, or raise the bandwidth cap and
>>>> reduce max number of concurrent VMs, etc.
>>>
>>> My migration network is IPoIB 10GBit. During our tests only one VM
>>> was migrated. Bandwidth cap or number of concurrent VMs has not
>>> been changed after default install.
>>>
>>> Is migration_max_bandwidth in /etc/vdsm/vdsm.conf still the right place?
>>
>> probably
>>
>>> And what settings do you suggest?
>>
>> well, to begin with, 300MB/sec on 10GE (still allowing concurrent
>> migrations)
>> _______________________________________________
>> Users mailing list
>> Users(a)ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/users
>>
>>
>>
>
10 years, 4 months