Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 1091990

Summary: instance status turn to ERROR when running instance suspend
Product: Red Hat OpenStack Reporter: Yogev Rabl <yrabl>
Component: openstack-novaAssignee: Nikola Dipanov <ndipanov>
Status: CLOSED INSUFFICIENT_DATA QA Contact: Ami Jeain <ajeain>
Severity: urgent Docs Contact:
Priority: urgent    
Version: 4.0CC: eglynn, ndipanov, sgordon, yeylon, yrabl
Target Milestone: ---   
Target Release: 5.0 (RHEL 7)   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2014-06-05 18:34:18 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:
Embargoed:
Attachments:
Description Flags
compute log none

Description Yogev Rabl 2014-04-28 12:57:20 UTC
Created attachment 890468 [details]
compute log

Description of problem:
When trying to suspend an instance the instance's status turn to Error. 
The instance's flavor details are:

+----------------------------+--------------------------------------+
| Property                   | Value                                |
+----------------------------+--------------------------------------+
| name                       | m1.small                             |
| ram                        | 2048                                 |
| OS-FLV-DISABLED:disabled   | False                                |
| vcpus                      | 1                                    |
| extra_specs                | {}                                   |
| swap                       |                                      |
| os-flavor-access:is_public | True                                 |
| rxtx_factor                | 1.0                                  |
| OS-FLV-EXT-DATA:ephemeral  | 40                                   |
| disk                       | 20                                   |
| id                         | 7427e83a-5f96-43af-936b-a054191482ab |
+----------------------------+--------------------------------------+

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

openstack-nova-common-2013.2.3-6.el6ost.noarch
openstack-nova-console-2013.2.3-6.el6ost.noarch
openstack-nova-network-2013.2.3-6.el6ost.noarch
python-novaclient-2.15.0-4.el6ost.noarch
python-nova-2013.2.3-6.el6ost.noarch
openstack-nova-compute-2013.2.3-6.el6ost.noarch
openstack-nova-conductor-2013.2.3-6.el6ost.noarch
openstack-nova-novncproxy-2013.2.3-6.el6ost.noarch
openstack-nova-scheduler-2013.2.3-6.el6ost.noarch
openstack-nova-api-2013.2.3-6.el6ost.noarch
openstack-nova-cert-2013.2.3-6.el6ost.noarch

How reproducible:
100%

Steps to Reproduce:
1. launch an instance from an iso image with the flavor as it is detailed above.
2. suspend the instance.


Actual results:
The instance status turns to ERROR.

Expected results:
The instance should be suspend


Additional info:
The error from the compute log is attached.

Comment 2 Nikola Dipanov 2014-04-29 19:30:30 UTC
According to the upstream discussion - this may be worth tracking here as it seems that it might be a libvirt bug. All of our domains should be persistent. There are several places where we undefine domains - but none of them seem likely to cause this.

Adding needinfo on danpb to see if this is a libvirt issue we might want to track, otherwise we should deal with this upstream as it seems to be hit by other people too.

Comment 3 Daniel Berrangé 2014-04-30 09:30:48 UTC
There's not really enough info here to give a good idea of where the bug might lie. To start with we'd really need to capture some verbose debug logs of libvirt APIs that Nova is running. eg set these env vars for nova compute

 LIBVIRT_LOG_FILTERS="1:libvirt 1:qemu" LIBVIRT_LOG_OUTPUTS="1:file:/var/log/nova/libvirt-client.log"

With that info we'd be able to see if Nova was issuing a virDomainUndefine call to cause this situation, or whether libvirt is loosing track of the defined domain.

Comment 4 Nikola Dipanov 2014-05-09 14:29:28 UTC
Adding a needinfo on the report as it seems some more input is needed. Ideally - let's move the discussion upstream if possible, but still leave this one in case we need to clone to libvirt.

Comment 5 Red Hat Bugzilla 2023-09-14 02:07:01 UTC
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 1000 days