[pve-devel] [RFC qemu-server 9/9] restore_vm: improve checks if storage supports vm images

Daniel Kral d.kral at proxmox.com
Wed Jan 22 14:21:06 CET 2025


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.kral at 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.




More information about the pve-devel mailing list