README.rst 6.1 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184
  1. Project Coriolis
  2. ================
  3. *Cloud Migration as a Service*
  4. Migrating existing workloads between clouds is a necessity for a large number
  5. of use cases, especially for user moving from traditional virtualization
  6. technologies like VMware vSphere or Microsoft System Center VMM to Azure /
  7. AzureStack, OpenStack, Amazon AWS or Google Cloud. Furthermore, cloud to cloud
  8. migrations, like AWS to Azure are also a common requirement.
  9. Project Coriolis(R) addresses exactly those requirements, in particular migrating
  10. Linux (Ubuntu, Red Hat / CentOS, SUSE, Debian, Fedora) and Windows virtual
  11. machine, templates, storage and networking configurations.
  12. There are some tricky scenarios where Coriolis excels: to begin with, virtual
  13. machines need to be moved between different hypervisors, which means including
  14. new operating system drivers and tools, for example cloud-init / cloudbase-init
  15. in the OpenStack use case, LIS kernel modules on Hyper-V and Azure and so on.
  16. The project is largely using Oslo libraries with an architecture meant to be
  17. familiar for devops used to OpenStack, as shown in the diagram below.
  18. A clear separation between stateless microservices and proper usage of queues
  19. allows scalability and fault tolerance from the start. For PoCs and small
  20. environments, all components can be deployed on a single host / VM / container.
  21. Authentication and endpoint discovery is based on Keystone (in the typical
  22. OpenStack way), which means that passing an X-Auth-Token header from an
  23. existing Keystone session allows an easy integration with other components,
  24. e.g. in Horizon's console.
  25. The same token is passed to other components along the pipeline, which also
  26. implies that importing virtual machines and other resources to the same
  27. OpenStack infrastructure doesn't require further authentication.
  28. Authentication to external clouds (Azure, AWS, etc) or virtualisation solutions
  29. (vSphere, SCVMM, etc) in order to export virtual resources requires credentials
  30. that can be saved in Barbican, thus avoiding the need to pass secrets directly
  31. to the API.
  32. Cloud resources that can be migrated:
  33. - Virtual machines
  34. - Virtual Machine templates
  35. - Storage
  36. - Network configurations
  37. VM disks are converted to the desired target format and drivers / tools are
  38. automatically added where appropriate during the process (e. cloud-init on
  39. OpenStack, KVM Windows VirtIO drivers, etc).
  40. The migration jobs are split in import / export tasks with a scheduler taking
  41. care of choosing a worker node where this can be executed. Each task contains
  42. progress update info that the client can poll to follow the progress of the
  43. operations. Tasks can be relatively long running, depending on the storage
  44. size, so proper status reporting was included in the design from the start.
  45. .. image:: https://cloudbase.it/wp-content/uploads/2016/02/coriolis-diagram.svg
  46. Keystone configuration
  47. ----------------------
  48. Here's an example Keystone service and endpoints configuration:
  49. ::
  50. openstack service create --name coriolis --description "Cloud Migration as a Service" migration
  51. ENDPOINT_URL="http://hostname:7667/v1/%(tenant_id)s"
  52. openstack endpoint create --region RegionOne migration `
  53. --publicurl $ENDPOINT_URL `
  54. --internalurl $ENDPOINT_URL `
  55. --adminurl $ENDPOINT_URL
  56. openstack user create --password-prompt coriolis
  57. openstack role add --project service --user coriolis admin
  58. API
  59. ---
  60. The API is also very straightforward, here's a complete example available on
  61. Postman: https://api.postman.com/collections/2414861-766ace3d-b46c-4510-bbaf-e1f001a8be75?access_key=PMAT-01GJTF9HV7MY7YMHZW7Q79N5V2
  62. Create a migration job:
  63. POST http://server:7667/v1/%project_id/migrations
  64. Example request body:
  65. ::
  66. {
  67. "migration": {
  68. "origin": {
  69. "type": "vmware_vsphere",
  70. "connection_info": {
  71. "secret_id": "ebe69d82-da6f-451e-a0f6-3551d0f7ef85"
  72. }
  73. },
  74. "destination": {
  75. "type": "openstack",
  76. "target_environment": {
  77. "flavor_name": "m1.small",
  78. "network_map": {
  79. "VM Network": "private",
  80. "VM Network Local": "public"
  81. }
  82. }
  83. },
  84. "instances": ["CentOS 7", "RHEL 7.2", "Ubuntu 14.04", "WS 2012 R2"]
  85. }
  86. }
  87. Note: here's an example secret stored in Barbican with vSphere connection info:
  88. ::
  89. {
  90. "host": "10.0.0.10",
  91. "username": "user@vsphere.local",
  92. "password": "Password",
  93. "allow_untrusted": true
  94. }
  95. List migrations:
  96. GET http://server:7667/v1/%(project_id)s/migrations
  97. GET http://server:7667/v1/%(project_id)s/migrations/detail
  98. Get a migration job info:
  99. GET http://server:7667/v1/%(project_id)s/migrations/%(migration_id)s
  100. Cancel a migration job:
  101. This API allows the user to interrupt any running job.
  102. POST http://server:7667/v1/%(project_id)s/migrations/%(migration_id)s/action
  103. Request body:
  104. ::
  105. { "cancel": null }
  106. Delete a migration job:
  107. DELETE http://server:7667/v1/%(project_id)s/migrations/%(migration_id)s
  108. Note: only completed, failed or cancelled jobs can be deleted.
  109. The following Coriolis APIs support pagination:
  110. * transfers
  111. * transfer executions
  112. * deployments
  113. * endpoint instances (only marker and limit parameters)
  114. Pagination parameters:
  115. * ``sort_key`` - sort key, repeatable. `created_at` and `id` are used by default.
  116. * ``sort_dir`` - sort direction, repeatable. `asc` or `desc` (default).
  117. * ``marker`` - the last seen ID, omitted from the results.
  118. * ``limit`` - the maximum number of records to retrieve.
  119. Example:
  120. GET http://server:7667/v1/transfers?marker=a7061715-e56c-470c-a6ac-80bb02f1f198&limit=2&sort_key=id&sort_dir=asc
  121. API Documentation
  122. -----------------
  123. To build the API documentation, while in the repository root directory, run:
  124. ::
  125. sphinx-build -W -b html coriolis/api-refs/source $DOCS_PATH
  126. API bindings
  127. ------------
  128. A reference Python client library implementation is available at:
  129. https://github.com/cloudbase/python-coriolisclient
  130. Web UI
  131. ------
  132. The official Web-based GUI for Coriolis is available at:
  133. https://github.com/cloudbase/coriolis-web