Multiple instances can be booted from the same volume

[Rohit Karajgi]

Nova allows multiple instances to be booted from the same volume (Cinder environment)

1. Create a bootable volume, say 'vol1'
2. Try to boot two (or more) instances from 'vol1'

Expected result:

Only 1 instance should be created, and booted from the volume in Active state
The other instance should not get created, and the API should return 409 Conflict for their requests.

Actual result:

* Both the instances get booted and become Active.
* It's possible to login to the console of both the instance - In this case it's possible to write data to the file system of instance1 and not in instance2, which gives a Read Only File System error.

Commands snip:
-------------------

rohit@precise$ cinder list
+--------------------------------------+--------+---------------------------+------+-------------+----------+--------------------------------------+
| ID | Status | Display Name | Size | Volume Type | Bootable | Attached to |
+--------------------------------------+--------+---------------------------+------+-------------+----------+--------------------------------------+
| 7408008f-c65d-4f96-9ee6-76373b4bad3e | in-use | maverick_bootable_vol-001 | 1 | None | true | b314bbc5-e85e-48ca-9b09-b9ab2513f4f2 |
+--------------------------------------+--------+---------------------------+------+-------------+----------+--------------------------------------+
rohit@precise$
rohit@precise$ nova list
+--------------------------------------+----------------+--------+------------------+
| ID | Name | Status | Networks |
+--------------------------------------+----------------+--------+------------------+
| 0deb9d79-f4de-442d-a170-50f5af01aefb | test_instance | ACTIVE | private=10.0.0.4 |
| b314bbc5-e85e-48ca-9b09-b9ab2513f4f2 | test_instance2 | ACTIVE | private=10.0.0.3 |
+--------------------------------------+----------------+--------+------------------+
rohit@precise$ virsh list
 Id Name State
----------------------------------
  9 instance-0000000d running
 10 instance-0000000e running

The libvirt.xml for both instances contain the same device path for the block device:

rohit@precise$ grep iscsi-iqn instance-0000000d/libvirt.xml
      <source dev="/dev/disk/by-path/ip-10.2.3.100:3260-iscsi-iqn.2010-10.org.openstack:volume-7408008f-c65d-4f96-9ee6-76373b4bad3e-lun-1"/>
rohit@precise$ grep iscsi-iqn instance-0000000e/libvirt.xml
      <source dev="/dev/disk/by-path/ip-10.2.3.100:3260-iscsi-iqn.2010-10.org.openstack:volume-7408008f-c65d-4f96-9ee6-76373b4bad3e-lun-1"/>

[Vish Ishaya (vishvananda)]

It looks like we should be calling reserve volume when we parse the block_device_mapping and failing if we attempt to boot twice.

[Rohit Karajgi (rohitk)]

Changed project to Cinder as this is a timing synchronization issue that should be handled at the Volume manager level.

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.openstack.org/18717

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/18717
Committed: http://github.com/openstack/cinder/commit/2331d3336a6adf4fc13a3b187e91a5d1b1f7c723
Submitter: Jenkins
Branch: master

commit 2331d3336a6adf4fc13a3b187e91a5d1b1f7c723
Author: Rohit Karajgi <email address hidden>
Date: Fri Dec 28 04:58:46 2012 -0800

    Adds synchronization to attach volume.

    This patch adds the following changes:
    1. Move db update for volume status during attach to volume.manager
    2. Add lock synchronization to volume attach operation
    3. Related unit tests

    Fixes Bug 1087253
    Change-Id: I15242766bf4cfa4da67789c485fdf6886983eb45