Support logical devices in `lvm prepare --data <device path>`
`ceph-volume lvm prepare --data <device path>` only accepts physical block
devices and partitions.
It will be convenient to support other kinds of devices.
Possible use cases are as follows:
- With dm-fleakey, we can simulate the failure of devices in testing.
- With dm-crypt, we can use encrypted devices with a variety of
- With LVs in the form of device path, orchestration software,
e.g. Rook, can pass LVs transparently like other devices.
#2 Updated by Satoru Takeuchi 4 months ago
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.
- 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.
def prepare_device(self, arg, device_type, cluster_fsid, osd_fsid):
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)
vg.name, # the volume group
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.
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.
- 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.
#3 Updated by Jan Fajerski 4 months ago
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?
#4 Updated by Satoru Takeuchi 4 months ago
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.
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
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.
#6 Updated by Satoru Takeuchi 4 months ago
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.