The nova.volume.san Module

Drivers for san-stored volumes.

The unique thing about a SAN is that we don’t expect that we can run the volume controller on the SAN hardware. We expect to access it over SSH or some API.

class HpSanISCSIDriver(*args, **kwargs)

Bases: nova.volume.san.SanISCSIDriver

Executes commands relating to HP/Lefthand SAN ISCSI volumes.

We use the CLIQ interface, over SSH.

Rough overview of CLIQ commands used:

Createvolume :(creates the volume)
Getvolumeinfo :(to discover the IQN etc)
Getclusterinfo :
 (to discover the iSCSI target IP address)
Assignvolumechap :
 (exports it with CHAP security)

The ‘trick’ here is that the HP SAN enforces security by default, so normally a volume mount would need both to configure the SAN in the volume layer and do the mount on the compute layer. Multi-layer operations are not catered for at the moment in the nova architecture, so instead we share the volume using CHAP at volume creation time. Then the mount need only use those CHAP credentials, so can take place exclusively in the compute layer.

create_snapshot(snapshot)

Creates a snapshot.

create_volume(volume)

Creates a volume.

create_volume_from_snapshot(volume, snapshot)

Creates a volume from a snapshot.

delete_volume(volume)

Deletes a volume.

initialize_connection(volume, connector)

Assigns the volume to a server.

Assign any created volume to a compute node/host so that it can be used from that host. HP VSA requires a volume to be assigned to a server.

This driver returns a driver_volume_type of ‘iscsi’. The format of the driver data is defined in _get_iscsi_properties. Example return value:

{
    'driver_volume_type': 'iscsi'
    'data': {
        'target_discovered': True,
        'target_iqn': 'iqn.2010-10.org.openstack:volume-00000001',
        'target_portal': '127.0.0.1:3260',
        'volume_id': 1,
    }
}
local_path(volume)
terminate_connection(volume, connector)

Unassign the volume from the host.

class SanISCSIDriver(*args, **kwargs)

Bases: nova.volume.driver.ISCSIDriver

Base class for SAN-style storage volumes

A SAN-style storage value is ‘different’ because the volume controller probably won’t run on it, so we need to access is over SSH or another remote protocol.

check_for_setup_error()

Returns an error if prerequisites aren’t met.

create_export(context, volume)

Exports the volume.

ensure_export(context, volume)

Synchronously recreates an export for a logical volume.

remove_export(context, volume)

Removes an export for a logical volume.

class SolarisISCSIDriver(*args, **kwargs)

Bases: nova.volume.san.SanISCSIDriver

Executes commands relating to Solaris-hosted ISCSI volumes.

Basic setup for a Solaris iSCSI server:

pkg install storage-server SUNWiscsit

svcadm enable stmf

svcadm enable -r svc:/network/iscsi/target:default

pfexec itadm create-tpg e1000g0 ${MYIP}

pfexec itadm create-target -t e1000g0

Then grant the user that will be logging on lots of permissions. I’m not sure exactly which though:

zfs allow justinsb create,mount,destroy rpool

usermod -P’File System Management’ justinsb

usermod -P’Primary Administrator’ justinsb

Also make sure you can login using san_login & san_password/san_private_key

create_export(context, volume)
create_volume(volume)

Creates a volume.

delete_volume(volume)

Deletes a volume.

ensure_export(context, volume)

Synchronously recreates an export for a logical volume.

local_path(volume)
remove_export(context, volume)

Removes an export for a logical volume.

Previous topic

The nova.volume.nfs Module

Next topic

The nova.volume.solidfire Module

This Page