From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from firstgate.proxmox.com (firstgate.proxmox.com [212.224.123.68]) by lore.proxmox.com (Postfix) with ESMTPS id BD9C01FF17A for ; Tue, 28 Oct 2025 11:50:12 +0100 (CET) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 0BE8B18296; Tue, 28 Oct 2025 11:50:43 +0100 (CET) Message-ID: Date: Tue, 28 Oct 2025 11:50:04 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird To: Proxmox VE development discussion , Friedrich Weber References: <20251024122705.93761-1-f.weber@proxmox.com> <82562115-907d-41d2-b3c1-ee8bbc91d1d8@proxmox.com> Content-Language: en-US From: Fiona Ebner In-Reply-To: <82562115-907d-41d2-b3c1-ee8bbc91d1d8@proxmox.com> X-Bm-Milter-Handled: 55990f41-d878-4baa-be0a-ee34c49e34d2 X-Bm-Transport-Timestamp: 1761648593001 X-SPAM-LEVEL: Spam detection results: 0 AWL -0.021 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DMARC_MISSING 0.1 Missing DMARC policy KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment RCVD_IN_VALIDITY_CERTIFIED_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to Validity was blocked. See https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more information. RCVD_IN_VALIDITY_RPBL_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to Validity was blocked. See https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more information. RCVD_IN_VALIDITY_SAFE_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to Validity was blocked. See https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more information. SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record URIBL_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to URIBL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more information. [ceph.com] Subject: Re: [pve-devel] [RFC qemu-server/storage 0/3] fix #5779: introduce guest hints to pass rxbounce flag to KRBD X-BeenThere: pve-devel@lists.proxmox.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Proxmox VE development discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Proxmox VE development discussion Cc: Thomas Lamprecht Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: pve-devel-bounces@lists.proxmox.com Sender: "pve-devel" Am 28.10.25 um 10:02 AM schrieb Friedrich Weber: > On 24/10/2025 14:27, Friedrich Weber wrote: >> [...] >> Obstacles I faced so far: >> >> - The biggest obstacle is that we need to update all callers of >> activate_volumes to pass guest hints where possible. This means that optimally >> all callers should be able to generate the guest hints. Right now, there is >> only the 'guest-ostype' hint which is taken from the VM config. Currently, this >> is not always available to the caller of activate_volumes, sometimes >> some extra work/refactoring would be needed to get it (e.g. see >> PVE::QemuServer::QemuImage::convert or PVE::QemuServer::clone_disk), >> so this needs quite some code changes, which I have not done in all cases in >> this RFC. >> >> - There are also some indirect callers of activate_volumes, e.g. via >> PVE::Storage::abs_filesystem_path or PVE::Storage::storage_migrate -- these >> would also need to be extended to accept hints (not done in this RFC) >> >> - Initially, to avoid having to modify all (direct+indirect) callers of >> activate_volumes, I thought I could pass the hints only at the few "relevant" >> call sites (i.e., when starting a VM), but then noticed that volumes may be >> activated by an action unrelated to a VM start (e.g. a clone), then stay >> active, and not be re-activated by a VM start. So if e.g. we do not pass the >> hints on clone, the KRBD volume would be mapped without rxbounce, stay active, >> and when starting the VM, a user could run into the original problem again. >> So we can't get away with only passing hints to the few relevant call sites, >> and actually need to pass them everywhere (where possible). >> > > Thomas and I discussed this point off-list: > > - to clarify: if a Windows guest volume was mapped with KRBD without > rxbounce (e.g. by a clone where the activate_volumes caller doesn't pass > $hints) and doesn't get unmapped, and then a VM start activates the > volumes again (passing $hints this time so we'd like to pass rxbounce), > RBDPlugin::map_volume will early-exit because the volume is already mapped: > > sub map_volume { > my ($class, $storeid, $scfg, $volname, $snapname) = @_; > > my ($vtype, $img_name, $vmid) = $class->parse_volname($volname); > > my $name = $img_name; > $name .= '@' . $snapname if $snapname; > > my $kerneldev = get_rbd_dev_path($scfg, $storeid, $name); > > return $kerneldev if -b $kerneldev; # already mapped > > [...] > } > > ... which is the VM will just use the guest volume without rxbounce and > the user can run into the issue. > > - we discussed whether, to avoid this, we could apply the rxbounce > option "on the fly" to an already-mapped volume. I looked a bit [1] and > didn't see any way to apply rxbounce to an already-mapped volume. > Calling `rbd map` again apparently just maps the volume a second time > which doesn't sound like a good idea, and an `rbd unmap` followed by an > `rbd map` (with rxbounce) is likely not safe either? > > [1] https://docs.ceph.com/en/reef/man/8/rbd/ I was also thinking along similar lines when reading that paragraph of the cover letter. Using unmap and then map again might be safe in certain situations like VM start, where there should be no other active users of the volume (from the top of my head, but would need to be checked in detail of course). That information is not available to the map_volume() implementation of course, so it would need to be part of the contract that either: 1. hints are only used in situations where a deactivate/unmap up front is safe or 2. that the callers using hints are required to ensure the volume is deactivated first or there is no guarantee that the hint is used. Approach 1. would have the advantage that the plugin could check if it even needs to do the unmap/deactivate and for some plugins/hints it might be able to be done on the fly. Question is, do we already have callers that would be unhappy with that requirement? As you described, the approach from the series has the requirement of knowing "early enough" about what hints we'll need, which is not always easy, but I haven't looked at it yet, just wanted to ask about this already :) _______________________________________________ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel