Page History

Bug Reference

tbd

Branch

tbd

Introduction

Users want to be able to upgrade their datastore in vSphere and migrate existing VMs and data to the new datastore. For this they need to migrate stopped VMs and detached disks which is not possible at the moment. VMware does provide this functionality. The intention of this FS is to leverage VMware's functionality via existing APIs.

References

• N/A

Glossary

Feature Specifications

• A stopped VM will be able to be migrated to an other datastore in VMware.

...

Performance for this feature is dependent upon the underlying resources such as vSphere and ESXi hosts, network bandwidth and datastore speed.

Use Cases

Migrating an offline VM or volume is now a copy from primary to secondary and back to the new primary. This can be time consuming and requires large job timeouts. This can be cut in about half by letting the hypervisor perform the migration directly.

Architecture and Design Description

• For offline VM migration, the existing API will be used. A method finalizeMigration is created that returns a set of commands to execute on the resource to perform the migration. For VMware this returns the needed commands. As default, a null will be returned indicating the hypervisor type cannot perform this function. (Storage migration is to be used in those cases.)
• For detached volume migration, the VMware storage migration strategy can return the priority of HYPERVISOR. For VMware this would mean that the copyAsync call as implemented by storage migration strategies would actually do a full migration instead of a copy. The subsequent delete is mute and will succeed as not needed.

Web Services APIs

No API will be changed to implement this functionality. The semantics of migrateVirtualMachine and migrateVolume will be changed in that these will now yield results on VMware, as opposed to yielding errors.

UI flow

No UI change will be implemented

...

No usage impact is foreseen.

Appendix

Appendix A:

Appendix B: