Bug 1175255 - ERROR 'no free file handlers in pool' in vdsm.log while creating VM from template
Summary: ERROR 'no free file handlers in pool' in vdsm.log while creating VM from temp...
Keywords:
Status: CLOSED DUPLICATE of bug 1145241
Alias: None
Product: oVirt
Classification: Retired
Component: ovirt-engine-core
Version: 3.4
Hardware: x86_64
OS: Linux
unspecified
urgent
Target Milestone: ---
: 3.5.1
Assignee: Tal Nisan
QA Contact: Pavel Stehlik
URL:
Whiteboard: storage
Depends On:
Blocks: 1193195
TreeView+ depends on / blocked
 
Reported: 2014-12-17 11:18 UTC by Tiemen Ruiten
Modified: 2019-04-28 09:37 UTC (History)
11 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-01-07 07:18:48 UTC
oVirt Team: Storage


Attachments (Terms of Use)
vdsm log file (899.77 KB, application/x-xz)
2014-12-17 11:18 UTC, Tiemen Ruiten
no flags Details
engine log (1.02 MB, application/x-gzip)
2014-12-21 18:01 UTC, Tiemen Ruiten
no flags Details

Description Tiemen Ruiten 2014-12-17 11:18:26 UTC
Created attachment 970055 [details]
vdsm log file

Description of problem:

ERROR 'no free file handlers in pool' in vdsm.log

Version-Release number of selected component (if applicable):
Name        : vdsm
Arch        : x86_64
Version     : 4.14.17
Release     : 0.el6


How reproducible:
Create a new cloned VM from a template.

Actual results:
Load skyrockets on the hypervisor node, other VMs stop responding. VM creation job fails.

Expected results:
New VM is created and other VMs are not affected.

Additional info:
Two node oVirt cluster running on Xeon(R) CPU E5-2650 0 @ 2.00GHz and 64 GB of RAM. Load at the moment of creating the new VM was less than 1 on both nodes. There are currently 26 VMs running on the two nodes, evenly distributed. 
The ISO domain is a gluster volume exposed through NFS. The storage domain for the VMs is also a gluster volume. The underlying filesystem for the gluster volumes is ZFS.

Comment 1 Sven Kieske 2014-12-17 13:05:38 UTC
maybe this helps:

I did not observe this behaviour with
vdsm-4.13.3-3.el6.x86_64
on a node with much more ram/cpu and vms.

HTH

Sven

Comment 2 Allon Mureinik 2014-12-21 11:40:01 UTC
Tal, can you take a look please?

Comment 3 Allon Mureinik 2014-12-21 17:49:21 UTC
Tiemen, can you please also include the engine's log?

Comment 4 Tiemen Ruiten 2014-12-21 18:01:02 UTC
Created attachment 971760 [details]
engine log

The button to create the VM was pressed around 2016-12-16 11:17.

Comment 5 Tiemen Ruiten 2015-01-07 07:18:48 UTC

*** This bug has been marked as a duplicate of bug 1145241 ***

Comment 6 Tiemen Ruiten 2015-01-07 07:21:23 UTC
The cluster didn't have a default disk policy. Once a policy was created, the problem did not occur when adding a VM or creating a disk.


Note You need to log in before you can comment on or make changes to this bug.