From nobody Mon Feb 9 12:25:20 2026 Delivered-To: importer@patchew.org Received-SPF: pass (zohomail.com: domain of redhat.com designates 170.10.129.124 as permitted sender) client-ip=170.10.129.124; envelope-from=libvir-list-bounces@redhat.com; helo=us-smtp-delivery-124.mimecast.com; Authentication-Results: mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=libvir-list-bounces@redhat.com; dmarc=pass(p=none dis=none) header.from=redhat.com ARC-Seal: i=1; a=rsa-sha256; t=1643632504; cv=none; d=zohomail.com; s=zohoarc; b=S1i7ttgBRCBqkfhdIYgtWPcVU1uOzOMliyb2l4zRGcSN0PHIuAR/CGrACFSFjcIO2v13FUuDD7ivbhblvXWZobcbljeA/jfoZYn3xT+tzjLgTxnJWcvvPPuiVGbHstiJtuzIpqmcrQf8XbyUik9XZmZXSng7RJZUuHS42cnZfSo= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1643632504; h=Content-Type:Content-Transfer-Encoding:Date:From:List-Subscribe:List-Post:List-Id:List-Archive:List-Help:List-Unsubscribe:MIME-Version:Message-ID:Sender:Subject:To; bh=TfncdrUuNB3KluAeQF21fl1MvtdoDzt0aUbjDCoAiZw=; b=j9ncrEkOrG3CKqE8YWOjvRvs7qjwBSgrkdMt5xT4qXkBsWj8PhZEwkEeMj+nL+z9PSbqAEiFihOE5VZd04NqlJ65RINCpQbFFGu6PiC+UvT1Y9WRk7LpD/dGJZPhuY4WZTs+KX5wyMbgD1+juR59ihJgxBbrM6EhHH2OnL/IEAA= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=libvir-list-bounces@redhat.com; dmarc=pass header.from= (p=none dis=none) Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by mx.zohomail.com with SMTPS id 1643632504411268.1693794387551; Mon, 31 Jan 2022 04:35:04 -0800 (PST) Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-177-LP7ZDn96PomdEA2Dvz8i3w-1; Mon, 31 Jan 2022 07:34:59 -0500 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 26A6E8143E5; Mon, 31 Jan 2022 12:34:53 +0000 (UTC) Received: from colo-mx.corp.redhat.com (colo-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.20]) by smtp.corp.redhat.com (Postfix) with ESMTPS id A14777B6FB; Mon, 31 Jan 2022 12:34:52 +0000 (UTC) Received: from lists01.pubmisc.prod.ext.phx2.redhat.com (lists01.pubmisc.prod.ext.phx2.redhat.com [10.5.19.33]) by colo-mx.corp.redhat.com (Postfix) with ESMTP id B64B81809CB8; Mon, 31 Jan 2022 12:34:51 +0000 (UTC) Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) by lists01.pubmisc.prod.ext.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id 20VCYomk025997 for ; Mon, 31 Jan 2022 07:34:50 -0500 Received: by smtp.corp.redhat.com (Postfix) id 74CF784638; Mon, 31 Jan 2022 12:34:50 +0000 (UTC) Received: from localhost.localdomain (unknown [10.40.193.157]) by smtp.corp.redhat.com (Postfix) with ESMTP id E96868462C for ; Mon, 31 Jan 2022 12:34:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1643632502; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding:list-id:list-help: list-unsubscribe:list-subscribe:list-post; bh=TfncdrUuNB3KluAeQF21fl1MvtdoDzt0aUbjDCoAiZw=; b=WBoJS2tiCEIrYl6nE6yzlUj+XYSVlLHIdRC5p7tq+WCsJWOWqAIZc6OonhBF+5HL3lyPkc bUVGQ7a8mPOkbMqaN+gnoK5kJmxd0FORZCyhXZXY8kxlNt+q5I8xrLvBdZnEm/xKuHkFiF G1eOFRkYQyPLeykohGS8Gf4AtE0QIUk= X-MC-Unique: LP7ZDn96PomdEA2Dvz8i3w-1 From: Michal Privoznik To: libvir-list@redhat.com Subject: [PATCH] qemu: Validate domain definition even on migration Date: Mon, 31 Jan 2022 13:34:29 +0100 Message-Id: <98effbbb355776bc3bb7ad41ceae6522cdf1cbe5.1643632395.git.mprivozn@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 X-loop: libvir-list@redhat.com X-BeenThere: libvir-list@redhat.com X-Mailman-Version: 2.1.12 Precedence: junk List-Id: Development discussions about the libvirt library & tools List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: libvir-list-bounces@redhat.com Errors-To: libvir-list-bounces@redhat.com X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=libvir-list-bounces@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Transfer-Encoding: quoted-printable X-ZohoMail-DKIM: pass (identity @redhat.com) X-ZM-MESSAGEID: 1643632506636100006 Content-Type: text/plain; charset="utf-8" When we are about to spawn QEMU, we validate the domain definition against qemuCaps. Except when domain is/was already running before (i.e. on incoming migration, snapshots, resume from a file). However, especially on incoming migration it may happen that the destination QEMU is different to the source QEMU, e.g. the destination QEMU may have some devices disabled. And we have a function that validates devices/features requested in domain XML against the desired QEMU capabilities (aka qemuCaps) - it's virDomainDefValidate() which calls qemuValidateDomainDef() and qemuValidateDomainDeviceDef() subsequently. But the problem here is that the validation function is explicitly skipped over in specific scenarios (like incoming migration, restore from a snapshot or previously saved file). This in turn means that we may spawn QEMU and request device/features it doesn't support. When that happens QEMU fails to load migration stream: qemu-kvm: ... 'virtio-mem-pci' is not a valid device model name (NB, while the example shows one particular device, the problem is paramount) This problem is easier to run into since we are slowly moving validation from qemu_command.c into said validation functions. The solution is simple: do the validation in all cases. And while it may happen that users would be unable to migrate/restore a guest due to a bug in our validator, spawning QEMU without validation is worse (especially when you consider that users can supply their own XMLs for migrate/restore operations - these were never validated). Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=3D2048435 Signed-off-by: Michal Privoznik --- Technically, this is v2 of: https://listman.redhat.com/archives/libvir-list/2022-January/msg01307.html but since it implements completely different approach I've reset the counter. src/qemu/qemu_process.c | 6 +----- 1 file changed, 1 insertion(+), 5 deletions(-) diff --git a/src/qemu/qemu_process.c b/src/qemu/qemu_process.c index c13280c8f3..ea586e54c1 100644 --- a/src/qemu/qemu_process.c +++ b/src/qemu/qemu_process.c @@ -5399,11 +5399,7 @@ qemuProcessStartValidate(virQEMUDriver *driver, =20 } =20 - /* Checks below should not be executed when starting a qemu process fo= r a - * VM that was running before (migration, snapshots, save). It's more - * important to start such VM than keep the configuration clean */ - if ((flags & VIR_QEMU_PROCESS_START_NEW) && - virDomainDefValidate(vm->def, 0, driver->xmlopt, qemuCaps) < 0) + if (virDomainDefValidate(vm->def, 0, driver->xmlopt, qemuCaps) < 0) return -1; =20 if (qemuProcessStartValidateGraphics(vm) < 0) --=20 2.34.1