prior to the introduction of snapshot as volume chains, volume names of
almost arbitrary form were accepted. only forbid filenames which are
part of the newly introduced namespace for snapshot files, while
deprecating other names not following our usual naming scheme, instead
of forbidding them outright.
Fixes: b63147f5df "plugin: fix volname parsing"
Co-authored-by: Shannon Sterz <s.sterz@proxmox.com>
Signed-off-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
Tested-by: Shannon Sterz <s.sterz@proxmox.com>
Link: https://lore.proxmox.com/20250731111519.931104-2-f.gruenbichler@proxmox.com
Without untainting, offline-deleting a volume-chain snapshot on an LVM
storage via the GUI can fail with an "Insecure dependecy in exec
[...]" error, because volume_snapshot_delete uses the filename its
qemu-img invocation.
Commit 93f0dfb ("plugin: volume snapshot info: untaint snapshot
filename") fixed this already for the volume_snapshot_info
implementation of the Plugin base class, but missed that the LVM
plugin overrides the method and was still missing the untaint.
Signed-off-by: Friedrich Weber <f.weber@proxmox.com>
Link: https://lore.proxmox.com/20250731071306.11777-1-f.weber@proxmox.com
Volume names are allowed to contain underscores, so it is impossible
to determine the snapshot name from just the volume name, e.g:
snap_vm-100-disk_with_underscore_here_s_some_more.qcow2
Therefore, pass along the short volume name too and match against it.
Note that none of the variables from the result of parse_volname()
were actually used previously.
Signed-off-by: Fiona Ebner <f.ebner@proxmox.com>
Tested-by: Max R. Carrara <m.carrara@proxmox.com>
Reviewed-by: Max R. Carrara <m.carrara@proxmox.com>
Link: https://lore.proxmox.com/20250730162117.160498-3-f.ebner@proxmox.com
At the moment calling
```
pvesm add pbs test --password="bär12345" --datastore='test' # ..other params
```
Will result in the API handler getting the param->{passowrd} as a utf-8
encoded string. When dumped with Debug::Peek's Dump() one can see:
```
SV = PV(0x5a02c1a3ff10) at 0x5a02bd713670
REFCNT = 1
FLAGS = (POK,IsCOW,pPOK,UTF8)
PV = 0x5a02c1a409b0 "b\xC3\xA4r12345"\0 [UTF8 "b\x{e4}r12345"]
CUR = 9
LEN = 11
COW_REFCNT = 0
```
Then when writing the file via file_set_contents (using syswrite
internally) will result in perl encoding the password as latin1 and a
file with contents:
```
$ hexdump -C /etc/pve/priv/storage/test.pw
00000000 62 e4 72 31 32 33 34 35 |b.r12345|
00000008
```
when the correct contents should have been:
```
00000000 62 c3 a4 72 31 32 33 34 35 |b..r12345|
00000009
```
Later when the file is read via file_read_firstline it will result in
```
SV = PV(0x5e8baa411090) at 0x5e8baa5a96b8
REFCNT = 1
FLAGS = (POK,pPOK)
PV = 0x5e8baa43ee20 "b\xE4r12345"\0
CUR = 8
LEN = 81
```
which is a different string than the original.
At the moment, adding the storage will work as the utf8 password is
still in memory, however, however subsequent uses (e.g. pvestatd) will
fail.
This patch fixes the issue by encoding the string as utf8 both when
reading and storing it to disk. The user was able in the past to go
around the issue by writing the right password in
/etc/pve/priv/{storage}.pw and this fix is compatible with that.
It is documented at
https://pbs.proxmox.com/docs/backup-client.html#environment-variables
that the Backup Server password must be valid utf-8.
Signed-off-by: Maximiliano Sandoval <m.sandoval@proxmox.com>
Link: https://lore.proxmox.com/20250730072239.24928-1-m.sandoval@proxmox.com
Signed-off-by: Wolfgang Bumiller <w.bumiller@proxmox.com>
[FE: use 'images' rather than not-yet-existing 'ct-vol' for now
disable seen vtype tests for now]
Signed-off-by: Fiona Ebner <f.ebner@proxmox.com>
The existence of the original volume should imply the existence of its
parent directory, after all... And with the new typed subdirectories
this was wrong.
Signed-off-by: Wolfgang Bumiller <w.bumiller@proxmox.com>
ZFS itself does not track the refquota per snapshot, so this needs to
be handled by Proxmox VE. Otherwise, rolling back a volume that has
been resized since the snapshot was taken, will retain the new size.
This is problematic, as it means the value in the guest config does
not match the size of the disk on the storage anymore.
This implementation does so by leveraging a user property per
snapshot.
Reported-by: Lukas Wagner <l.wagner@proxmox.com>
Suggested-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
Signed-off-by: Shannon Sterz <s.sterz@proxmox.com>
Reviewed-by: Fiona Ebner <f.ebner@proxmox.com>
Link: https://lore.proxmox.com/20250729121151.159797-1-s.sterz@proxmox.com
[FE: improve capitalization and wording in commit message]
Signed-off-by: Fiona Ebner <f.ebner@proxmox.com>
Without untainting, offline-deleting a volume-chain snapshot on a
directory storage via the GUI fails with an "Insecure dependecy in
exec [...]" error, because volume_snapshot_delete uses the filename
its qemu-img invocation.
Signed-off-by: Friedrich Weber <f.weber@proxmox.com>
Callers interested in the list of valid formats from
storage_default_format() actually want this functionality.
Signed-off-by: Fiona Ebner <f.ebner@proxmox.com>
Rely on get_formats() rather than just the static plugin data in the
'status' API call. This removes the need for the special casing for
LVM storages without the 'snapshot-as-volume-chain' option. It also
fixes the issue that the 'format' storage configuration option to
override the default format was previously ignored there.
Signed-off-by: Fiona Ebner <f.ebner@proxmox.com>
As the alloc_lvm_image() helper asserts, qcow2 cannot be used as a
format without the 'snapshot-as-volume-chain' configuration option.
Therefore it is necessary to implement get_formats() and distinguish
based on the storage configuration.
In case the 'snapshot-as-volume-chain' option is set, qcow2 is even
preferred and thus declared the default format.
Signed-off-by: Fiona Ebner <f.ebner@proxmox.com>
The LVM plugin can only use qcow2 format when the
'snapshot-as-volume-chain' configuration option is set. The format
information is currently only recorded statically in the plugin data.
This causes issues, for example, restoring a guest volume that uses
qcow2 as a format hint on an LVM storage without the option set will
fail, because the plugin data indicates that qcow2 is supported.
Introduce a dedicated method, so that plugins can indicate what
actually is supported according to the storage configuration.
The implementation for LVM is done in a separate commit.
Remove the now unused default_format() function from Plugin.pm.
Signed-off-by: Fiona Ebner <f.ebner@proxmox.com>
[WB: docs: add missing params, drop =pod line, use !! for bools]
Signed-off-by: Wolfgang Bumiller <w.bumiller@proxmox.com>
Because LvmThinPlugin.pm uses LVMPlugin.pm as a base, it inherits the
`volume_rollback_is_possible()` subroutine added in eda88c94. Its
implementation however causes snapshot rollbacks to fail with
"can't rollback snapshot for 'raw' volume".
Fix this by implementing `volume_rollback_is_possible()`.
Closes: #6553
Signed-off-by: Max R. Carrara <m.carrara@proxmox.com>
As this cannot trigger due to no direct upgrade path existing between
PVE 7 and PVE 9, we only support single major version upgrades at a
time.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Not perfect but now it's still easy to rename and the new variant fits
a bit better to the actual design and implementation.
Add best-effort migration for storage.cfg, this has been never
publicly released after all.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
This also changes the return values, since their meanings are rather
weird from the storage point of view. For instance, "internal" meant
it is *not* the storage which does the snapshot, while "external"
meant a mixture of storage and qemu-server side actions. `undef` meant
the storage does it all...
┌────────────┬───────────┐
│ previous │ new │
├────────────┼───────────┤
│ "internal" │ "qemu" │
│ "external" │ "mixed" │
│ undef │ "storage" │
└────────────┴───────────┘
Signed-off-by: Wolfgang Bumiller <w.bumiller@proxmox.com>
