Bug 1308651 - VM startup takes several minutes
Summary: VM startup takes several minutes
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: vdsm
Version: 3.5.3
Hardware: Unspecified
OS: Linux
high
high
Target Milestone: ovirt-3.6.3
: 3.6.0
Assignee: Nir Soffer
QA Contact: Aharon Canan
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-02-15 16:57 UTC by Gordon Watson
Modified: 2019-10-10 11:15 UTC (History)
10 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-02-22 14:51:03 UTC
oVirt Team: Storage
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description Gordon Watson 2016-02-15 16:57:18 UTC
Description of problem:

VMs can take several minutes (e.g. 7 minutes in the example provided below, but some take longer) to start up. The delay appears to be in VDSM in the 'prepareImage' sequence.


Version-Release number of selected component (if applicable):

RHEV 3.5.3
RHEL 6.6 hosts w/vdsm-4.16.20-1


How reproducible:

Not.


Steps to Reproduce:
1.
2.
3.

Actual results:

Starting VMs can take several minutes. This is across different hosts. The same VMs can later start up much quicker.

An example of one such VM is that it consists of a single disk with a single volume on an NFS storage domain.


Expected results:

VMs start up in a timely fashion.


Additional info:

Comment 8 Allon Mureinik 2016-02-16 15:41:02 UTC
Nir, this sounds awfully familiar - does this ring any bells?

Comment 9 Nir Soffer 2016-02-16 17:35:35 UTC
(In reply to Allon Mureinik from comment #8)
> Nir, this sounds awfully familiar - does this ring any bells?

vdsm 4.16.20 does not include this fix:

46a328b fileSD: Optimize getAllVolumes on file storage

Which can cause long delays in prepareImage, and mixed with many cores and many
concurrent prepareImage calls, can be related.

I will need to look in the logs to understand if there is another issue.

So the best advice for now is to upgrade to 4.16.21, or better to version
that support cpu_affinity option.


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