Hide Forgot
Ensure active, unopened logical volumes are refreshed fully before use. This is an additional check required to avoid any potential corruption introduced by volumes being erroneously activated across multiple HSMs while being modified by the SPM. Until now there have been two bugs that could lead to this situation. BZ#962549 - Volumes are not deactivated correctly when powering down a guest. BZ#1009812 - All logical volumes are activated at boot time. The suggested approach of using lvchange --refresh to do this has produced mix results and needs to be investigated further both up and downstream before being used.
This change is a nice to have feature, adding a second layer of protection, if a volume remain active because of a bug in the volume handling code. To implement this, we must keep state for each volume activated. On the first activation, we can check if the volume is already active, and refresh it instead. On later activation requests, this volume should not be refreshed again. Otherwise, we may refresh volumes multiple times, which can be too expensive with big volume chains. It looks like we do not keep such state for activated volumes curently, so we cannot fix this. I suggest to close this currently as CANTFIX.
(In reply to Lee Yarwood from comment #0) > Ensure active, unopened logical volumes are refreshed fully before use. > > This is an additional check required to avoid any potential corruption > introduced by volumes being erroneously activated across multiple HSMs while > being modified by the SPM. > > Until now there have been two bugs that could lead to this situation. > > BZ#962549 - Volumes are not deactivated correctly when powering down a guest. > BZ#1009812 - All logical volumes are activated at boot time. > > The suggested approach of using lvchange --refresh to do this has produced > mix results and needs to be investigated further both up and downstream > before being used. Both bug 962549 and bug 1009812 are fixed in currrent releases. In particular, the case where volumes are found active when vdsm is starting is handled by the fix for bug 1009812. The only case which is not handled by that fix is volumes not activated when it should be when a vm is shutdown, and then accessed again, after SPM changed the volume.
This was not removed by mistake - we are not going to handle this in 3.4.0.
The proposed solution will cause performance issues and does not seem worth the trouble. If we ever hit a situation where this happens again we will also be able to diagnose where in the flow we could put such a check without hurting performance in the positive flows. closing for now.