[pve-devel] [PATCH storage 08/26] prepare for vm-vol and ct-vol content and vtypes
Fabian Grünbichler
f.gruenbichler at proxmox.com
Wed Jul 30 11:14:50 CEST 2025
On July 29, 2025 1:15 pm, Wolfgang Bumiller wrote:
> Prepares the stoplevel PVE::Storage API updates as well as adding the
> new vtype subdirs to the base plugin's vtype subdir hash.
>
> The new types are "vm-vol" and "ct-vol". They represent VM and
> container volumes, respectively. The "images" and "rootdir" types are
> considered legacy/deprecated, as the "rootdir" type was not properly
> used, and container volumes were technically of type "images", with
> the "rootdir" case "hacked in" by checking the existing VMs.
>
> To more easily transition, the "images" type is now also a "supertype"
> of "vm-vol", and the "rootdir" type a "supertype" of "ct-vol".
>
> - `get_images_dir()` is replaced by `get_vm_volume_dir()`
> - `get_private_dir()` is dropped as it is an openvz leftover
> - `get_ct_volume_dir()` is added its stead
>
> We now also unify the vtypes and content types. As such,
> `content-dirs` can now include separate dirs for `vm-vol` and
> `ct-vol`.
> This is now also taken into account in `path_to_volume_id()` which
> tries to match file system paths to a storage and content type.
>
> The following subs also get a $vtype parameter:
> - `vdisk_alloc()`
alloc requires it
> - `vdisk_clone()`
> - `volume_import()`
these two don't. should we make vdisk_clone also require it? or should
we remove it altogether and always use the vtype of the base volume?
for import we probably want to make it optional for now to support old
nodes triggering it..
More information about the pve-devel
mailing list