From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gate001.proxmox.com (gate001.proxmox.com [IPv6:2a0f:8001:1:32::40]) by lore.proxmox.com (Postfix) with ESMTPS id B9D931FF0E0 for ; Thu, 09 Jul 2026 16:54:40 +0200 (CEST) Received: from gate001.proxmox.com (localhost.localdomain [127.0.0.1]) by gate001.proxmox.com (Proxmox) with ESMTP id B5AE02148B; Thu, 09 Jul 2026 16:54:39 +0200 (CEST) From: Daniel Herzig To: "Daniel Kral" Subject: Re: [PATCH qemu-server] fix #7786: migrate: deactivate shared storage volumes of offline VMs In-Reply-To: References: <20260708073135.55426-1-d.herzig@proxmox.com> <87tsq8z3wp.fsf@proxmox.com> Date: Thu, 09 Jul 2026 16:54:06 +0200 Message-ID: <87pl0wz01d.fsf@proxmox.com> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Bm-Milter-Handled: 55990f41-d878-4baa-be0a-ee34c49e34d2 X-Bm-Transport-Timestamp: 1783608836661 X-SPAM-LEVEL: Spam detection results: 0 AWL 0.568 Adjusted score from AWL reputation of From: address DMARC_MISSING 0.1 Missing DMARC policy KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment (newer systems) SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record Message-ID-Hash: NTLMOTMD2LOOTZDUTTDYUGZJPC2I36SZ X-Message-ID-Hash: NTLMOTMD2LOOTZDUTTDYUGZJPC2I36SZ X-MailFrom: d.herzig@proxmox.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; loop; banned-address; emergency; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: pve-devel@lists.proxmox.com X-Mailman-Version: 3.3.10 Precedence: list List-Id: Proxmox VE development discussion List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: "Daniel Kral" writes: >>> >>> As discussed off-list, I wonder whether this can be a >>> >>> if (!$self->{running}) { >>> my $vollist = PVE::QemuServer::get_vm_volumes($conf); >>> PVE::Storage::deactivate_volumes($self->{storecfg}, $vollist); >>> } >>> >>> Just to be sure that there are no active volumes in the case of a >>> offline migration. >>> >> I guess a call to `deactivate_volumes` without restricting to shared >> storage (as in `deactivate_volumes_on_shared_storage()`) would also >> do. But in such a case we won't have complications anyway, as >> `sync_offline_local_volumes` is taking care of these with its own >> call to `deactivate_volumes` in the end. >> >> I'm not against shortening down the code (will see what I can >> do) -- but I'd like to keep the `eval->error->log` sequence and not >> bloat `phase1` at the same time, as it's such a lean sub. >> > > No hard feelings from my side, just thought that it might not hurt here > as with an offline migration it seems natural that the _local_ volumes > on the source node are deactivated with or without shared storage. > > But you're right, sync_offline_local_volumes() already does handle that > for some volumes. > >>> I wonder whether there are any assumptions in later migration steps >>> where this might break something that I'm not aware of? >> >> I'll double-check, but for now I think the issue is, that we >> currently don't do anything with the activation state in case of an >> offline migration on shared storage. Clearly the `if (!self->{running})` >> check is important, as it would cause issues with online-migrations, >> where volume deactivation is handled in a dedicated step. >> > > Yeah, it might be worth to investigate if we can reduce the amount of > time volumes are active when these are needed, e.g. after the disk > resize, clone, and disk move without deleting the original volume. I second on that. A definite deactivation of volumes on shared storage in the end of a migration should be in place for both offline and online migrations in any case, as we cannot exclude user-activated volumes either (which would cause the same pattern). We're actually already doing this 'sanity-check' for containers, but I guess there we already had more focus on it, as everything's about offline migrations with containers. > >>> >>>> + >>>> $self->phase1_remote($vmid) if $self->{opts}->{remote}; >>>> } >>>>