- Launchpad Entry: NovaSpec:bexar-iscsi-support-xenapi
- Created: 16 November 2010
- Contributors: Armando Migliaccio
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.
- 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
This spec will provide iSCSI back-end storage for XenServer hosted virtual machines via XenAPI.
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.
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.
The changes provided with this blueprint will obviosuly work only with the iSCSI driver for nova-volume
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.
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.
no changes, other than the euca-attach-volume and euca-detach-volume now respond correctly when the underlying hypervisor is XS/XCP
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.
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
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
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.