[pve-devel] [RFC 1/2 pve-storage] implement map_volume and unmap_volume

[Dietmar Maurer]

> > I though somebody will suggest a better name for that parameter so that it looks more reasonable?
> 
> FWIW, I like Thomas suggestion of pulling out the bdev path generation
> into a private sub (or, since we are already adding to the storage
> API[1], evaluate whether "give me the block device for this volume"
> deserves its own API method).

OK
 
> are there other storage types/situations where map would be appropriate?
> 
> IMHO, LVM and LVM-Thin would logically also fit into that category
> (especially if we ever implement using the "activation skip" feature for
> PVE-managed LVs, and not let them auto-activate on boot anymore).

The map feature only makes sense if you can access the device 'with' or 'without' a kernel device. LVM always needs a kernel device, so using 'map' make things unnecessarily complex for no good reason.

> loopback devices (.raw / .iso for containers) might also work, but the
> current code is a bit more involved so might not be easily portable to
> the new map_volume semantics..

I would not touch that code for now.

> 1: don't forget to bump the storage plugin API version..

@alwin: Please can you continue to work on that. We also want to cleanup the ceph config (only a single config entry)?