| 2016-04-04 16:59:18 |
Lucian Petrut |
bug |
|
|
added bug |
| 2016-04-04 17:01:03 |
Lucian Petrut |
bug task added |
|
nova |
|
| 2016-04-04 17:01:13 |
Lucian Petrut |
tags |
|
driver hyper-v |
|
| 2016-04-04 20:16:09 |
Matt Riedemann |
tags |
driver hyper-v |
driver hyper-v migrate |
|
| 2016-04-04 20:16:22 |
Matt Riedemann |
nova: status |
New |
Confirmed |
|
| 2016-04-04 20:16:24 |
Matt Riedemann |
compute-hyperv: status |
New |
Confirmed |
|
| 2016-04-04 20:16:27 |
Matt Riedemann |
nova: importance |
Undecided |
Medium |
|
| 2016-04-12 14:49:26 |
OpenStack Infra |
compute-hyperv: status |
Confirmed |
Fix Released |
|
| 2016-04-18 06:47:32 |
OpenStack Infra |
tags |
driver hyper-v migrate |
driver hyper-v in-stable-mitaka migrate |
|
| 2016-05-27 13:53:10 |
Lucian Petrut |
summary |
Hyper-V: cold migrations cannot handle shared storage |
Hyper-V: migrations cannot handle shared storage |
|
| 2016-05-27 13:53:50 |
Lucian Petrut |
description |
At the moment, if the destination host is other than the source host, we attempt to move the instance files without checking if
shared storage is being used. |
At the moment, if the destination host is other than the source host, we attempt to move the instance files without checking if shared storage is being used.
Cold migrations as well as live migrations are affected by this issue. |
|
| 2016-06-28 15:38:52 |
Lucian Petrut |
summary |
Hyper-V: migrations cannot handle shared storage |
The Hyper-V driver cannot handle shared storage |
|
| 2016-06-28 16:05:01 |
Lucian Petrut |
description |
At the moment, if the destination host is other than the source host, we attempt to move the instance files without checking if shared storage is being used.
Cold migrations as well as live migrations are affected by this issue. |
The Hyper-V driver has a few issues when attempting to use shared storage for the instance files.
Migration issues
----------------
In case of migrations, we attempt to move the instance files without checking whether shared storage is used. Note that the block_migration flag is completely ignored.
After a live migration is performed, we always try to delete the instance files. Also, if the migration fails, the destination node is not cleaned up, as the HyperVLiveMigrateData object is not used at the moment.
Image/path handling issues
--------------------------
The image cache operation uses thread locks, for which reason it is prone to race conditions when using shared storage. Switching to file locks would solve this issue.
Also, the image cache cleanup worker can cause issues in this case, as it only checks for local instances and file timestamps (which are updated by this periodic task). For this reason, it may try to delete base images used by other nodes. Simply updating the timestamp of the image file whenever we want to 'fetch' it would avoid this issue.
Using UNC paths for the instance path does not work either. The driver will fail to fetch the available space. Also, it will not build the remote instance path properly when trying to move files during migrations. |
|
| 2016-06-28 16:10:23 |
OpenStack Infra |
nova: status |
Confirmed |
In Progress |
|
| 2016-06-28 16:10:23 |
OpenStack Infra |
nova: assignee |
|
Lucian Petrut (petrutlucian94) |
|
| 2016-08-02 13:34:00 |
Matt Riedemann |
nova: importance |
Medium |
Wishlist |
|
| 2016-09-22 12:53:20 |
Lucian Petrut |
description |
The Hyper-V driver has a few issues when attempting to use shared storage for the instance files.
Migration issues
----------------
In case of migrations, we attempt to move the instance files without checking whether shared storage is used. Note that the block_migration flag is completely ignored.
After a live migration is performed, we always try to delete the instance files. Also, if the migration fails, the destination node is not cleaned up, as the HyperVLiveMigrateData object is not used at the moment.
Image/path handling issues
--------------------------
The image cache operation uses thread locks, for which reason it is prone to race conditions when using shared storage. Switching to file locks would solve this issue.
Also, the image cache cleanup worker can cause issues in this case, as it only checks for local instances and file timestamps (which are updated by this periodic task). For this reason, it may try to delete base images used by other nodes. Simply updating the timestamp of the image file whenever we want to 'fetch' it would avoid this issue.
Using UNC paths for the instance path does not work either. The driver will fail to fetch the available space. Also, it will not build the remote instance path properly when trying to move files during migrations. |
The Hyper-V driver has a few issues when attempting to use shared storage for the instance files.
Migration issues
----------------
In case of migrations, we attempt to move the instance files without checking whether shared storage is used. Note that the block_migration flag is completely ignored.
During live migrations, we let Hyper-V automatically detect whether shared storage is used or not. This seems to be troublesome when instance files reside on CSVs.
After a live migration is performed, we always try to delete the instance files. Also, if the migration fails, the destination node is not cleaned up, as the HyperVLiveMigrateData object is not used at the moment.
Image/path handling issues
--------------------------
The image cache operation uses thread locks, for which reason it is prone to race conditions when using shared storage. Switching to file locks would solve this issue.
Also, the image cache cleanup worker can cause issues in this case, as it only checks for local instances and file timestamps (which are updated by this periodic task). For this reason, it may try to delete base images used by other nodes. Simply updating the timestamp of the image file whenever we want to 'fetch' it would avoid this issue.
Using UNC paths for the instance path does not work either. The driver will fail to fetch the available space. Also, it will not build the remote instance path properly when trying to move files during migrations. |
|
| 2016-09-23 14:06:13 |
Lucian Petrut |
description |
The Hyper-V driver has a few issues when attempting to use shared storage for the instance files.
Migration issues
----------------
In case of migrations, we attempt to move the instance files without checking whether shared storage is used. Note that the block_migration flag is completely ignored.
During live migrations, we let Hyper-V automatically detect whether shared storage is used or not. This seems to be troublesome when instance files reside on CSVs.
After a live migration is performed, we always try to delete the instance files. Also, if the migration fails, the destination node is not cleaned up, as the HyperVLiveMigrateData object is not used at the moment.
Image/path handling issues
--------------------------
The image cache operation uses thread locks, for which reason it is prone to race conditions when using shared storage. Switching to file locks would solve this issue.
Also, the image cache cleanup worker can cause issues in this case, as it only checks for local instances and file timestamps (which are updated by this periodic task). For this reason, it may try to delete base images used by other nodes. Simply updating the timestamp of the image file whenever we want to 'fetch' it would avoid this issue.
Using UNC paths for the instance path does not work either. The driver will fail to fetch the available space. Also, it will not build the remote instance path properly when trying to move files during migrations. |
The Hyper-V driver has a few issues when attempting to use shared storage for the instance files.
Migration issues
----------------
In case of migrations, we attempt to move the instance files without checking whether shared storage is used. Note that the block_migration flag is completely ignored.
During live migrations, we let Hyper-V automatically detect whether shared storage is used or not. This seems to be troublesome when instance files reside on CSVs.
After a live migration is performed, we always try to delete the instance files. Also, if the migration fails, the destination node is not cleaned up, as the HyperVLiveMigrateData object is not used at the moment.
Image/path handling issues
--------------------------
The image cache operation uses thread locks, for which reason it is prone to race conditions when using shared storage. Switching to file locks would solve this issue.
Using UNC paths for the instance path does not work either. The driver will fail to fetch the available space. Also, it will not build the remote instance path properly when trying to move files during migrations. |
|
| 2016-11-24 02:14:58 |
OpenStack Infra |
nova: status |
In Progress |
Fix Released |
|
| 2016-12-09 16:17:07 |
Matt Riedemann |
nova: importance |
Wishlist |
Medium |
|
| 2016-12-12 06:27:06 |
OpenStack Infra |
tags |
driver hyper-v in-stable-mitaka migrate |
driver hyper-v in-stable-mitaka in-stable-newton migrate |
|
