Re: [pve-devel] [RFC storage 1/3] plugin: add method to get qemu blockdevice options for volume

["DERUMIER, Alexandre via pve-devel" <pve-devel@lists.proxmox.com>]

[-- Attachment #1: Type: message/rfc822, Size: 13697 bytes --]

From: "DERUMIER, Alexandre" <alexandre.derumier@groupe-cyllene.com>
To: "pve-devel@lists.proxmox.com" <pve-devel@lists.proxmox.com>, "f.ebner@proxmox.com" <f.ebner@proxmox.com>
Subject: Re: [pve-devel] [RFC storage 1/3] plugin: add method to get qemu blockdevice options for volume
Date: Fri, 23 May 2025 08:50:50 +0000
Message-ID: <67db7959a03a391df39e9b5af24edc2bed48a21d.camel@groupe-cyllene.com>

> 
> Also, for lvm volume, they are not currently activate at vm command
> line generation. (but anyway, I'll need it to retrieve backing chain,
> so maybe it's not a problem)

>>Thanks for testing! I'll add an activate_volume() call in the
>>PVE::Storage::qemu_blockdev_options() function. 
>>I'd guess (almost?) >>all
>>calls of the function will be followed by actually using the device
>>afterwards, so that seems sensible enough.

ok. (I'll also verify in qemu-server to deactivate_volumes, if vm
command line generation is failing, as I think we only doing it in
vm_start currently)


> Do you think it's enough safe to rely on /dev/.. path?

>>Can you mock File::stat::stat() or
>>PVE::Storage::qemu_blockdev_options()? I'd rather not make the
>>production code less precise, just for easier tests if it can be
>>avoided.

sure,no problem!

(maybe also add a check if the file exist before calling st->mode,
because I got

# got unexpected error: Can't call method "mode" on an undefined value 



[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel