reference value is passed straight from the get_volume_list helper
function. it is up to the driver how this should be interpreted.
It should be sufficient to identify a storage object that the driver
should somehow associate with the newly-created cinder volume
structure.
There are two ways to do this:

Rename the backend storage object so that it matches the,
volume[‘name’] which is how drivers traditionally map between a
cinder volume and the associated backend storage object.

Place some metadata on the volume, or somewhere in the backend, that
allows other driver requests (e.g. delete, clone, attach, detach…)
to locate the backend storage object when required.

If the reference doesn’t make sense, or doesn’t refer to an existing
backend storage object, raise a ManageExistingInvalidReference
exception.

The volume may have a volume_type, and the driver can inspect that and
compare against the properties of the referenced backend storage
object. If they are incompatible, raise a
ManageExistingVolumeTypeMismatch, specifying a reason for the failure.