From: Daniel Kral <d.kral@proxmox.com>
To: Fiona Ebner <f.ebner@proxmox.com>,
Proxmox VE development discussion <pve-devel@lists.proxmox.com>
Subject: Re: [pve-devel] [RFC qemu-server 9/9] restore_vm: improve checks if storage supports vm images
Date: Wed, 22 Jan 2025 14:21:06 +0100 [thread overview]
Message-ID: <eb80f82a-3f73-4f1f-9294-b0ace2034357@proxmox.com> (raw)
In-Reply-To: <ce8fdfc2-f2df-4544-bebc-a2596a976750@proxmox.com>
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@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
prev parent reply other threads:[~2025-01-22 13:21 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-09-16 16:38 [pve-devel] [RFC qemu-server 0/9] consistent checks for storage content types on volume disk allocation Daniel Kral
2024-09-16 16:38 ` [pve-devel] [RFC qemu-server 1/9] test: cfg2cmd: expect error for invalid volume's storage content type Daniel Kral
2024-11-29 14:23 ` Fiona Ebner
2024-09-16 16:38 ` [pve-devel] [RFC qemu-server 2/9] cfg2cmd: improve error message for invalid volume " Daniel Kral
2024-11-29 14:23 ` Fiona Ebner
2025-01-22 13:16 ` Daniel Kral
2025-01-22 14:31 ` Fiona Ebner
2024-09-16 16:38 ` [pve-devel] [RFC qemu-server 3/9] fix #5284: move_vm: add check if target storage supports vm images Daniel Kral
2024-11-29 14:23 ` Fiona Ebner
2025-01-22 13:18 ` Daniel Kral
2025-01-22 13:43 ` Daniel Kral
2025-01-22 14:35 ` Fiona Ebner
2024-09-16 16:38 ` [pve-devel] [RFC qemu-server 4/9] api: clone_vm: add check if " Daniel Kral
2024-11-29 14:23 ` Fiona Ebner
2025-01-22 13:18 ` Daniel Kral
2024-09-16 16:38 ` [pve-devel] [RFC qemu-server 5/9] api: create_vm: improve checks if storages for disks support " Daniel Kral
2024-09-16 16:38 ` [pve-devel] [RFC qemu-server 6/9] cloudinit: add check if storage for cloudinit disk supports " Daniel Kral
2024-09-16 16:38 ` [pve-devel] [RFC qemu-server 7/9] api: migrate_vm: improve check if target storages support " Daniel Kral
2024-11-29 14:23 ` Fiona Ebner
2025-01-22 13:19 ` Daniel Kral
2024-09-16 16:38 ` [pve-devel] [RFC qemu-server 8/9] api: importdisk: improve check if storage supports " Daniel Kral
2024-09-16 16:38 ` [pve-devel] [RFC qemu-server 9/9] restore_vm: improve checks " Daniel Kral
2024-11-29 14:23 ` Fiona Ebner
2025-01-22 13:21 ` Daniel Kral [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=eb80f82a-3f73-4f1f-9294-b0ace2034357@proxmox.com \
--to=d.kral@proxmox.com \
--cc=f.ebner@proxmox.com \
--cc=pve-devel@lists.proxmox.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.