Pass storage backed mount point to LXC container

[l-warlok]

I'm trying to pass through an existing LV to a container. I believe this means I need to use an image based, storage backed mountpoint as described here, which mentions a special syntax for creating a new LV, but there is no mention of the option to mount an existing LV.

I have created a new 10gb LV, formatted with ext4, for testing this configuration called lvol1, which exists on the thinDataLV thinpool, on the bigData VG.

When I try to mount this using pct the output is:

pct set 104 -mp1 bigData-thinpool:lvol1,mp=/mnt/test
Could not rescan volume size - unable to parse lvm volume name 'lvol1'

If I rescan the volumes attached to vm 104:

pct rescan --vmid 104
rescan volumes...
CT 104: updated volume size of 'bigData-thinpool:lvol1' in config.

The size is updated to 0T

mp1: bigData-thinpool:lvol1,mp=/mnt/test,size=0T

When i run the container:

lxc-start -n 104 -F
lxc-start: 104: ../src/lxc/conf.c: run_buffer: 322 Script exited with status 9
lxc-start: 104: ../src/lxc/start.c: lxc_init: 844 Failed to run lxc.hook.pre-start for container "104"
lxc-start: 104: ../src/lxc/start.c: __lxc_start: 2027 Failed to initialize container "104"
lxc-start: 104: ../src/lxc/tools/lxc_start.c: main: 306 The container failed to start

The output of lvs is

 LV             VG      Attr       LSize    Pool       Origin    Data%  Meta%  Move Log Cpy%Sync Convert   
 lvol1          bigData Vwi-a-tz--   10.00g thinDataLV           0.73                                     
 thinDataLV     bigData twi-aotz--    3.61t                      6.67   0.91

Is it possible to pass an existing LV through to a container like this? If so, how?

 

[fweber]

Hi,

lxc-start: 104: ../src/lxc/conf.c: run_buffer: 322 Script exited with status 9
lxc-start: 104: ../src/lxc/start.c: lxc_init: 844 Failed to run lxc.hook.pre-start for container "104"
lxc-start: 104: ../src/lxc/start.c: __lxc_start: 2027 Failed to initialize container "104"
lxc-start: 104: ../src/lxc/tools/lxc_start.c: main: 306 The container failed to start

FYI: To get a more detailed error message, you can start the container with pct start VMID -debug 1.

As an alternative to the storage:volume syntax, you could try a device mount point [1] and pass the volume's device path on the host, for example mp0: /dev/mapper/your-mapped-volume-name,mp=/mnt/test.

Hope that helps!

[1] https://pve.proxmox.com/pve-docs/pct.1.html#_device_mount_points

 

[fabian]

I'd take a step back and ask *why* you want to do that, instead of letting PVE allocate and manage the LV?

 

[l-warlok]

I'd take a step back and ask *why* you want to do that, instead of letting PVE allocate and manage the LV?

That's a good question and the answer is that I am a noob

I have data on several existing LVs(created by PVE) that are attached to a VM. I've recently added backups to my homelab and I realised I want to be able to manage LV backup on a more granular level.

My thought was to create an LXC per LV to serve over NFS and move those LVs over to the containers. Then I can back up the LVs individually as required, and the VM will still have access over NFS on the proxmox network bridge.

I could always let PVE create the LV and just copy the data across but I hoped for a more elegant solution as all these LVs are on the same VG and node.

@fweber
I did see the device mount point type but the note says

Device mount points should only be used under special circumstances. In most cases a storage backed mount point offers the same performance and a lot more features.

so I tried storage backed mount first.

It seems like this is not a standard config. Is there a better way to get granular control over backups of storage that's attached to a VM? Should I even want more control over backups? I think so because I want to back up rarely changing data less often than frequently changing data, but that's just my initial thoughts.

 

[fabian]

just use PBS, and you get fast incremental deduplicated backups when using VMs