public inbox for pve-devel@lists.proxmox.com
 help / color / mirror / Atom feed
From: Thomas Lamprecht <t.lamprecht@proxmox.com>
To: Proxmox VE development discussion <pve-devel@lists.proxmox.com>,
	Daniel Kral <d.kral@proxmox.com>
Subject: Re: [pve-devel] [PATCH qemu-server] fix #5284: diallow moving vm disks to storages not meant for images
Date: Fri, 6 Sep 2024 18:44:39 +0200	[thread overview]
Message-ID: <69a860e8-8364-48af-8022-879a5d87a54f@proxmox.com> (raw)
In-Reply-To: <20240829142633.158766-1-d.kral@proxmox.com>

Am 29/08/2024 um 16:26 schrieb Daniel Kral:
> Adds a check if the target storage of a VM disk move between two
> different storages supports the content type 'images'. Without the
> check, it will move the disk image to storages which do not support VM
> images, which causes the VM to fail at startup (for any non-unused
> disks).
> 
> Signed-off-by: Daniel Kral <d.kral@proxmox.com>
> ---
> There is a content type check for any used volume (e.g. 'scsi0', ...) at
> PVE/QemuServer.pm:3964 in the subroutine `config_to_command` which will
> (at least) make the VM fail to start unless the volumes are moved to a
> storage that supports images again.
> 
> Also, just as a note, moving the disk to storages that do not support
> the `vdisk_alloc` method in the storage plugin (like PBS) also
> rightfully fail before and after this change.
> 
>  PVE/API2/Qemu.pm | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/PVE/API2/Qemu.pm b/PVE/API2/Qemu.pm
> index d25a79fe..b6ba9d21 100644
> --- a/PVE/API2/Qemu.pm
> +++ b/PVE/API2/Qemu.pm
> @@ -4409,6 +4409,9 @@ __PACKAGE__->register_method({
>  	    );
>  	} elsif ($storeid) {
>  	    $rpcenv->check($authuser, "/storage/$storeid", ['Datastore.AllocateSpace']);
> +	    my $scfg = PVE::Storage::storage_config($storecfg, $storeid);
> +	    raise_param_exc({ storage => "storage '$storeid' does not support vm images" })
> +		if !$scfg->{content}->{images};

Hmm, code wise it looks OK, but not so sure if this is the best place
to check, I'd rather look into either moving this into the $load_and_check_move
closure or into the PVE::QemuServer::clone_disk method, avoiding such an issue
for all other call sites too, albeit one would need to evaluate those call sites
if it does not break an existing usecase when disallowing this everywhere.

btw. did you check if containers are also affected by this bug?

>  
>  	    $load_and_check_move->(); # early checks before forking/locking
>  



_______________________________________________
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel


  parent reply	other threads:[~2024-09-06 16:44 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-08-29 14:26 Daniel Kral
2024-09-02  9:15 ` Filip Schauer
2024-09-06 16:44 ` Thomas Lamprecht [this message]
2024-09-09 12:23   ` Daniel Kral
2024-09-17  8:30 ` Daniel Kral

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=69a860e8-8364-48af-8022-879a5d87a54f@proxmox.com \
    --to=t.lamprecht@proxmox.com \
    --cc=d.kral@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Service provided by Proxmox Server Solutions GmbH | Privacy | Legal