yahoo-eng-team team mailing list archive

[Hong <hong.chung@xxxxxxxxxx>]

Public bug reported:

1. Exact version of Nova/OpenStack you are running:

Liberty Devstack

commit f4485bae9c719ee6b0c243cf5a69a6461df0bf23
Merge: ace1e8f e5a6f82
Author: Jenkins <jenkins@xxxxxxxxxxxxxxxxxxxx>
Date:   Thu Oct 1 07:14:41 2015 +0000

    Merge "Cleanup nova v2.1 API testing options"


2. Relevant log files:  n-cpu.log file is in the attachment.

3. Reproduce steps:
- Setup is running with Liberty devstack version on Ubuntu 14.04.
- Connected to a NetApp eSeries (iSCSI) for storage.  (Using multipath to manage the array)
- Launch an instance from Horizon, by selecting "launch instance", input an Instance Name, m1.small, Instance count: 1, select "Boot from image (creates a new volume)", select "cirros..." image, default size(20G for small), then click on "Launch"

- The launch instance failed with the following error:

Error: Failed to perform requested operation on instance "testvm", the
instance has an error status: Please try again later [Error: Build of
instance 1304643b-f8f2-4894-89d8-26c1b8d3e438 aborted: Block Device
Mapping is Invalid.].

It seems the host failed to get the new disk from the eSeries storage.

Did some more tests with the following observation:

When I create a new (1st) volume with certain image (cirros), the host created a host on the array, started the iSCSI sessions, and mapped the volume.  But then the iSCSI sessions disconnected and the host failed to discover the volume, “sudo multipath –ll” did not list any volume.
 
Then I tried to create a 2nd instance, the host restarted the iSCSI sessions, created and mapped a new (2nd) volume.  This time the host discovered the first volume, but not the newly created (2nd) volume.   Also, the iSCSI sessions stay this time, they didn’t get disconnected.
 
It seem like there might be a problem with when the newly added volume is being discover is not in proper order, the discover/rescan command is being use too early.

Also, tried the same with the Kilo Devstack version, and this version is
working fine.

** Affects: nova
     Importance: Undecided
         Status: New

** Attachment added: "n-cpu.log"
   https://bugs.launchpad.net/bugs/1501914/+attachment/4481340/+files/n-cpu.log.recreate

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
https://bugs.launchpad.net/bugs/1501914

Title:
  Liberty devstack failed to launch instance w/ NetApp eSeries.

Status in OpenStack Compute (nova):
  New

Bug description:
  1. Exact version of Nova/OpenStack you are running:

  Liberty Devstack

  commit f4485bae9c719ee6b0c243cf5a69a6461df0bf23
  Merge: ace1e8f e5a6f82
  Author: Jenkins <jenkins@xxxxxxxxxxxxxxxxxxxx>
  Date:   Thu Oct 1 07:14:41 2015 +0000

      Merge "Cleanup nova v2.1 API testing options"

  
  2. Relevant log files:  n-cpu.log file is in the attachment.

  3. Reproduce steps:
  - Setup is running with Liberty devstack version on Ubuntu 14.04.
  - Connected to a NetApp eSeries (iSCSI) for storage.  (Using multipath to manage the array)
  - Launch an instance from Horizon, by selecting "launch instance", input an Instance Name, m1.small, Instance count: 1, select "Boot from image (creates a new volume)", select "cirros..." image, default size(20G for small), then click on "Launch"

  - The launch instance failed with the following error:

  Error: Failed to perform requested operation on instance "testvm", the
  instance has an error status: Please try again later [Error: Build of
  instance 1304643b-f8f2-4894-89d8-26c1b8d3e438 aborted: Block Device
  Mapping is Invalid.].

  It seems the host failed to get the new disk from the eSeries storage.

  Did some more tests with the following observation:

  When I create a new (1st) volume with certain image (cirros), the host created a host on the array, started the iSCSI sessions, and mapped the volume.  But then the iSCSI sessions disconnected and the host failed to discover the volume, “sudo multipath –ll” did not list any volume.
   
  Then I tried to create a 2nd instance, the host restarted the iSCSI sessions, created and mapped a new (2nd) volume.  This time the host discovered the first volume, but not the newly created (2nd) volume.   Also, the iSCSI sessions stay this time, they didn’t get disconnected.
   
  It seem like there might be a problem with when the newly added volume is being discover is not in proper order, the discover/rescan command is being use too early.

  Also, tried the same with the Kilo Devstack version, and this version
  is working fine.

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1501914/+subscriptions