Jump to: navigation, search

Difference between revisions of "ISCSISupportXenAPI"

(talk)
 
m (Text replace - "NovaSpec" to "NovaSpec")
 
(5 intermediate revisions by 3 users not shown)
Line 1: Line 1:
__NOTOC__
+
 
* '''Launchpad Entry''': [[NovaSpec]]:bexar-iSCSI-support-xenserver
+
<!-- ## page was renamed from iSCSISupportForXenServer -->
 +
* '''Launchpad Entry''': NovaSpec:bexar-iscsi-support-xenapi
 
* '''Created''': 16 November 2010
 
* '''Created''': 16 November 2010
 
* '''Contributors''': Armando Migliaccio
 
* '''Contributors''': Armando Migliaccio
  
 
== Summary ==
 
== Summary ==
 +
This feature will enable XenServer (and XCP) hosted VMs to see iSCSI storage and attach/detach EBS-like volumes to/from them. This specification covers Nova support for XenServer and XCP through XenAPI. Note that this does not imply support for other Xen-based platforms such as those shipped with RHEL 5 or SUSE.
  
== Release Note ==
+
Glossary:
  
This section should include a paragraph describing the end-user impact of this change.  It is meant to be included in the release notes of the first release in which it is implemented. (Not all of these will actually be included in the release notes, at the release manager's discretion; but writing them is a useful exercise.)
+
* XenServer: Commercial, supported product from Citrix
 +
* Xen Cloud Platform (XCP): Open-source equivalent of XenServer (and the development project for the toolstack). Everything said about XenServer below applies equally to XCP
 +
* XenAPI: The management API exposed by XenServer and XCP
 +
* xapi: The primary daemon on XenServer and Xen Cloud Platform; the one that exposes the XenAPI
  
It is mandatory.
+
== Release Note ==
 +
This spec will provide iSCSI back-end storage for XenServer hosted virtual machines via XenAPI.
  
 
== Rationale ==
 
== Rationale ==
 +
Currently commands like euca-attach-volume/euca-detach-volume have no effect on XenServer hosted virtual machines. Volumes can be created/destroyed on AoE/iSCSI storage, but there is lack of support in the XenAPI abstraction layer available in Nova today. This spec plans to fix that.
  
 
== User stories ==
 
== User stories ==
 +
A user has Nova running on a XenServer. He/She wants his/her data to persist once the VM is terminated. He can use the euca-create-volume/euca-attach-volume/euca-detach-volume set of commands to make this possible.
  
 
== Assumptions ==
 
== Assumptions ==
 +
The changes provided with this blueprint will obviosuly work only with the iSCSI driver for nova-volume
  
 
== Design ==
 
== Design ==
 
+
Basically, the work that Ewan has done for euca-run-instances/euca-terminate-instances need to be done to enable the volume related API commands.
You can have subsections that better describe specific parts of the issue.
 
  
 
== Implementation ==
 
== Implementation ==
 
+
A few files (mainly in the virt directory) need to be updated, and the changes should follow a similar pattern of what Ewan already did for other VM related commands. During the implementation there might be necessity to introduce some refactoring to improve readability and maintainability of the xenapi support.
This section should describe a plan of action (the "how") to implement the changes discussed. Could include subsections like:
 
  
 
=== UI Changes ===
 
=== UI Changes ===
 
+
no changes, other than the euca-attach-volume and euca-detach-volume now respond correctly when the underlying hypervisor is XS/XCP
Should cover changes required to the UI, or specific UI that is required to implement this
 
  
 
=== Code Changes ===
 
=== Code Changes ===
 
+
Two principal methods have been introduced to XenAPIConnection: attach_volume and detach_volume. Many more utility functions have been added to handle XenAPI specifics and to improve reusability when handling VBDs, VDIs, SRs, etc.
Code changes should include an overview of what needs to change, and in some cases even the specific details.
 
  
 
=== Migration ===
 
=== Migration ===
 
+
No data migration planned at this stage. It is necessary to add a few fields to the iscsitarget table (like iscsi target host ip and iscsi iqn) and modify the iscsi driver to set them. This is because the iscsi driver is not general enough to handle other hypervisors' needs. In the case of XenAPI the iscsi initiator is XenServer/XCP running (most likely) on a host different from compute. Even with this changes there should not be any data migration required
Include:
 
* data migration, if any
 
* redirects from old URLs to new ones, if any
 
* how users will be pointed to the new way of doing things, if necessary.
 
  
 
== Test/Demo Plan ==
 
== Test/Demo Plan ==
 
+
Unit tests have been introduced as well as a mocking framework for XenAPI. Basic tests have been added and a lot more must be implemented
This need not be added or completed until the specification is nearing beta.
 
  
 
== Unresolved issues ==
 
== Unresolved issues ==
 +
As mentioned above, the following work can done:
  
This should highlight any issues that should be addressed in further specifications, and not problems with the specification itself; since any specification with problems cannot be approved.
+
* Extension to iscsi table and changes to iscsi driver
 +
* More unit tests
 +
* Write a new iscsi driver to handle storage using XenAPI/SM (Storage Manager) and more advanced iSCSI systems like filers etc.
  
 
== BoF agenda and discussion ==
 
== BoF agenda and discussion ==
 
+
[TBD] Use this section to take notes during the BoF; if you keep it in the approved spec, use it for summarising what was discussed and note any options that were rejected.
Use this section to take notes during the BoF; if you keep it in the approved spec, use it for summarising what was discussed and note any options that were rejected.
 
  
 
----
 
----
 
[[Category:Spec]]
 
[[Category:Spec]]

Latest revision as of 23:31, 17 February 2013

  • Launchpad Entry: NovaSpec:bexar-iscsi-support-xenapi
  • Created: 16 November 2010
  • Contributors: Armando Migliaccio

Summary

This feature will enable XenServer (and XCP) hosted VMs to see iSCSI storage and attach/detach EBS-like volumes to/from them. This specification covers Nova support for XenServer and XCP through XenAPI. Note that this does not imply support for other Xen-based platforms such as those shipped with RHEL 5 or SUSE.

Glossary:

  • XenServer: Commercial, supported product from Citrix
  • Xen Cloud Platform (XCP): Open-source equivalent of XenServer (and the development project for the toolstack). Everything said about XenServer below applies equally to XCP
  • XenAPI: The management API exposed by XenServer and XCP
  • xapi: The primary daemon on XenServer and Xen Cloud Platform; the one that exposes the XenAPI

Release Note

This spec will provide iSCSI back-end storage for XenServer hosted virtual machines via XenAPI.

Rationale

Currently commands like euca-attach-volume/euca-detach-volume have no effect on XenServer hosted virtual machines. Volumes can be created/destroyed on AoE/iSCSI storage, but there is lack of support in the XenAPI abstraction layer available in Nova today. This spec plans to fix that.

User stories

A user has Nova running on a XenServer. He/She wants his/her data to persist once the VM is terminated. He can use the euca-create-volume/euca-attach-volume/euca-detach-volume set of commands to make this possible.

Assumptions

The changes provided with this blueprint will obviosuly work only with the iSCSI driver for nova-volume

Design

Basically, the work that Ewan has done for euca-run-instances/euca-terminate-instances need to be done to enable the volume related API commands.

Implementation

A few files (mainly in the virt directory) need to be updated, and the changes should follow a similar pattern of what Ewan already did for other VM related commands. During the implementation there might be necessity to introduce some refactoring to improve readability and maintainability of the xenapi support.

UI Changes

no changes, other than the euca-attach-volume and euca-detach-volume now respond correctly when the underlying hypervisor is XS/XCP

Code Changes

Two principal methods have been introduced to XenAPIConnection: attach_volume and detach_volume. Many more utility functions have been added to handle XenAPI specifics and to improve reusability when handling VBDs, VDIs, SRs, etc.

Migration

No data migration planned at this stage. It is necessary to add a few fields to the iscsitarget table (like iscsi target host ip and iscsi iqn) and modify the iscsi driver to set them. This is because the iscsi driver is not general enough to handle other hypervisors' needs. In the case of XenAPI the iscsi initiator is XenServer/XCP running (most likely) on a host different from compute. Even with this changes there should not be any data migration required

Test/Demo Plan

Unit tests have been introduced as well as a mocking framework for XenAPI. Basic tests have been added and a lot more must be implemented

Unresolved issues

As mentioned above, the following work can done:

  • Extension to iscsi table and changes to iscsi driver
  • More unit tests
  • Write a new iscsi driver to handle storage using XenAPI/SM (Storage Manager) and more advanced iSCSI systems like filers etc.

BoF agenda and discussion

[TBD] Use this section to take notes during the BoF; if you keep it in the approved spec, use it for summarising what was discussed and note any options that were rejected.