Public bug reported: 1. Exact version of Nova/OpenStack you are running:
Liberty Devstack commit f4485bae9c719ee6b0c243cf5a69a6461df0bf23 Merge: ace1e8f e5a6f82 Author: Jenkins <[email protected]> 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 <[email protected]> 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 -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : [email protected] Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
