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

[Fabian Grünbichler]

On Mon, Sep 24, 2018 at 09:40:04AM +0200, Dietmar Maurer wrote:
> > > 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

fair enough. it does mean introducing two new storage plugin methods
just for a single storage type though.. all the other stuff that I can
think of is rather contrived (e.g., exporting stuff like qcow2 files
over nbd).

> > 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)?