Steps to recreate:
1. Create instance based on a flavor that includes swap on a Xen-based openstack installation.
2. See that in the database the instance has a BDM for swap at /dev/xvdb, but nothing for /dev/xvdc.
3. See that on the instance it has swap at /dev/xvdc, but nothing at /dev/xvdb.
4. Try to attach a volume at /dev/xvdb, but fail because the database has swap at /dev/xvdb.
5. Try to attach a volume at /dev/xvdc, but fail because the instance has swap at /dev/xvdc.
The below explanation is relative to a Nova Git commit as of today (and therefor won't changed).
A BDM for swap, based on the flavor, is created in nova/compute/api.py (pseudo call-stack: [1][2][3][4]), which is incorrectly (based on Xen and historical behavior) assigned to /dev/xvdb (pseudo call-stack: [5][6][7][8][9][10][11]), of which specifically get_next_device_name() insures that /dev/xvdc, the proper device name, will never be used [12].
The swap is actually created in nova/virt/xenapi/vmops.py (pseudo call-stack: [13][14][15]), again based on flavor, but with no regard for the previously created bdm for swap.
Steps to recreate:
1. Create instance based on a flavor that includes swap on a Xen-based openstack installation.
2. See that in the database the instance has a BDM for swap at /dev/xvdb, but nothing for /dev/xvdc.
3. See that on the instance it has swap at /dev/xvdc, but nothing at /dev/xvdb.
4. Try to attach a volume at /dev/xvdb, but fail because the database has swap at /dev/xvdb.
5. Try to attach a volume at /dev/xvdc, but fail because the instance has swap at /dev/xvdc.
The above problem was introduced with http:// git.openstack. org/cgit/ openstack/ nova/commit/ ?id=7f8128f87f5 a2fa93c857295fb 7e4163986eda25.
The below explanation is relative to a Nova Git commit as of today (and therefor won't changed).
A BDM for swap, based on the flavor, is created in nova/compute/api.py (pseudo call-stack: [1][2][3][4]), which is incorrectly (based on Xen and historical behavior) assigned to /dev/xvdb (pseudo call-stack: [5][6][ 7][8][9] [10][11] ), of which specifically get_next_ device_ name() insures that /dev/xvdc, the proper device name, will never be used [12].
[1] https:/ /github. com/openstack/ nova/blob/ bd3b5a62/ nova/compute/ api.py# L775 /github. com/openstack/ nova/blob/ bd3b5a62/ nova/compute/ api.py# L829 /github. com/openstack/ nova/blob/ bd3b5a62/ nova/compute/ api.py# L750 /github. com/openstack/ nova/blob/ bd3b5a62/ nova/compute/ api.py# L761 /github. com/openstack/ nova/blob/ bd3b5a62/ nova/compute/ manager. py#L1663 /github. com/openstack/ nova/blob/ bd3b5a62/ nova/compute/ manager. py#L1705 /github. com/openstack/ nova/blob/ bd3b5a62/ nova/compute/ manager. py#L1642 /github. com/openstack/ nova/blob/ bd3b5a62/ nova/compute/ manager. py#L1650 /github. com/openstack/ nova/blob/ bd3b5a62/ nova/compute/ utils.py# L107 /github. com/openstack/ nova/blob/ bd3b5a62/ nova/compute/ utils.py# L120 /github. com/openstack/ nova/blob/ bd3b5a62/ nova/compute/ utils.py# L127 /github. com/openstack/ nova/blob/ bd3b5a62/ nova/compute/ utils.py# L173
[2] https:/
[3] https:/
[4] https:/
[5] https:/
[6] https:/
[7] https:/
[8] https:/
[9] https:/
[10] https:/
[11] https:/
[12] https:/
The swap is actually created in nova/virt/ xenapi/ vmops.py (pseudo call-stack: [13][14][15]), again based on flavor, but with no regard for the previously created bdm for swap.
[13] https:/ /github. com/openstack/ nova/blob/ bd3b5a62/ nova/virt/ xenapi/ vmops.py# L678 /github. com/openstack/ nova/blob/ bd3b5a62/ nova/virt/ xenapi/ vmops.py# L741 /github. com/openstack/ nova/blob/ bd3b5a62/ nova/virt/ xenapi/ vmops.py# L89
[14] https:/
[15] https:/