Add volume driver concept to xenapi driver

Registered by Mate Lakat

A volume driver is a piece of code that could use a connection_info structure to attach a block device to the instance.

At the moment xenapi supports raw iscsi and xenapinfs cinder backends. One codeblock supports connecting both types.

The issue with the actual implementation is that the volume related code is spread across different places.

This blueprint is about to introduce a plugin model in the xenapi driver, so that it is extensible. Separate the xenapinfs, and raw iscsi drivers to distinct plugins. Having a driver model will help in maintenance, and make it easier to connect to new protocols.

Blueprint information

Vish Ishaya
Citrix OpenStack development team
Mate Lakat
Series goal:
Good progress
Milestone target:
Started by
Vish Ishaya
Completed by
John Garbutt

Related branches



Killing this off, there is some new work that will cover the remaining tasks here, moving things to oslo:


I'm removing blueprints from grizzly where the code is not up for review. It looks like there is still more work needed here and the code is not up for review, so I'm taking it off the grizzly list. If this happens to make it in anyway, let me know and I'll add it back. --Russell

Look at:

We need a XenAPI equivalent to provide:
attach, detach volumes

The aim is to allow any 3rd party vendor should easily add its volume driver.
It is likely you may also need to include changes to XenServer, packaged as a supplemental pack

Likely steps:
Refactor xapi driver nova/virt/xenapi/ [attach_volume]
according to nova/virt/libvirt/ (plugin pattern)

At the moment, two implementations exist: ['iscsi', 'xensm']
Need to document the XenSM case much better, so it can be used by third parties.

Consider adding a file based SR attach for XCP-XenAPI and gluster/ceph as an example.

The LibVirtVolumeDriver's connect_volume method returns a struct, that could be digested by libvirt, a sort of configuration, that could be passed to an instance's attachDeviceFlags method, see:

It needs to be decided what should be the interface with xenapi.
a VDI ref seems reasonable.

Look at: nova/virt/xenapi/ / introduce_sr

The libvirt "interface":

class LibvirtVolumeDriver(object):
    def __init__(self, connection):

    def connect_volume(self, connection_info, mount_device):

    def disconnect_volume(self, connection_info, mount_device):

connection is actually a reference to the compute driver.

The dependency for a volume driver in XenAPI case:
- An initialised XenAPI connection

The parameters could be the same as in the libvirt case:
- connection_info: the data structure, returned from volume_api.initialize_connection
- mount_device: the mount_device, that identifies the device, converted to device number by: nova/virt/xenapi/

I am not sure, if the whole connection_info needs to be passed to the driver implementation. I guess, only connection_info[data] needs to be passed down.

Gerrit topic:,topic:bp/xenapi-volume-drivers,n,z

Addressed by:
    Do not call directly vmops.attach_volume

Addressed by:
    Introduce volume manager, and drivers

Addressed by:
    limit the usage of connection_info

The volume_connect must support a rollback, so using a context manager should be considered. No. Context managers are not reflecting the same thing, so a separate rollback method on the driver makes more sense.

Addressed by:
    Remove mountpoint from parse_volume_info

Addressed by:
    Restructure attach_volume

Addressed by:
    refactor: extract method vm_ref_or_raise

Addressed by:
    refactor: extract method: connect_volume

Addressed by:
    refactor: extract class XenAPISessionBase

This seems to have stalled, so I'm going to untarget it from Grizzly for now. Please ping me or Vish if this is picked back up.

Sorry guys, this has been a bit blocked by some Cinder work. We should have that all in place, and the local CI to test both configurations, so should get back going very soon.

Addressed by:
    Refactor: extract method: to_driver_registry

Addressed by:
    xenapi: Remove dead code, moves, tests


Work Items

Work items:
Refactor the volume attach and detach calls: INPROGRESS
Remove last traces of old nova-volume SM code: TODO
Pull volume driver related code from libvirt/driver to driver: INPROGRESS

This blueprint contains Public information 
Everyone can see this information.