On 11/29/24 15:23, Fiona Ebner wrote:
Am 16.09.24 um 18:38 schrieb Daniel Kral:
Improves checks if the underlying storage, where VMs are restored to,
support the content type 'images'. This has been already the case for
backup restores, but is refactored to use `check_storage_alloc` and
`check_volume_alloc`.
Adds a check right before allocating a snapshot statefile and a
fleecing VM disk image for backups for consistency with the storage
content type system.
Signed-off-by: Daniel Kral <d.k...@proxmox.com>
---
I am not sure about the changes to the statefile and fleecing images
allocation as I've done them for consistency as well, but could cause
sudden failures, especially if the logic in
`PVE::QemuServer::find_vmstate_storage` could default to the hardcoded
`local` storage, which fails on system where said storage does not
support vm images (which is the default when installing PVE). Also the
fleecing disk image storage is specified when starting the backup job
with the `storeid` parameter in the PVE::VZDump::Plugin, where I'm not
totally sure yet how it is used across the repositories.
The part about the vmstate images should be part of the commit message,
but is also the reason we can't go for it right now. I do think the
fallback to 'local' can trigger for a VM without disks. We can add a
comment there to fix it up for Proxmox VE 9.0 (i.e. don't default to
local storage anymore, but require an explicit vmstate storage for such
VMs) where we can do such breaking changes.
Thanks for the clarification, I'll take another look at this and add a
comment there. I might append a for-9.0 RFC patch if it doesn't change
too much and could be easily rebased for the 9.0 release.
_______________________________________________
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
