From nobody Tue Sep 9 03:13:57 2025 Delivered-To: importer@patchew.org Received-SPF: pass (zohomail.com: domain of lists.libvirt.org designates 8.43.85.245 as permitted sender) client-ip=8.43.85.245; envelope-from=devel-bounces@lists.libvirt.org; helo=lists.libvirt.org; Authentication-Results: mx.zohomail.com; dkim=fail; spf=pass (zohomail.com: domain of lists.libvirt.org designates 8.43.85.245 as permitted sender) smtp.mailfrom=devel-bounces@lists.libvirt.org; dmarc=pass(p=reject dis=none) header.from=lists.libvirt.org ARC-Seal: i=1; a=rsa-sha256; t=1747323057; cv=none; d=zohomail.com; s=zohoarc; b=O5rbdeKfyjQTq10KNUQU6PdYTOeI2tI6GSc+Nd+kGMeAcIsfyNgRP1hKr4nRKxSmrjmYUsy8Xh9jzInQ1flrjfhS4NHQuT/7GYU34YXymUIYP4xHr1SH6jXJ/l/ZXbJXEpS2kvdgDRpKmKb1mI5DHw6K2vyeDMvyplFBzrPyPZ0= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1747323057; h=Content-Type:Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:In-Reply-To:List-Subscribe:List-Post:List-Id:List-Archive:List-Help:List-Unsubscribe:MIME-Version:Message-ID:Reply-To:Reply-To:References:Subject:Subject:To:To:Message-Id; bh=joGhFqbkXJIwGYcCfM9Cetjqc11U/NTsRZEO4M0z1Cg=; b=N59CNlgP1yKRLGUTtH+QkClwXZxrXzwadXZadxKTCh2hIRfq/jZ3Wib2//nHN6Gi/ayWikwgaUBYQ7cl9SqmcSQdpbHrOmjtAWUMCVSRgPqz6MjO3TsGjqh/6YdoIXQskGGDPO3yRrjmTUvsNroX++I53UcGtnLkyl4einTrESE= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=fail; spf=pass (zohomail.com: domain of lists.libvirt.org designates 8.43.85.245 as permitted sender) smtp.mailfrom=devel-bounces@lists.libvirt.org; dmarc=pass header.from= (p=reject dis=none) Return-Path: Received: from lists.libvirt.org (lists.libvirt.org [8.43.85.245]) by mx.zohomail.com with SMTPS id 1747323057534896.5316387771711; Thu, 15 May 2025 08:30:57 -0700 (PDT) Received: by lists.libvirt.org (Postfix, from userid 996) id 90A6D144D; Thu, 15 May 2025 11:30:56 -0400 (EDT) Received: from lists.libvirt.org (localhost [IPv6:::1]) by lists.libvirt.org (Postfix) with ESMTP id EBC4413ED; Thu, 15 May 2025 11:29:28 -0400 (EDT) Received: by lists.libvirt.org (Postfix, from userid 996) id 2A1E113CC; Thu, 15 May 2025 11:29:23 -0400 (EDT) Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.libvirt.org (Postfix) with ESMTPS id 401D41284 for ; Thu, 15 May 2025 11:29:20 -0400 (EDT) Received: from mx-prod-mc-06.mail-002.prod.us-west-2.aws.redhat.com (ec2-35-165-154-97.us-west-2.compute.amazonaws.com [35.165.154.97]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-93-drqy0A2oPpySI2e-ig6wMw-1; Thu, 15 May 2025 11:29:16 -0400 Received: from mx-prod-int-08.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-08.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.111]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mx-prod-mc-06.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id A51121800771 for ; Thu, 15 May 2025 15:29:13 +0000 (UTC) Received: from speedmetal.lan (unknown [10.44.22.37]) by mx-prod-int-08.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id A1A6F1805B03; Thu, 15 May 2025 15:29:12 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on lists.libvirt.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, MAILING_LIST_MULTI,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H5, RCVD_IN_MSPIKE_WL,RCVD_IN_VALIDITY_RPBL_BLOCKED, RCVD_IN_VALIDITY_SAFE_BLOCKED,SPF_HELO_NONE autolearn=unavailable autolearn_force=no version=3.4.4 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1747322960; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=+/1+/UBTWCi82wETvatVqRDQdOjwY8nG92S0AwMQpEk=; b=ZrliUqyIXvvoQFjo8yKoXrig7I5P3lKXSc60MQ53NgSafkq0qlg7jmNF2e6qYliLvgDJFV wvAPDVgoXUD4SwOs6pbL/rvVADGgch5VkQKLQUNe+dLm5A9tgLpuQ7DAAhPFWC0ih2m4eL z9assYaJRfOun8ytQVKm+2q+ZiBhjE4= X-MC-Unique: drqy0A2oPpySI2e-ig6wMw-1 X-Mimecast-MFC-AGG-ID: drqy0A2oPpySI2e-ig6wMw_1747322955 To: devel@lists.libvirt.org Subject: [PATCH 01/17] qemuProcessStartWithMemoryState: Don't setup qemu for incoming migration when reverting internal snapshot Date: Thu, 15 May 2025 17:28:46 +0200 Message-ID: In-Reply-To: References: MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.4.1 on 10.30.177.111 X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: TzhVvUumxD2OxeZhcZ2TQs-6Cz0XrGFKVtTJpytzbG4_1747322955 X-Mimecast-Originator: redhat.com Content-Transfer-Encoding: quoted-printable Message-ID-Hash: CVWLKJ2EOVXUKKWOQOLWY73GGSGV3V3C X-Message-ID-Hash: CVWLKJ2EOVXUKKWOQOLWY73GGSGV3V3C X-MailFrom: pkrempa@redhat.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-config-1; header-match-config-2; header-match-config-3; header-match-devel.lists.libvirt.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; suspicious-header CC: Peter Krempa X-Mailman-Version: 3.2.2 Precedence: list List-Id: Development discussions about the libvirt library & tools Archived-At: List-Archive: List-Help: List-Post: List-Subscribe: List-Unsubscribe: From: Peter Krempa via Devel Reply-To: Peter Krempa X-ZohoMail-DKIM: fail (Header signature does not verify) X-ZM-MESSAGEID: 1747323059756116600 Content-Type: text/plain; charset="utf-8" From: Peter Krempa The memory/device state of the VM for an internal snapshot is restored by qemu itself via a QMP command and is taken from the qcow2 image, thus we don't actually do any form of incoming migration. Commit 5b324c0a739fe00 which refactored the setup of the incoming migration state didn't take the above into account and inadvertently caused that qemu is being started with '-incoming defer' also when libvirt would want to revert an internal snapshot. Now when qemu expects incoming migration it doesn't activate the block backends as that would cause locking problems and image inconsistency, but also doesn't allow the use of the images. Since the block backends are not activated qemu then thinks that they don't actually support internal snapshots and reports: error: operation failed: load of internal snapshot 'foo1' job failed: Dev= ice 'libvirt-1-format' is writable but does not support snapshots Due to the above bug it's not possible to revert to internal snapshots in libvirt-11.2 and libvirt-11.3. Fixes: 5b324c0a739fe00cbec209219db4488742492112 Resolves: https://issues.redhat.com/browse/RHEL-88747 Closes: https://gitlab.com/libvirt/libvirt/-/issues/771 Signed-off-by: Peter Krempa Reviewed-by: Jim Fehlig --- src/qemu/qemu_process.c | 10 +++++++--- 1 file changed, 7 insertions(+), 3 deletions(-) diff --git a/src/qemu/qemu_process.c b/src/qemu/qemu_process.c index 1af91c5909..5f2203dd13 100644 --- a/src/qemu/qemu_process.c +++ b/src/qemu/qemu_process.c @@ -8636,9 +8636,13 @@ qemuProcessStartWithMemoryState(virConnectPtr conn, /* The fd passed to qemuProcessIncomingDefNew is used to create the mi= gration * URI, so it must be called after starting the decompression program. */ - incoming =3D qemuProcessIncomingDefNew(driver, vm, NULL, "stdio", fd, = path, data, migParams); - if (!incoming) - return -1; + if (!snapshot) { + /* Internal snapshots are reverted by a QMP command after qemu is = started, + * so we don't actually want to setup incoming migration. */ + if (!(incoming =3D qemuProcessIncomingDefNew(driver, vm, NULL, "st= dio", + fd, path, data, migPara= ms))) + return -1; + } /* No cookie means libvirt which saved the domain was too old to mess = up * the CPU definitions. --=20 2.49.0