Feature or Bug?: "pvesm path" command appears broken

[gfngfn256]

While testing, I discovered the following:

According to the pvesm manpage:

pvesm path <volume>
Get filesystem path for specified volume
<volume>: <string>
Volume identifier

So when trying this:

~# pvesm path local-lvm:vm-100-disk-0
/dev/pve/vm-100-disk-0

This is correct as shown by:

~# pvesm list local-lvm
Volid                   Format  Type             Size VMID
local-lvm:vm-100-disk-0 raw     images        4194304 100
local-lvm:vm-100-disk-1 raw     images    34359738368 100

However I then tried a non-existent Volid:

~# pvesm path local-lvm:vm-999-disk-999
/dev/pve/vm-999-disk-999

Upon testing, I discovered that as long as you use the correct LVM disk naming convention in Proxmox (vm-<vmid>-disk-<int>) you will get a correctly parsed but possibly non-existent reference!

I then tried with another Proxmox storage I have named Storage which is of a directory type:

~# pvesm path Storage:101/vm-101-disk-0.raw
/mnt/pve/Storage/images/101/vm-101-disk-0.raw

This is correct:

~# pvesm list Storage | grep "101/"
Storage:101/vm-101-disk-0.raw                              raw     rootdir    8589934592 101

However, here too, you can try non-existent ones:

~# pvesm path Storage:101/12345.raw
/mnt/pve/Storage/images/101/12345.raw

#or even non-existent VM:

~# pvesm path Storage:888/anything.qcow2
/mnt/pve/Storage/images/888/anything.qcow2

This works for vm's disks, as long as extension is either .qcow2 or .raw .

Let's try another Proxmox storage type, (I chose iso, but I guess all will behave similar):

~# pvesm path Storage:iso/non-existent.iso
/mnt/pve/Storage/template/iso/non-existent.iso
~# pvesm list Storage | grep "non-existent"
~#

So have I misunderstood something; pvesm path only references the theoretical path (if I were to create it) ?!
If it is only to see the path of the storage, BUT not the actual stored file/content, then the command should just be:
pvesm path <storageID>:<label> (I tried it but it returns with an error)

 

[fiona]

Hi,
yes, the implementation (currently) doesn't actually check if the volume exists, but the volume ID you provide needs to adhere to the usual structure (this can depend on the concrete plugin). For LVM, the volume might not currently be activated and thus not mapped there.

 

[gfngfn256]

Thanks for your reply. I'm therefore not sure of the use-case for this function, and this probably validates my above comment:

If it is only to see the path of the storage, BUT not the actual stored file/content, then the command should just be:
pvesm path <storageID>:<label>

For LVM, the volume might not currently be activated and thus not mapped there.

I get that. So let it return what it finds, & maybe add an LVM-specific warning that non-activated LVs won't appear.

 

[fiona]

Thanks for your reply. I'm therefore not sure of the use-case for this function, and this probably validates my above comment:

If it is only to see the path of the storage, BUT not the actual stored file/content, then the command should just be:
pvesm path <storageID>:<label> (I tried it but it returns with an error)

I'm not quite sure what you mean by label? If the label is not a valid volume name in Proxmox VE, why should it not fail?

The behavior is also not set in stone. I think it might've just been implemented like this in the storage plugin methods for simplicity/to avoid the need to do actual IO there. But (at least) for the user-facing pvesm invocation, such a check could make sense. Feel free to open a feature request: https://bugzilla.proxmox.com/

 

[gfngfn256]

Thanks for your reply.

I probably misused the word label incorrectly (for lack of a better term).

Just to clarify:
If pvesm path Storage:999/12345.raw returns without an error, even though neither VMID 999 nor 12345.raw exist, then why shouldn't pvesm path Storage:999 or pvesm path Storage itself also not return a valid result. I just don't get the point.

 

[fiona]

Just to clarify:
If pvesm path Storage:999/12345.raw returns without an error, even though neither VMID 999 nor 12345.raw exist, then why shouldn't pvesm path Storage:999 or pvesm path Storage itself also not return a valid result. I just don't get the point.

Because the argument for the pvesm path command is required to be a volume ID. Think of typed programming languages where you cannot call a function when the types of the arguments are not as required. One is a valid volume ID that can be parsed and the storage plugin can determine an associated path for it and the other just isn't a valid volume ID. You could implement the result for the examples you give for path-based storages, but then the argument for the command needs to allow different types other than a volume ID too, i.e. those types being a guest image dir and a storage ID. (Of course, the types here are conceptual/implicitly determined by what the string looks like).

 

[gfngfn256]

Thanks for you speedy reply. I understand it programmatically, just don't see the real benefit. Better would be that the command should actually check that the said volume really exists. A warning could be added for a non-active LV.

 

[fiona]

Thanks for you speedy reply. I understand it programmatically, just don't see the real benefit. Better would be that the command should actually check that the said volume really exists. A warning could be added for a non-active LV.

Yes, feel free to open a feature request for this: https://bugzilla.proxmox.com/