ISCSISupportXenAPI - Revision history

Ryan Lane: Text replace - "NovaSpec" to "NovaSpec"

2013-02-17T23:31:12Z

Text replace - "NovaSpec" to "NovaSpec"

Ryan Lane: Text replace - "NOTOC" to ""

2013-02-17T23:29:59Z

Text replace - "__NOTOC__" to ""

Todd: fix some formatting

2011-11-18T03:27:41Z

fix some formatting

Armando at 14:28, 24 December 2010

2010-12-24T14:28:33Z

Armando at 14:27, 24 December 2010

2010-12-24T14:27:39Z

Armando: being consistent with the glossary

2010-12-03T11:34:42Z

being consistent with the glossary

at 00:00, 1 January 1970

1970-01-01T00:00:00Z

New page

__NOTOC__
* '''Launchpad Entry''': [[NovaSpec]]:bexar-iSCSI-support-xenserver
* '''Created''': 16 November 2010
* '''Contributors''': Armando Migliaccio

== Summary ==

== Release Note ==

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.)

It is mandatory.

== Rationale ==

== User stories ==

== Assumptions ==

== Design ==

You can have subsections that better describe specific parts of the issue.

== Implementation ==

This section should describe a plan of action (the "how") to implement the changes discussed. Could include subsections like:

=== UI Changes ===

Should cover changes required to the UI, or specific UI that is required to implement this

=== Code Changes ===

Code changes should include an overview of what needs to change, and in some cases even the specific details.

=== Migration ===

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 ==

This need not be added or completed until the specification is nearing beta.

== Unresolved issues ==

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.

== BoF agenda and discussion ==

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]]

@@ Line 1: / Line 1: @@
 <!-- ## page was renamed from iSCSISupportForXenServer -->
-* '''Launchpad Entry''': [[NovaSpec]]:bexar-iscsi-support-xenapi
+* '''Launchpad Entry''': NovaSpec:bexar-iscsi-support-xenapi
 * '''Created''': 16 November 2010
 * '''Contributors''': Armando Migliaccio

@@ Line 1: / Line 1: @@
-__NOTOC__
 <!-- ## page was renamed from iSCSISupportForXenServer -->
 * '''Launchpad Entry''': [[NovaSpec]]:bexar-iscsi-support-xenapi

@@ Line 6: / Line 6: @@
 == 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.
+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
+* 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
+* 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
+* 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
+* 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.
+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.
+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.
+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 ==
@@ Line 40: / Line 40: @@
 === 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
+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 ==

@@ Line 6: / Line 6: @@
 == 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
+* [[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
-      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
+* Extension to iscsi table and changes to iscsi driver
-- More unit tests
+* More unit tests
-- Write a new iscsi driver to handle storage using XenAPI/SM (Storage Manager) and more advanced iSCSI systems like filers etc.
+* 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.
 ----
 [[Category:Spec]]