Bug 1318082

Summary:	nova create-image (aka snapshot) failing on RHOSP-5
Product:	Red Hat OpenStack	Reporter:	Dan Yocum <dyocum>
Component:	openstack-nova	Assignee:	Eoghan Glynn <eglynn>
Status:	CLOSED INSUFFICIENT_DATA	QA Contact:	nlevinki <nlevinki>
Severity:	high	Docs Contact:
Priority:	unspecified
Version:	5.0 (RHEL 6)	CC:	berrange, dasmith, dyocum, eglynn, kchamart, mbooth, ndipanov, sbauza, sferdjao, sgordon, vromanso, yeylon
Target Milestone:	---
Target Release:	8.0 (Liberty)
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2016-03-18 16:09:55 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:

Description Dan Yocum 2016-03-16 01:50:25 UTC

Description of problem:

Attempting to create a snapshot of an running VM is failing as of a recent update to openstack-nova.

The dashboard fails, as does the cli 'nova create-image ...'

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

openstack-nova-api-2014.1.5-29.el6ost.noarch

How reproducible:

every

Steps to Reproduce:
1. launch a VM (in OS1 Internal)
2. try to take a snapshot using either the dashboard or cli
3. fail!

Actual results:

queues forever, never completes

Expected results:

snapshot created!

Additional info:

Comment 2 Dan Smith 2016-03-17 20:19:03 UTC

Can we see logs please? From all services at debug level.

Comment 3 Matthew Booth 2016-03-18 16:09:55 UTC

Thanks for the report, Dan.

I can see that you've also opened a customer issue with support. I'm going to close this bug because it isn't ready for the bugzilla workflow, yet. I'd be very grateful if you could work through the problem with support to ensure that it's something which needs to come to engineering. For example, that it isn't a known problem with a workaround, or possibly even something to do with local configuration.

If the problem looks like a product bug rather than a local issue, they will then drive the bugzilla process, possibly by reopening this bug. They will also be responsible to us for ensuring we have enough information to diagnose the issue, which will include not only the reproducer steps required on your system, but also configuration and logs for all affected services. They will also gather enough information to appropriately direct the bug, which could be in nova, glance, or potentially even some other infrastructure service.

Thanks again,

Matt

Comment 4 Dan Yocum 2016-03-28 15:39:57 UTC

Yeah, that's fine.  The problem with rabbitmq resolved itself - the timeout for exchanges (or queues, or something...) is really too long.  It took a long time for some un-acked messages to clear out.