Ceph » ceph-volume

This is already supported. You can pass an lv to the lvm create or lvm prepare subcommands like so:

ceph-volume lvm prepare --data <vg_name>/<lv_name>

Does this not work for you? If so can you please open a bug and add a debug log?

This is already supported. You can pass an lv to the lvm create or lvm prepare subcommands like so:

ceph-volume lvm prepare --data <vg_name>/<lv_name>

Oops, probably my expression, `logical devices` was improper.

What I mean and what I'm preparing PR to are as follows.

1. a. Support devices created by device-mappers

Let assume that we want to use a device created with dm-flakey as OSD.
When we call `ceph-volume lvm prepare --data <path/to/device`,
it fails since the following condition A becomes false.

https://github.com/ceph/ceph/blob/70d27ce3523738c9363760d33d819bf48342b9fe/src/ceph-volume/ceph_volume/devices/lvm/prepare.py#L192
```
def prepare_device(self, arg, device_type, cluster_fsid, osd_fsid):
<snip>
if disk.is_partition(arg) or disk.is_device(arg): ... condition A # we must create a vg, and then a single lv
vg = api.create_vg(arg)
lv_name = "osd-%s-%s" % (device_type, osd_fsid)
return api.create_lv(
lv_name,
vg.name, # the volume group
tags={'ceph.type': device_type})
else:
error = [
'Cannot use device (%s).' % arg,
'A vg/lv path or an existing device is needed']
raise RuntimeError(' '.join(error))

```

I know multiple devices are not supported as-is.
https://docs.ceph.com/docs/mimic/ceph-volume/lvm/prepare/#multipath-support

However, the above-mentioned condition A prohibits not only multipath
devices (lsblk's TYPE=="mpath"), but also all device excepts physical
devices and partitions thereof (TYPE == "disk" or "part").
It's a too strong restriction.

1. b. Passing LV to ceph-volume transparently

Currently, we can pass LV to ceph-volume with `vg_name/lv_name` as you said.
In addition to this way, it's convenient to be able to pass it with a device
name because users can manage LVs and other devices transparently.

If I should divide this issue to two different ones, I'll do it.

Regarding multipath: I'm actually exploring that too. I believe this should work fine (I need a test system) when you simply create block device nodes for your mpath device. It would be up to the admin to make sure that multipath is set up as expected.

The second use case (passing an LV by a device node) I'm not sure what the advantage is. You should be able to pass any LV by <vg_name>/<lv_name>, what does the option to pass an LV by dev/<some_name> add here?

Regarding multipath: I'm actually exploring that too. I believe this should work fine (I need a test system)
when you simply create block device nodes for your mpath device. It would be up to the admin to make sure
that multipath is set up as expected.

Got it.

In the PR that I've created, mpath type is intentionally rejected.
Do you mean that mpath should also be permitted? In other words,
permitting all types of block devices is more preferable than the current
implementation?

The second use case (passing an LV by a device node) I'm not sure what the advantage is.
You should be able to pass any LV by <vg_name>/<lv_name>, what does the option to pass
an LV by dev/<some_name> add here?

It's not a kind of must-have feature, but for a little convenience.
From the perspective of Ceph orchestration tools like Rook, its users will
specify the devices for OSD as /path/to/device without the knowledge of device type.

Anyway, this LV topic is a bit different from the first topic. So I withdraw this topic
from this issue. I'm sorry to confuse you.

My PR is here.

https://github.com/ceph/ceph/pull/31205

As I wrote in the following PR, the scope of this issue is too wide.
I'll close this ticket and will reconsider the use case of individual
block device type.

https://github.com/ceph/ceph/pull/31205#issuecomment-552042462

I seem not to have enough privilege to change the status of this ticket.
Could you close it? I'm sorry to bother you.