[SMAPIv3] xe vdi-create leaves VDI half-created on error in Volume.set for vdi-type=user
#5530
Assignees
Comments
ydirson
added a commit
to xcp-ng/xcp-ng-xapi-storage
that referenced
this issue
Mar 26, 2024
Note that if Volume.set were not implemented yet (or indeed cannot complete and returns an error), we face xapi-project/xen-api#5530: if the Volume.set call fails (to add the vdi-type=user custom-key record), then the VDI object is not created (though, as this happens after Volume.create, the zvol and DB entries were indeed created and there suppression was not requested by SMAPI after the error). But since all the VDI information that count are here, "xe sr-scan" will bring those VDI to life (after implementation of SR.ls). Originally-by: Matias Ezequiel Vara Larsen <[email protected]> Signed-off-by: Yann Dirson <[email protected]>
ydirson
added a commit
to xcp-ng/xcp-ng-xapi-storage
that referenced
this issue
Apr 2, 2024
We create sparse volumes, making the SR a thin-provisioning one. Cache as vsize the actual size created by the zfs command (which in zfs-2.1 unlike in zfs-0.8 does round up requested size to be acceptable). Note that if Volume.set were not implemented yet (or indeed cannot complete and returns an error), we face xapi-project/xen-api#5530: if the Volume.set call fails (to add the vdi-type=user custom-key record), then the VDI object is not created (though, as this happens after Volume.create, the zvol and DB entries were indeed created and there suppression was not requested by SMAPI after the error). But since all the VDI information that count are here, "xe sr-scan" will bring those VDI to life (after implementation of SR.ls). Originally-by: Matias Ezequiel Vara Larsen <[email protected]> Signed-off-by: Yann Dirson <[email protected]>
ydirson
added a commit
to xcp-ng/xcp-ng-xapi-storage
that referenced
this issue
Apr 4, 2024
We create sparse volumes, making the SR a thin-provisioning one. Cache as vsize the actual size created by the zfs command (which in zfs-2.1 unlike in zfs-0.8 does round up requested size to be acceptable). Note that if Volume.set were not implemented yet (or indeed cannot complete and returns an error), we face xapi-project/xen-api#5530: if the Volume.set call fails (to add the vdi-type=user custom-key record), then the VDI object is not created (though, as this happens after Volume.create, the zvol and DB entries were indeed created and there suppression was not requested by SMAPI after the error). But since all the VDI information that count are here, "xe sr-scan" will bring those VDI to life (after implementation of SR.ls). Originally-by: Matias Ezequiel Vara Larsen <[email protected]> Signed-off-by: Yann Dirson <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
On SMAPIv3
xe vdi-createmakes one call toVolume.createthen wants set avdi-typefield usingVolume.set.When this second call fails, the VDI creation is failed, but the created volume is left untouched, to be picked up by a later
sr-scanand appear as a VDI as if the call had succeeded.It looks like objects created should be destroyed in case of errors?
The text was updated successfully, but these errors were encountered: