oVirt 3.4.3 GA postponed due to blocker
by Sandro Bonazzola
Hi,
recent python upgrade in Fedora 19 broke vdsmd service.
While we wait for an updated python-cpopen package to be built, we're postponing oVirt 3.4.3 GA.
The package should be built for tomorrow and will be hosted on ovirt repo until it will be available on Fedora repositories.
We'll release 3.4.3 after basic sanity testing with the new package.
Thanks,
--
Sandro Bonazzola
Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com
9 years, 10 months
python-ioprocess for el7?
by Adam Litke
Hi,
I am looking for python-ioprocess RPMs (new enough for latest vdsm
requirements). Can anyone point me in the right direction? Thanks!
--
Adam Litke
9 years, 10 months
[QE] Hardening Guide
by Sandro Bonazzola
Hi,
while I was working on Bug 1097022 - ovirt-engine-setup: weak default passwords for PostgreSQL database users
I was wondering where to write hardening tips described in comment #18.
It looks like we don't have any page on oVirt wiki about hardening.
Anyone interested in contributing to such page?
I guess it can be created as http://www.ovirt.org/OVirt_Hardening_Guide
Thoughts?
--
Sandro Bonazzola
Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com
9 years, 10 months
problem with UI css file
by Kobi Ianko
Hi,
Got the following error in the engine log:
Can't read file "/home/kianku/ovirt-engine/etc/ovirt-engine/branding/00-ovirt.brand/patternfly/css/styles.min.css" for request "/ovirt-engine/webadmin/theme/00-ovirt.brand/patternfly/css/styles.min.css", will send a 404 error response.
for some reason I'm missing "patternfly" directory...
I'm fetched and rebase with latest..
10x
9 years, 10 months
oVirt Node Weekly Meeting Minutes - July 16 2014
by Fabian Deutsch
Minutes: http://ovirt.org/meetings/ovirt/2014/ovirt.2014-07-15-13.17.html
Minutes (text): http://ovirt.org/meetings/ovirt/2014/ovirt.2014-07-15-13.17.txt
Log: http://ovirt.org/meetings/ovirt/2014/ovirt.2014-07-15-13.17.log.html
=================================
#ovirt: oVirt Node Weekly Meeting
=================================
Meeting started by fabiand at 13:17:08 UTC. The full logs are available
at http://ovirt.org/meetings/ovirt/2014/ovirt.2014-07-15-13.17.log.html
.
Meeting summary
---------------
* Agenda (fabiand, 13:19:01)
* Action Item Review (fabiand, 13:19:18)
* Next Release (3.1) (fabiand, 13:19:29)
* 3.5 Feature Status (fabiand, 13:20:51)
* Other Items (fabiand, 13:20:59)
* Action Item Review (fabiand, 13:21:17)
* LINK:
http://resources.ovirt.org/meetings/ovirt/2014/ovirt.2014-07-08-13.03.txt
(fabiand, 13:21:55)
* fabiand and rbarry to test the ovirt-node iso (fabiand, 13:22:12)
* QE team discovered some issues (fabiand, 13:23:15)
* LINK: http://lists.ovirt.org/pipermail/devel/2014-July/008142.html
(fabiand, 13:24:30)
* Next Release (3.1) (fabiand, 13:26:40)
* 3.5 Feature Status (fabiand, 13:29:55)
* generic-registration -- Needs some clearifying (fabiand, 13:30:48)
* hosted-engine-plugin -- Needs a maintainer (fabiand, 13:31:03)
* virtual-appliance -- Has a working jenkins build (fabiand,
13:31:22)
* Other Items (fabiand, 13:35:45)
* LINK: http://bpaste.net/show/HrZnry3kru8D1naejzt7/ (peetaur2,
15:39:00)
Meeting ended at 14:04:49 UTC.
Action Items
------------
Action Items, by person
-----------------------
* **UNASSIGNED**
* (none)
People Present (lines said)
---------------------------
* fabiand (44)
* YamakasY_ (40)
* peetaur2 (32)
* clarkee (22)
* ojorge (21)
* thomas (20)
* jhernand (13)
* bkp (12)
* msivak (12)
* sbonazzo (10)
* jvandewege (8)
* urthmover (8)
* rbarry (8)
* dougsland (5)
* YamakasY (5)
* leaboy (3)
* Dick-Tracy (3)
* ovirtbot (3)
* oved_ (2)
* SvenKieske (2)
* lvernia (2)
* kobi (1)
* Moe__ (1)
* derez (1)
* dcaro (1)
* eedri (1)
* yzaslavs|mtg (1)
Generated by `MeetBot`_ 0.1.4
.. _`MeetBot`: http://wiki.debian.org/MeetBot
9 years, 10 months
[QE][ACTION NEEDED] oVirt 3.5.0 Second Beta status
by Sandro Bonazzola
Hi,
We're going to compose oVirt 3.5.0 Second Beta on Mon *2014-07-21 08:00 UTC*.
Maintainers:
- Please be sure that 3.5 snapshot allow to create VMs before *2014-07-20 15:00 UTC*
The bug tracker [1] shows the following proposed blockers to be reviewed:
Bug ID Whiteboard Status Summary
1115044 infra POST Host stuck in "Unassinged" state when using jsonrpc and disconnection from pool failed
1115152 infra POST Cannot edit or create block storage doamin when using jsonrpc
1113974 integration POST Hostname validation during all-in-one setup
1115001 network ASSIGNED Error code 23 when invoking Setup Networks
1119019 network POST Remove network with network custom properties from Host fails
1110305 virt POST BSOD - CLOCK_WATCHDOG_TIMEOUT_2 - Win 7SP1 guest, need to set hv_relaxed
Feature freeze is now effective, and branch has been created.
All new patches must be backported to 3.5 branch too.
Features completed are marked in green on Features Status Table [2]
There are still 412 bugs [3] targeted to 3.5.0.
Excluding node and documentation bugs we still have 364 bugs [4] targeted to 3.5.0.
Maintainers / Assignee:
- Please check ensure that completed features are marked in green on Features Status Table [2]
- Please remember to rebuild your packages before *2014-07-20 15:00* if needed, otherwise nightly snapshot will be taken.
- Please be sure that 3.5 snapshot allow to create VMs before *2014-07-20 15:00 UTC*
- If you find a blocker bug please remember to add it to the tracker [1]
- Please start filling release notes, the page has been created here [5]
- Please review and add test cases to oVirt 3.5 Second Test Day [6]
Community:
- save the date for second test day scheduled on 2014-07-24!
- You're welcome to join us testing next beta release and getting involved in oVirt Quality Assurance[7]!
[1] http://bugzilla.redhat.com/1073943
[2] http://bit.ly/17qBn6F
[3] http://red.ht/1pVEk7H
[4] http://red.ht/1rLCJwF
[5] http://www.ovirt.org/OVirt_3.5_Release_Notes
[6] http://www.ovirt.org/OVirt_3.5_TestDay
[7] http://www.ovirt.org/OVirt_Quality_Assurance
Thanks,
--
Sandro Bonazzola
Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com
9 years, 10 months
[QE][ACTION NEEDED] oVirt 3.4.3 GA status
by Sandro Bonazzola
Hi,
We're going to start composing oVirt 3.4.3 GA tomorrow *2014-07-17 08:00 UTC* from 3.4.3 branch.
The bug tracker [1] shows no open blocking bugs for the release
There are still 10 bugs [2] targeted to 3.4.3.
Excluding node and documentation bugs we still have 3 bugs [3] targeted to 3.4.3.
Bug ID Status Whiteboard Severity Summary
1111655 NEW storage urgent Disks imported from Export Domain to Data Domain are converted to Preallocated after upgrade...
1059309 NEW sla high [events] 'Available memory of host $host (...) under defined threshold...' is logged only once
1048880 NEW network unspecified [vdsm][openstacknet] Migration fails for vNIC using OVS + security groups
Maintainers / Assignee:
- Please add the bugs to the tracker if you think that 3.4.3 should not be released without them fixed.
- Please update the target to any next release for bugs that won't be in 3.4.3:
it will ease gathering the blocking bugs for next releases.
- Please fill release notes, the page has been created here [4]
- Please build packages before today *2014-07-16 15:00 UTC*.
Community:
- If you're testing oVirt 3.4 nightly snapshot, please add yourself to the test page [5]
[1] bugzilla.redhat.com/1107968
[2] http://red.ht/1lBAw2R
[3] http://red.ht/1ly9hfA
[4] http://www.ovirt.org/OVirt_3.4.3_Release_Notes
[5] http://www.ovirt.org/Testing/oVirt_3.4.3_Testing
--
Sandro Bonazzola
Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com
9 years, 10 months
[VDSM][sampling] thread pool status and handling of stuck calls
by Francesco Romani
Hi,
Nir has begun reviewing my draft patches about the thread pool and sampling refactoring (thanks!),
and already suggested quite some improvements which I'd like to summarize
Quick links to the ongoing discussion:
http://gerrit.ovirt.org/#/c/29191/8/lib/threadpool/worker.py,cm
http://gerrit.ovirt.org/#/c/29190/4/lib/threadpool/README.rst,cm
Quick summary of the discussion on gerrit so far:
1. extract the scheduling logic from the thread pool. Either add a separate scheduler class
or let the sampling task reschedule themselves after a succesfull completion.
In any way the concept of 'periodic task', and the added complexity, isn't needed.
2. drop all the *queue classes I've added, thus making the package simpler.
They are no longer needed since we remove the concept of periodic task.
3. have per-task timeout, move the stuck task detection elsewhere, like in the worker thread, ot
maybe better in the aforementioned scheduler.
If the scheduler finds that any task started in the former pass (or even before!)
has not yet completed, there is no point in keeping this task alive and it should be cancelled.
4. the sampling task (or maybe the scheduler) can be smarter and halting the sample in presence of
not responding calls for a given VM, granted the VM reports its 'health'/responsiveness.
(Hopefully I haven't forgot anything big)
In the draft currently published, I reluctantly added the *queue classes and I agree the periodic
task implementation is messy, so I'll be very happy to drop them.
However, a core question still holds: what to do in presence of the stuck task?
I think it is worth to discuss this topic on a medium friendlier than gerrit, as it is the single
most important decision to make in the sampling refactoring.
It all boils down to:
Should we just keep somewhere stuck threads and wait? Should we cancel stuck tasks?
A. Let's cancel the stuck tasks.
If we move toward a libvirt connection pool, and we give each worker thread in the sampling pool
a separate libvirt connection, hopefully read-only, then we should be able to cancel stuck task by
killing the worker's libvirt connection. We'll still need a (probably much simpler) watchman/supervisor,
but no big deal here.
Libvirt allows to close a connection from a different thread.
I haven't actually tried to unstuck a blocked thread this way, but I have no reason to believe it
will not work.
B. Let's keep around blocked threads
The code as it is just leaves a blocked libvirt call and the worker thread that carried it frozen.
The stuck worker thread can be replaced up to a cap of frozen threads.
In this worst case scenario, we end up with one (blocked!) thread per VM, as it is today, and with
no sampling data.
I believe that #A has some drawbacks which we risk to overlook, and on the same time #B has some merits.
Let me explain:
The hardest case is a call blocked in the kernel in D state. Libvirt has no more room than VDSM
to unblock it; and libvirt itself *has* a pool of resources (threads in this case) which can be depleted
by stuck calls. Actually, retrying to do a failed task may deplete their pool even faster[1].
I'm not happy to just push this problem down the stack, as it looks to me that we gain
very little by doing so. VDSM itself surely stays cleaner, but the VDS/hypervisor hosts on the whole
improves just a bit: libvirt scales better, and that gives us some more room.
On the other hand, by avoiding to reissue dangerous calls, I believe we make better use of
the host resources in general. Actually, the point of keeping blocked thread around is a side effect
of not reattempting blocked calls. Moreover, to keep the blocked thread around has a significant
benefit: we can discover at the earliest moment when it is safe again to do the blocked call,
because the blocked call itself returns and we can track this event! (and of course drop the
now stale result). Otherwise, if we drop the connection, we'll lose this event and we have no
more option that trying again and hoping for the best[2]
I know the #B approach is not the cleanest, but I think it has slightly more appeal, especially
on the libvirt depletion front.
Thoughts and comments very welcome!
+++
[1] They have extensions to management API to dinamically adjust their thread pool and/or to cancel
tasks, but it is in the RHEL7.2 timeframe.
[2] A crazy idea would be to do something like http://en.wikipedia.org/wiki/Exponential_backoff
which I'm not sure would be beneficial
Bests and thanks,
--
Francesco Romani
RedHat Engineering Virtualization R & D
Phone: 8261328
IRC: fromani
9 years, 10 months
Custom fencing with virsh_fence
by Adam Litke
Hi all,
I am trying to configure custom fencing using fence_virsh in order to
test out fencing flows with my virtualized oVirt hosts. I'm getting a
failure when clicking the "Test" button. Can someone help me to
diagnose the problem? I have applied the following settings using
engine-config:
~/ovirt-engine/bin/engine-config -s CustomVdsFenceType="xxxvirt"
~/ovirt-engine/bin/engine-config -s CustomFenceAgentMapping="xxxvirt=virsh"
~/ovirt-engine/bin/engine-config -s CustomVdsFenceOptionMapping="xxxvirt:address=ip,username=username,password=password"
(note that engine-config seems to arbitrarily limit the number of
mapped options to 3. Seems like a bug to me).
Here is the log output in engine.log:
2014-07-15 11:43:34,813 INFO
[org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector]
(http--0.0.0.0-8080-1) Correlation ID: null, Call Stack: null, Custom
Event ID: -1, Message: Host centennial from cluster block was chosen
as a proxy to execute Status command on Host cascade.
2014-07-15 11:43:34,813 INFO
[org.ovirt.engine.core.bll.FenceExecutor] (http--0.0.0.0-8080-1) Using
Host centennial from cluster block as proxy to execute Status command
on Host
2014-07-15 11:43:34,815 INFO
[org.ovirt.engine.core.bll.FenceExecutor] (http--0.0.0.0-8080-1)
Executing <Status> Power Management command, Proxy Host:centennial,
Agent:virsh, Target Host:, Management IP:192.168.2.101, User:root,
Options:
2014-07-15 11:43:34,816 INFO
[org.ovirt.engine.core.vdsbroker.vdsbroker.FenceVdsVDSCommand]
(http--0.0.0.0-8080-1) START, FenceVdsVDSCommand(HostName =
centennial, HostId = a34f7dbc-dd99-4831-a1a9-54c411080ec1, targetVdsId
= b6b9d480-e20f-411a-9b9c-883fac32a4e5, action = Status, ip =
192.168.2.101, port = , type = virsh, user = root, password = ******,
options = ''), log id: 24f33bda
2014-07-15 11:43:34,875 ERROR
[org.ovirt.engine.core.vdsbroker.vdsbroker.FenceVdsVDSCommand]
(http--0.0.0.0-8080-1) Failed in FenceVdsVDS method, for vds:
centennial; host: 192.168.2.103
2014-07-15 11:43:34,876 ERROR
[org.ovirt.engine.core.vdsbroker.vdsbroker.FenceVdsVDSCommand]
(http--0.0.0.0-8080-1) Command FenceVdsVDSCommand(HostName =
centennial, HostId = a34f7dbc-dd99-4831-a1a9-54c411080ec1, targetVdsId
= b6b9d480-e20f-411a-9b9c-883fac32a4e5, action = Status, ip =
192.168.2.101, port = , type = virsh, user = root, password = ******,
options = '') execution failed. Exception: ClassCastException:
[Ljava.lang.Object; cannot be cast to java.lang.String
2014-07-15 11:43:34,877 INFO
[org.ovirt.engine.core.vdsbroker.vdsbroker.FenceVdsVDSCommand]
(http--0.0.0.0-8080-1) FINISH, FenceVdsVDSCommand, log id: 24f33bda
--
Adam Litke
9 years, 10 months
