activating a lvm in a group

[droidus]

I am trying to activate a lvm in a group. In the group, there are a total of 3 lvms. This one is not mounting though:

  --- Logical volume ---
  LV Name                data
  VG Name                pve
  LV UUID                GSlWfw-Y3aH-6C7l-iJ62-rqJD-TVQV-KxRO3y
  LV Write Access        read/write
  LV Creation host, time proxmox, 2020-04-04 20:07:21 -0400
  LV Pool metadata       data_tmeta
  LV Pool data           data_tdata
  LV Status              available
  # open                 17
  LV Size                <794.29 GiB
  Allocated pool data    19.58%
  Allocated metadata     1.17%
  Current LE             203337
  Segments               1
  Allocation             inherit
  Read ahead sectors     auto
  - currently set to     256
  Block device           253:4

I look in /dev/pve, and "data" is not in there. The two others in the group show up.

 

[Alwin]

What does lvs show? There you will see the current attributes.

 

[droidus]

LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert
data pve twi-aotz-- <794.29g 19.74 1.17
root pve -wi-ao---- 96.00g
swap pve -wi-ao---- 8.00g
vm-102-disk-0 pve Vwi-aotz-- 32.00g data 20.98

 

[Alwin]

data pve twi-aotz-- <794.29g 19.74 1.17

That seems to be ok. The mapper might not have created the device node. The easiest to see if that persists, is to reboot the node.

 

[droidus]

Did a reboot of the node. Still seeing the same thing:
data pve twi-aotz-- <794.29g 19.83 1.18

 

[Alwin]

What's the pveversion -v ?

 

[droidus]

proxmox-ve: 6.3-1 (running kernel: 5.4.78-2-pve)
pve-manager: 6.3-3 (running version: 6.3-3/eee5f901)
pve-kernel-5.4: 6.3-3
pve-kernel-helper: 6.3-3
pve-kernel-5.3: 6.1-6
pve-kernel-5.4.78-2-pve: 5.4.78-2
pve-kernel-5.4.78-1-pve: 5.4.78-1
pve-kernel-5.4.73-1-pve: 5.4.73-1
pve-kernel-5.3.18-3-pve: 5.3.18-3
pve-kernel-5.3.18-2-pve: 5.3.18-2
ceph-fuse: 12.2.11+dfsg1-2.1+b1
corosync: 3.0.4-pve1
criu: 3.11-3
glusterfs-client: 5.5-3
ifupdown: residual config
ifupdown2: 3.0.0-1+pve3
ksm-control-daemon: 1.3-1
libjs-extjs: 6.0.1-10
libknet1: 1.16-pve1
libproxmox-acme-perl: 1.0.7
libproxmox-backup-qemu0: 1.0.2-1
libpve-access-control: 6.1-3
libpve-apiclient-perl: 3.1-3
libpve-common-perl: 6.3-2
libpve-guest-common-perl: 3.1-3
libpve-http-server-perl: 3.1-1
libpve-storage-perl: 6.3-3
libqb0: 1.0.5-1
libspice-server1: 0.14.2-4~pve6+1
lvm2: 2.03.02-pve4
lxc-pve: 4.0.3-1
lxcfs: 4.0.3-pve3
novnc-pve: 1.1.0-1
proxmox-backup-client: 1.0.6-1
proxmox-mini-journalreader: 1.1-1
proxmox-widget-toolkit: 2.4-3
pve-cluster: 6.2-1
pve-container: 3.3-2
pve-docs: 6.3-1
pve-edk2-firmware: 2.20200531-1
pve-firewall: 4.1-3
pve-firmware: 3.1-3
pve-ha-manager: 3.1-1
pve-i18n: 2.2-2
pve-qemu-kvm: 5.1.0-7
pve-xtermjs: 4.7.0-3
qemu-server: 6.3-2
smartmontools: 7.1-pve2
spiceterm: 3.1-1
vncterm: 1.6-2
zfsutils-linux: 0.8.5-pve1

 

[Alwin]

Ok 6.3-3. Any multipath/iscsi setups? And can you create a VM disk on that storage?

 

[droidus]

I am not sure. But I did find this:


Is this it? So it is working as it should be?
It seems odd that I can create on it. But when I do a lvdisplay, for example, root has a LV Path of /dev/pve/root, but when I look at data, it does not have a LV Path, which seems to me like it's not mounted.

 

[Alwin]

Is this it? So it is working as it should be?

Did you create a VM/CT on it and start it? As the local-lvm is the default storage for a LVM based setup.

It seems odd that I can create on it. But when I do a lvdisplay, for example, root has a LV Path of /dev/pve/root, but when I look at data, it does not have a LV Path, which seems to me like it's not mounted.

I am not certain to why it doesn't get mapped. But I guess it may appear once you ran a VM/CT on it.

 

[droidus]

I am running several on it, and it does not show a "LV Path".

 

[fiona]

Hi,
the data LV is a thin pool, and thus only contains blocks and metadata for other logical volumes, see man 7 lvmthin. It cannot be mounted because it is not a filesystem. The respective device links should be in /dev/mapper, but I would strongly recommend not directly interacting with them, because you could lose the (meta)data of your thin pool.