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
> > 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
On Fri, Sep 21, 2018 at 03:21:50PM +0200, Dietmar Maurer wrote:
> > I know you just do this to not duplicate the blockdevice path assembly,
> > but it feels a bit weird to directly have an map with $nomap method call
> > in unmap, maybe pull the common parts out in its own ($private) helper sub?
>
> I know you just do this to not duplicate the blockdevice path assembly,
> but it feels a bit weird to directly have an map with $nomap method call
> in unmap, maybe pull the common parts out in its own ($private) helper sub?
I though somebody will suggest a better name for that parameter so
On 9/21/18 2:37 PM, Thomas Lamprecht wrote:
> [...]
>
> Single thing which was not working was the a full clone of a linked clone,
> i.e., convert a CT to a template, create a linked clone with said template
> as base (works) and then clone the linked clone (full clone), which seems
> to work
On 9/21/18 7:58 AM, Dietmar Maurer wrote:
> This allows to request a mapped device/path explicitly,
> regardles of the storage option, eg. krbd option in the RBDplugin.
I like this approach more, less intrusive and more explicit.
I tested a bit around, i.e., create CT, snapshot it, clone from
This allows to request a mapped device/path explicitly,
regardles of the storage option, eg. krbd option in the RBDplugin.
Signed-off-by: Dietmar Maurer
---
PVE/Storage.pm | 24 +++
PVE/Storage/Plugin.pm| 12 ++
PVE/Storage/RBDPlugin.pm | 62
