-
Notifications
You must be signed in to change notification settings - Fork 1.1k
Feature: iSCSI Initiator
Cockpit should allow people to configure the iSCSI initiator on the host.
- iSCSI is a way of mounting remote block devices.
- Scope: This feature is only client side.
- "iSCSI initiator" is the client side. "iSCSI target" is the server side.
User stories, workflow that will drive design.
User stories:
Robert is a sysadmin in a data-center. Robert runs a central SAN which exports it's LUNs via iSCSI and many hosts accessing that SAN. Robert wants to use the iSCSI initiator to discover targets on the remote target, and set the CHAP username and password to be able to connect to one of the discovered LUNs and attach it to the local host.
George runs a startup he quickly needs to expand the storage of his heavily overloaded VM. George get's some block storage from his favorite online cloud storage provider. Now George want's to discover and attach the remote storage to his local machine. To do this, George first needs to discover the remote portal, to see what LUNs are available. To leverage multiple paths (multipath) he might want to choose specific NIC 8residing on different subnets) for connecting to the remote portal.
Once he can list the remote targets, he selects the new one and attaches it to the local host.
From this point on George can handle it like a regular device.
Add multiple workflows here, for the various tasks that need to be accomplished.
Robert:
- Robert needs to setup a new hypervisor for one of his colleagues
- He orders a new physical machine, and the day it arrives he sets it up
- In his setup, the VMs running on the hypervisor, are not stored locally on the hypervisor, but centrally on a SAN
- After setting up the host, he now needs to attach a LUN from the SAN
- He opens Cockpit, and goes to the iSCSI Initiator page
- He enters the credentials (username and password) of the (on the SAN) freshly created CHAP user
- He then enters the FQDN and port of the SAN portal, and clicks "Discover targets" to find the available LUNs
- After finding the relevant LAN, he attaches it to the host
- Finally he configures the hypervisor to use the freshly attached LUN for storing and retrieving the VM images
George:
- ...
- ...
- ...
Please give feedback on the above!
- Is the user expected to reconfigure the LUN? Or just remove it if he no longer needs it?
- How is the user expected to diagnose an issue with the LUN after configuration (eg: networking issue). Is this out of scope?
- Is it out of scope to format and prepare such a device mounted from a LUN? Does this feature always assume that the iSCSI LUN has been formatted with a readable file system by the SAN administrator (elsewhere).