[Yahoo-eng-team] [Bug 1475411] [NEW] During post_live_migration the nova libvirt driver assumes that the destination connection info is the same as the source, which is not always true
Public bug reported: The post_live_migration step for Nova libvirt driver is currently making a bad assumption about the source and destination connector information. The destination connection info may be different from the source which ends up causing LUNs to be left dangling on the source as the BDM has overridden the connection info with that of the destination. Code section where this problem is occuring: https://github.com/openstack/nova/blob/master/nova/virt/libvirt/driver.py#L6036 At line 6038 the potentially wrong connection info will be passed to _disconnect_volume which then ends up not finding the proper LUNs to remove (and potentially removes the LUNs for a different volume instead). By adding debug logging after line 6036 and then comparing that to the connection info of the source host (by making a call to Cinder's initialize_connection API) you can see that the connection info does not match: http://paste.openstack.org/show/TjBHyPhidRuLlrxuGktz/ Version of nova being used: commit 35375133398d862a61334783c1e7a90b95f34cdb Merge: 83623dd b2c5542 Author: Jenkins jenk...@review.openstack.org Date: Thu Jul 16 02:01:05 2015 + Merge Port crypto to Python 3 ** Affects: nova Importance: Undecided Assignee: Anthony Lee (anthony-mic-lee) Status: New ** Tags: live-migration ** Changed in: nova Assignee: (unassigned) = Anthony Lee (anthony-mic-lee) ** Description changed: The post_live_migration step for Nova libvirt driver is currently making a bad assumption about the source and destination connector information. The destination connection info may be different from the source which ends up causing LUNs to be left dangling on the source as the BDM has overridden the connection info with that of the destination. Code section where this problem is occuring: https://github.com/openstack/nova/blob/master/nova/virt/libvirt/driver.py#L6036 At line 6038 the potentially wrong connection info will be passed to _disconnect_volume which then ends up not finding the proper LUNs to remove (and potentially removes the LUNs for a different volume instead). - By adding debug logging after line 6036 and then compare that to the + By adding debug logging after line 6036 and then comparing that to the connection info of the source host (by making a call to Cinder's initialize_connection API) you can see that the connection info does not match: http://paste.openstack.org/show/TjBHyPhidRuLlrxuGktz/ Version of nova being used: commit 35375133398d862a61334783c1e7a90b95f34cdb Merge: 83623dd b2c5542 Author: Jenkins jenk...@review.openstack.org Date: Thu Jul 16 02:01:05 2015 + - Merge Port crypto to Python 3 + Merge Port crypto to Python 3 -- 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/1475411 Title: During post_live_migration the nova libvirt driver assumes that the destination connection info is the same as the source, which is not always true Status in OpenStack Compute (nova): New Bug description: The post_live_migration step for Nova libvirt driver is currently making a bad assumption about the source and destination connector information. The destination connection info may be different from the source which ends up causing LUNs to be left dangling on the source as the BDM has overridden the connection info with that of the destination. Code section where this problem is occuring: https://github.com/openstack/nova/blob/master/nova/virt/libvirt/driver.py#L6036 At line 6038 the potentially wrong connection info will be passed to _disconnect_volume which then ends up not finding the proper LUNs to remove (and potentially removes the LUNs for a different volume instead). By adding debug logging after line 6036 and then comparing that to the connection info of the source host (by making a call to Cinder's initialize_connection API) you can see that the connection info does not match: http://paste.openstack.org/show/TjBHyPhidRuLlrxuGktz/ Version of nova being used: commit 35375133398d862a61334783c1e7a90b95f34cdb Merge: 83623dd b2c5542 Author: Jenkins jenk...@review.openstack.org Date: Thu Jul 16 02:01:05 2015 + Merge Port crypto to Python 3 To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1475411/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1458958] [NEW] Exceptions from Cinder detach volume API not handled
Public bug reported: There is currently a Cinder spec in-progress that proposes the removal of file locks that are present during volume attach / detach and a few other locations. Nova does not appear to be handling exceptions thrown during the volume detach process in a way that notifies the user why the detach failed. Example of what happens when an exception is thrown during a detach by Cinder's API: http://paste.openstack.org/show/KBpPWxfVMmQ5GmLeAFpG/ Related Cinder WIP spec giving an overview of why Cinder API might throw exceptions now: https://review.openstack.org/#/c/149894/ Related Cinder WIP patch showing potential changes to Cinder API: https://review.openstack.org/#/c/153748/ When a volume is in an 'ING' state, Cinder API calls that interact with that volume will return an exception notifying a caller that that volume is busy. There may be other calls to the Cinder API (that deal with volumes) that Nova does not handle an exception from. Exceptions from those calls will need to be handled, too. In order to reproduce the above exception: Add 'raise exception.VolumeIsBusy(message=sample)' to the top of the begin_detaching function in cinder/api.py. restart c-api. After attaching a volume in OpenStack, attempt to detach it. The above exception will occur in n-api. ** Affects: nova Importance: Undecided Status: New -- 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/1458958 Title: Exceptions from Cinder detach volume API not handled Status in OpenStack Compute (Nova): New Bug description: There is currently a Cinder spec in-progress that proposes the removal of file locks that are present during volume attach / detach and a few other locations. Nova does not appear to be handling exceptions thrown during the volume detach process in a way that notifies the user why the detach failed. Example of what happens when an exception is thrown during a detach by Cinder's API: http://paste.openstack.org/show/KBpPWxfVMmQ5GmLeAFpG/ Related Cinder WIP spec giving an overview of why Cinder API might throw exceptions now: https://review.openstack.org/#/c/149894/ Related Cinder WIP patch showing potential changes to Cinder API: https://review.openstack.org/#/c/153748/ When a volume is in an 'ING' state, Cinder API calls that interact with that volume will return an exception notifying a caller that that volume is busy. There may be other calls to the Cinder API (that deal with volumes) that Nova does not handle an exception from. Exceptions from those calls will need to be handled, too. In order to reproduce the above exception: Add 'raise exception.VolumeIsBusy(message=sample)' to the top of the begin_detaching function in cinder/api.py. restart c-api. After attaching a volume in OpenStack, attempt to detach it. The above exception will occur in n-api. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1458958/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1439861] [NEW] encrypted iSCSI volume attach fails to attach when multipath-tools installed
Public bug reported: An error was occurring in a devstack setup with nova version: commit ab25f5f34b6ee37e495aa338aeb90b914f622b9d Merge instance termination with update_dns_entries set fails A volume-type encrypted with CryptsetupEncryptor was being used. A volume was created using this volume-type and an attempt to attach it to an instance was made. This error also occurred when using the LuksEncryptor for the volume-type. The following error occurred in n-cpu during attachment: Stack Trace: 2015-04-02 13:39:54.397 ERROR nova.virt.block_device [req-a8220e7d-8d1e-459d-be1f-4ddd65b7ff66 admin admin] [instance: 41d0c192-a1ce-45eb-a5ff-bcb96ec0d8e5] Driver failed to attach volume 81c5f69a-9b01-4f c0-a105-be9d3c966aaf at /dev/vdb 2015-04-02 13:39:54.397 TRACE nova.virt.block_device [instance: 41d0c192-a1ce-45eb-a5ff-bcb96ec0d8e5] Traceback (most recent call last): 2015-04-02 13:39:54.397 TRACE nova.virt.block_device [instance: 41d0c192-a1ce-45eb-a5ff-bcb96ec0d8e5] File /opt/stack/nova/nova/virt/block_device.py, line 251, in attach 2015-04-02 13:39:54.397 TRACE nova.virt.block_device [instance: 41d0c192-a1ce-45eb-a5ff-bcb96ec0d8e5] device_type=self['device_type'], encryption=encryption) 2015-04-02 13:39:54.397 TRACE nova.virt.block_device [instance: 41d0c192-a1ce-45eb-a5ff-bcb96ec0d8e5] File /opt/stack/nova/nova/virt/libvirt/driver.py, line 1064, in attach_volume 2015-04-02 13:39:54.397 TRACE nova.virt.block_device [instance: 41d0c192-a1ce-45eb-a5ff-bcb96ec0d8e5] self._disconnect_volume(connection_info, disk_dev) 2015-04-02 13:39:54.397 TRACE nova.virt.block_device [instance: 41d0c192-a1ce-45eb-a5ff-bcb96ec0d8e5] File /usr/local/lib/python2.7/dist-packages/oslo_utils/excutils.py, line 85, in __exit__ 2015-04-02 13:39:54.397 TRACE nova.virt.block_device [instance: 41d0c192-a1ce-45eb-a5ff-bcb96ec0d8e5] six.reraise(self.type_, self.value, self.tb) 2015-04-02 13:39:54.397 TRACE nova.virt.block_device [instance: 41d0c192-a1ce-45eb-a5ff-bcb96ec0d8e5] File /opt/stack/nova/nova/virt/libvirt/driver.py, line 1051, in attach_volume 2015-04-02 13:39:54.397 TRACE nova.virt.block_device [instance: 41d0c192-a1ce-45eb-a5ff-bcb96ec0d8e5] encryptor.attach_volume(context, **encryption) 2015-04-02 13:39:54.397 TRACE nova.virt.block_device [instance: 41d0c192-a1ce-45eb-a5ff-bcb96ec0d8e5] File /opt/stack/nova/nova/volume/encryptors/cryptsetup.py, line 93, in attach_volume 2015-04-02 13:39:54.397 TRACE nova.virt.block_device [instance: 41d0c192-a1ce-45eb-a5ff-bcb96ec0d8e5] self._open_volume(passphrase, **kwargs) 2015-04-02 13:39:54.397 TRACE nova.virt.block_device [instance: 41d0c192-a1ce-45eb-a5ff-bcb96ec0d8e5] File /opt/stack/nova/nova/volume/encryptors/cryptsetup.py, line 78, in _open_volume 2015-04-02 13:39:54.397 TRACE nova.virt.block_device [instance: 41d0c192-a1ce-45eb-a5ff-bcb96ec0d8e5] check_exit_code=True, run_as_root=True) 2015-04-02 13:39:54.397 TRACE nova.virt.block_device [instance: 41d0c192-a1ce-45eb-a5ff-bcb96ec0d8e5] File /opt/stack/nova/nova/utils.py, line 206, in execute 2015-04-02 13:39:54.397 TRACE nova.virt.block_device [instance: 41d0c192-a1ce-45eb-a5ff-bcb96ec0d8e5] return processutils.execute(*cmd, **kwargs) 2015-04-02 13:39:54.397 TRACE nova.virt.block_device [instance: 41d0c192-a1ce-45eb-a5ff-bcb96ec0d8e5] File /usr/local/lib/python2.7/dist-packages/oslo_concurrency/processutils.py, line 233, in execute 2015-04-02 13:39:54.397 TRACE nova.virt.block_device [instance: 41d0c192-a1ce-45eb-a5ff-bcb96ec0d8e5] cmd=sanitized_cmd) 2015-04-02 13:39:54.397 TRACE nova.virt.block_device [instance: 41d0c192-a1ce-45eb-a5ff-bcb96ec0d8e5] ProcessExecutionError: Unexpected error while running command. 2015-04-02 13:39:54.397 TRACE nova.virt.block_device [instance: 41d0c192-a1ce-45eb-a5ff-bcb96ec0d8e5] Command: sudo nova-rootwrap /etc/nova/rootwrap.conf cryptsetup create --key-file=- ip-10.50.3.20:3260- iscsi-iqn.2003-10.com.lefthandnetworks:vsa-12-721:853:volume-81c5f69a-9b01-4fc0-a105-be9d3c966aaf-lun-0 /dev/sdb 2015-04-02 13:39:54.397 TRACE nova.virt.block_device [instance: 41d0c192-a1ce-45eb-a5ff-bcb96ec0d8e5] Exit code: 5 2015-04-02 13:39:54.397 TRACE nova.virt.block_device [instance: 41d0c192-a1ce-45eb-a5ff-bcb96ec0d8e5] Stdout: u'' 2015-04-02 13:39:54.397 TRACE nova.virt.block_device [instance: 41d0c192-a1ce-45eb-a5ff-bcb96ec0d8e5] Stderr: u'Cannot use device /dev/sdb which is in use (already mapped or mounted).\n' 2015-04-02 13:39:54.397 TRACE nova.virt.block_device [instance: 41d0c192-a1ce-45eb-a5ff-bcb96ec0d8e5] After looking into reasons why the device would be busy it was found that uninstalling multipath-tools seemed to fix the problem. Multipath- tools appears to keep the device busy even if not used. iscsi_use_multipath was not set to True in nova.conf. Steps to reproduce: install multipath-tools and wait for multipath daemon service to start. attempt to attach an encrypted volume to an instance The
[Yahoo-eng-team] [Bug 1439855] [NEW] encrypted iSCSI volume fails to attach, name too long
Public bug reported: When running the following tempest tests an error occurs in n-cpu: tempest.scenario.test_encrypted_cinder_volumes.TestEncryptedCinderVolumes.test_encrypted_cinder_volumes_cryptsetup test_encrypted_cinder_volumes_luks This occurred when using devstack with nova at: HEAD is now at d0c2684 Merge libvirt: Resize down an instance booted from a volume Both stack traces below are from n-cpu logs: Stack Trace (tempest.scenario.test_encrypted_cinder_volumes.TestEncryptedCinderVolumes.test_encrypted_cinder_volumes_cryptsetup): 2015-03-27 18:03:07.990 ERROR nova.compute.manager [req-cc941973-c038-4bac-a5ca-d516cd5dd33d TestEncryptedCinderVolumes-658052177 TestEncryptedCinderVolumes-1476988517] [instance: a2cccacf-2876-4e94-94e0-dbb3fbf51c46] Failed to attach 2ab47be7-64ac-4d34-a38c-59c5e97e2ec2 at /dev/vdb 2015-03-27 18:03:07.990 29082 TRACE nova.compute.manager [instance: a2cccacf-2876-4e94-94e0-dbb3fbf51c46] Traceback (most recent call last): 2015-03-27 18:03:07.990 29082 TRACE nova.compute.manager [instance: a2cccacf-2876-4e94-94e0-dbb3fbf51c46] File /opt/stack/new/nova/nova/compute/manager.py, line 4735, in _attach_volume 2015-03-27 18:03:07.990 29082 TRACE nova.compute.manager [instance: a2cccacf-2876-4e94-94e0-dbb3fbf51c46] do_check_attach=False, do_driver_attach=True) 2015-03-27 18:03:07.990 29082 TRACE nova.compute.manager [instance: a2cccacf-2876-4e94-94e0-dbb3fbf51c46] File /opt/stack/new/nova/nova/virt/block_device.py, line 48, in wrapped 2015-03-27 18:03:07.990 29082 TRACE nova.compute.manager [instance: a2cccacf-2876-4e94-94e0-dbb3fbf51c46] ret_val = method(obj, context, *args, **kwargs) 2015-03-27 18:03:07.990 29082 TRACE nova.compute.manager [instance: a2cccacf-2876-4e94-94e0-dbb3fbf51c46] File /opt/stack/new/nova/nova/virt/block_device.py, line 260, in attach 2015-03-27 18:03:07.990 29082 TRACE nova.compute.manager [instance: a2cccacf-2876-4e94-94e0-dbb3fbf51c46] connector) 2015-03-27 18:03:07.990 29082 TRACE nova.compute.manager [instance: a2cccacf-2876-4e94-94e0-dbb3fbf51c46] File /usr/local/lib/python2.7/dist-packages/oslo_utils/excutils.py, line 85, in __exit__ 2015-03-27 18:03:07.990 29082 TRACE nova.compute.manager [instance: a2cccacf-2876-4e94-94e0-dbb3fbf51c46] six.reraise(self.type_, self.value, self.tb) 2015-03-27 18:03:07.990 29082 TRACE nova.compute.manager [instance: a2cccacf-2876-4e94-94e0-dbb3fbf51c46] File /opt/stack/new/nova/nova/virt/block_device.py, line 251, in attach 2015-03-27 18:03:07.990 29082 TRACE nova.compute.manager [instance: a2cccacf-2876-4e94-94e0-dbb3fbf51c46] device_type=self['device_type'], encryption=encryption) 2015-03-27 18:03:07.990 29082 TRACE nova.compute.manager [instance: a2cccacf-2876-4e94-94e0-dbb3fbf51c46] File /opt/stack/new/nova/nova/virt/libvirt/driver.py, line 1065, in attach_volume 2015-03-27 18:03:07.990 29082 TRACE nova.compute.manager [instance: a2cccacf-2876-4e94-94e0-dbb3fbf51c46] self._disconnect_volume(connection_info, disk_dev) 2015-03-27 18:03:07.990 29082 TRACE nova.compute.manager [instance: a2cccacf-2876-4e94-94e0-dbb3fbf51c46] File /usr/local/lib/python2.7/dist-packages/oslo_utils/excutils.py, line 85, in __exit__ 2015-03-27 18:03:07.990 29082 TRACE nova.compute.manager [instance: a2cccacf-2876-4e94-94e0-dbb3fbf51c46] six.reraise(self.type_, self.value, self.tb) 2015-03-27 18:03:07.990 29082 TRACE nova.compute.manager [instance: a2cccacf-2876-4e94-94e0-dbb3fbf51c46] File /opt/stack/new/nova/nova/virt/libvirt/driver.py, line 1052, in attach_volume 2015-03-27 18:03:07.990 29082 TRACE nova.compute.manager [instance: a2cccacf-2876-4e94-94e0-dbb3fbf51c46] encryptor.attach_volume(context, **encryption) 2015-03-27 18:03:07.990 29082 TRACE nova.compute.manager [instance: a2cccacf-2876-4e94-94e0-dbb3fbf51c46] File /opt/stack/new/nova/nova/volume/encryptors/cryptsetup.py, line 86, in attach_volume 2015-03-27 18:03:07.990 29082 TRACE nova.compute.manager [instance: a2cccacf-2876-4e94-94e0-dbb3fbf51c46] self._open_volume(passphrase, **kwargs) 2015-03-27 18:03:07.990 29082 TRACE nova.compute.manager [instance: a2cccacf-2876-4e94-94e0-dbb3fbf51c46] File /opt/stack/new/nova/nova/volume/encryptors/cryptsetup.py, line 71, in _open_volume 2015-03-27 18:03:07.990 29082 TRACE nova.compute.manager [instance: a2cccacf-2876-4e94-94e0-dbb3fbf51c46] check_exit_code=True, run_as_root=True) 2015-03-27 18:03:07.990 29082 TRACE nova.compute.manager [instance: a2cccacf-2876-4e94-94e0-dbb3fbf51c46] File /opt/stack/new/nova/nova/utils.py, line 206, in execute 2015-03-27 18:03:07.990 29082 TRACE nova.compute.manager [instance: a2cccacf-2876-4e94-94e0-dbb3fbf51c46] return processutils.execute(*cmd, **kwargs) 2015-03-27 18:03:07.990 29082 TRACE nova.compute.manager [instance: a2cccacf-2876-4e94-94e0-dbb3fbf51c46] File /usr/local/lib/python2.7/dist-packages/oslo_concurrency/processutils.py, line 233, in execute 2015-03-27
[Yahoo-eng-team] [Bug 1439869] [NEW] encrypted iSCSI volume attach fails when iscsi_use_multipath is enabled
Public bug reported: When attempting to attach an encrypted iSCSI volume to an instance with iscsi_use_multipath set to True in nova.conf an error occurs in n-cpu. The devstack system being used had the following nova version: commit ab25f5f34b6ee37e495aa338aeb90b914f622b9d Merge instance termination with update_dns_entries set fails The following error occurs in n-cpu: Stack Trace: 2015-04-02 13:46:22.641 ERROR nova.virt.block_device [req-61f49ff8-b814-42c0-8cf8-ffe7b6a3561c admin admin] [instance: 41d0c192-a1ce-45eb-a5ff-bcb96ec0d8e5] Driver failed to attach volume 4778e71c-a1b5-4d b5-b677-1d8191468e87 at /dev/vdb 2015-04-02 13:46:22.641 TRACE nova.virt.block_device [instance: 41d0c192-a1ce-45eb-a5ff-bcb96ec0d8e5] Traceback (most recent call last): 2015-04-02 13:46:22.641 TRACE nova.virt.block_device [instance: 41d0c192-a1ce-45eb-a5ff-bcb96ec0d8e5] File /opt/stack/nova/nova/virt/block_device.py, line 251, in attach 2015-04-02 13:46:22.641 TRACE nova.virt.block_device [instance: 41d0c192-a1ce-45eb-a5ff-bcb96ec0d8e5] device_type=self['device_type'], encryption=encryption) 2015-04-02 13:46:22.641 TRACE nova.virt.block_device [instance: 41d0c192-a1ce-45eb-a5ff-bcb96ec0d8e5] File /opt/stack/nova/nova/virt/libvirt/driver.py, line 1064, in attach_volume 2015-04-02 13:46:22.641 TRACE nova.virt.block_device [instance: 41d0c192-a1ce-45eb-a5ff-bcb96ec0d8e5] self._disconnect_volume(connection_info, disk_dev) 2015-04-02 13:46:22.641 TRACE nova.virt.block_device [instance: 41d0c192-a1ce-45eb-a5ff-bcb96ec0d8e5] File /usr/local/lib/python2.7/dist-packages/oslo_utils/excutils.py, line 85, in __exit__ 2015-04-02 13:46:22.641 TRACE nova.virt.block_device [instance: 41d0c192-a1ce-45eb-a5ff-bcb96ec0d8e5] six.reraise(self.type_, self.value, self.tb) 2015-04-02 13:46:22.641 TRACE nova.virt.block_device [instance: 41d0c192-a1ce-45eb-a5ff-bcb96ec0d8e5] File /opt/stack/nova/nova/virt/libvirt/driver.py, line 1051, in attach_volume 2015-04-02 13:46:22.641 TRACE nova.virt.block_device [instance: 41d0c192-a1ce-45eb-a5ff-bcb96ec0d8e5] encryptor.attach_volume(context, **encryption) 2015-04-02 13:46:22.641 TRACE nova.virt.block_device [instance: 41d0c192-a1ce-45eb-a5ff-bcb96ec0d8e5] File /opt/stack/nova/nova/volume/encryptors/cryptsetup.py, line 93, in attach_volume 2015-04-02 13:46:22.641 TRACE nova.virt.block_device [instance: 41d0c192-a1ce-45eb-a5ff-bcb96ec0d8e5] self._open_volume(passphrase, **kwargs) 2015-04-02 13:46:22.641 TRACE nova.virt.block_device [instance: 41d0c192-a1ce-45eb-a5ff-bcb96ec0d8e5] File /opt/stack/nova/nova/volume/encryptors/cryptsetup.py, line 78, in _open_volume 2015-04-02 13:46:22.641 TRACE nova.virt.block_device [instance: 41d0c192-a1ce-45eb-a5ff-bcb96ec0d8e5] check_exit_code=True, run_as_root=True) 2015-04-02 13:46:22.641 TRACE nova.virt.block_device [instance: 41d0c192-a1ce-45eb-a5ff-bcb96ec0d8e5] File /opt/stack/nova/nova/utils.py, line 206, in execute 2015-04-02 13:46:22.641 TRACE nova.virt.block_device [instance: 41d0c192-a1ce-45eb-a5ff-bcb96ec0d8e5] return processutils.execute(*cmd, **kwargs) 2015-04-02 13:46:22.641 TRACE nova.virt.block_device [instance: 41d0c192-a1ce-45eb-a5ff-bcb96ec0d8e5] File /usr/local/lib/python2.7/dist-packages/oslo_concurrency/processutils.py, line 233, in execute 2015-04-02 13:46:22.641 TRACE nova.virt.block_device [instance: 41d0c192-a1ce-45eb-a5ff-bcb96ec0d8e5] cmd=sanitized_cmd) 2015-04-02 13:46:22.641 TRACE nova.virt.block_device [instance: 41d0c192-a1ce-45eb-a5ff-bcb96ec0d8e5] ProcessExecutionError: Unexpected error while running command. 2015-04-02 13:46:22.641 TRACE nova.virt.block_device [instance: 41d0c192-a1ce-45eb-a5ff-bcb96ec0d8e5] Command: sudo nova-rootwrap /etc/nova/rootwrap.conf cryptsetup create --key-file=- 36000eb37601bcf0200 00036c /dev/mapper/36000eb37601bcf02036c 2015-04-02 13:46:22.641 TRACE nova.virt.block_device [instance: 41d0c192-a1ce-45eb-a5ff-bcb96ec0d8e5] Exit code: 1 2015-04-02 13:46:22.641 TRACE nova.virt.block_device [instance: 41d0c192-a1ce-45eb-a5ff-bcb96ec0d8e5] Stdout: u'' 2015-04-02 13:46:22.641 TRACE nova.virt.block_device [instance: 41d0c192-a1ce-45eb-a5ff-bcb96ec0d8e5] Stderr: u'' 2015-04-02 13:46:22.641 TRACE nova.virt.block_device [instance: 41d0c192-a1ce-45eb-a5ff-bcb96ec0d8e5] multipath-tools was installed iscsi_use_multipath = True was set under the [libvirt] entry in nova.conf To reproduce: install multipath-tools set iscsi_use_multipath to True in nova.conf under the [libvirt] section. create an encrypted iSCSI volume and attempt to attach it to an instance (I was using CryptsetupEncryptor). The above error will occur in n-cpu. ** Affects: nova Importance: Undecided Status: New -- 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/1439869 Title: encrypted iSCSI volume
