From nobody Sun May 19 23:34:09 2024 Delivered-To: importer@patchew.org Received-SPF: pass (zohomail.com: domain of redhat.com designates 205.139.110.61 as permitted sender) client-ip=205.139.110.61; envelope-from=libvir-list-bounces@redhat.com; helo=us-smtp-delivery-1.mimecast.com; Authentication-Results: mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of redhat.com designates 205.139.110.61 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=1576607829; cv=none; d=zohomail.com; s=zohoarc; b=Oz1EKVTP3TQyHSg0ByXR3sy91AnG9vqgXkejKzIKL/xGSGmbiu2pM5K08WehmN5+dePzWqGVrWspKzC6y2aJD28I9h8+mDk534OgZojUEzTZx8f+bV9g0W6jYWWzmT2VsaK9otN6hwO8S8l7dPCdIfWZ0uoKClv2sCKmRMVNAIQ= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1576607829; h=Content-Type:Content-Transfer-Encoding:Date:From:In-Reply-To:List-Subscribe:List-Post:List-Id:List-Archive:List-Help:List-Unsubscribe:MIME-Version:Message-ID:References:Sender:Subject:To; bh=1vUJk+pFZ+qZYpnVXI+QhLabgANIoBzGiS9HdyttQ0U=; b=MPvOC7M8pkQJoU3pgQNkDsKC2ny86Ear5095PIdYuurkfjVoL0ocDtL1POTzMlhArg8I78d9UFe9KpLPqDOjhWmvq8bkuMHG6nmtR2SV38WLS1maEVzHQM+J+0GLcH0pttfYipz8TiTWMbMdxUNKamtMXpvmD4Q1nYRr+NglB+Y= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of redhat.com designates 205.139.110.61 as permitted sender) smtp.mailfrom=libvir-list-bounces@redhat.com; dmarc=pass header.from= (p=none dis=none) header.from= Return-Path: Received: from us-smtp-delivery-1.mimecast.com (us-smtp-2.mimecast.com [205.139.110.61]) by mx.zohomail.com with SMTPS id 1576607829182931.732241362667; Tue, 17 Dec 2019 10:37:09 -0800 (PST) Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-104-p2EC9jQqMTeaRaKsYc9yRQ-1; Tue, 17 Dec 2019 13:37:06 -0500 Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 20970DB9A; Tue, 17 Dec 2019 18:37:00 +0000 (UTC) Received: from colo-mx.corp.redhat.com (colo-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.21]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 2440010016DA; Tue, 17 Dec 2019 18:36:59 +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 65E60104871; Tue, 17 Dec 2019 18:36:56 +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 xBHIZmfc001013 for ; Tue, 17 Dec 2019 13:35:48 -0500 Received: by smtp.corp.redhat.com (Postfix) id 6A4F17C83B; Tue, 17 Dec 2019 18:35:48 +0000 (UTC) Received: from angien.redhat.com (unknown [10.43.2.48]) by smtp.corp.redhat.com (Postfix) with ESMTP id E75537C81A for ; Tue, 17 Dec 2019 18:35:47 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1576607827; 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: in-reply-to:in-reply-to:references:references:list-id:list-help: list-unsubscribe:list-subscribe:list-post; bh=1vUJk+pFZ+qZYpnVXI+QhLabgANIoBzGiS9HdyttQ0U=; b=TDLFTcQR2XTY5J8XB5e/oXmdW/PznxGPQFrZmEt+zdtz37iHAmvUeuO3BL9ed4bBrzqkKG MDXjrSCgXTBVvgQgGt4U2HKzfXTyRtkXePw2Ht5e6/q4dnMhp6VXhotDKuToav8tUI6aeB oWK6cvDzwkJ13FqkA7WqCETa/KMEHjg= From: Peter Krempa To: libvir-list@redhat.com Date: Tue, 17 Dec 2019 19:35:40 +0100 Message-Id: <29651eea0ce9bb7cd60fd9cee7e6cc87eb63aeef.1576607634.git.pkrempa@redhat.com> In-Reply-To: References: MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 X-loop: libvir-list@redhat.com Subject: [libvirt] [PATCH 1/4] tests: storage: Use strict version of virStorageFileGetMetadata 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.84 on 10.5.11.22 X-MC-Unique: p2EC9jQqMTeaRaKsYc9yRQ-1 X-Mimecast-Spam-Score: 0 Content-Transfer-Encoding: quoted-printable X-ZohoMail-DKIM: pass (identity @redhat.com) Content-Type: text/plain; charset="utf-8" Pass in 'true' as '@report_broken' of virStorageFileGetMetadata to make it fail in the tests. The most important code paths (when starting the VM) expect this function to fail rather than silently return partial data. Switch the test to exercise this more important code path. Signed-off-by: Peter Krempa Reviewed-by: Michal Privoznik --- tests/virstoragetest.c | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/tests/virstoragetest.c b/tests/virstoragetest.c index 407378bab4..73717b0460 100644 --- a/tests/virstoragetest.c +++ b/tests/virstoragetest.c @@ -103,7 +103,7 @@ testStorageFileGetMetadata(const char *path, def->path =3D g_strdup(path); - if (virStorageFileGetMetadata(def, uid, gid, false) < 0) + if (virStorageFileGetMetadata(def, uid, gid, true) < 0) return NULL; return g_steal_pointer(&def); @@ -775,7 +775,7 @@ mymain(void) qcow2.expBackingStoreRaw =3D datadir "/bogus"; /* Qcow2 file with missing backing file but specified type */ - TEST_CHAIN(absqcow2, VIR_STORAGE_FILE_QCOW2, (&qcow2), EXP_WARN); + TEST_CHAIN(absqcow2, VIR_STORAGE_FILE_QCOW2, (&qcow2), EXP_FAIL); /* Rewrite qcow2 to a missing backing file, without backing type */ virCommandFree(cmd); @@ -785,7 +785,7 @@ mymain(void) ret =3D -1; /* Qcow2 file with missing backing file and no specified type */ - TEST_CHAIN(absqcow2, VIR_STORAGE_FILE_QCOW2, (&qcow2), EXP_WARN); + TEST_CHAIN(absqcow2, VIR_STORAGE_FILE_QCOW2, (&qcow2), EXP_FAIL); /* Rewrite qcow2 to use an nbd: protocol as backend */ virCommandFree(cmd); @@ -916,7 +916,7 @@ mymain(void) qcow2.expBackingStoreRaw =3D "qcow2"; /* Behavior of an infinite loop chain */ - TEST_CHAIN(absqcow2, VIR_STORAGE_FILE_QCOW2, (&qcow2), EXP_WARN); + TEST_CHAIN(absqcow2, VIR_STORAGE_FILE_QCOW2, (&qcow2), EXP_FAIL); /* Rewrite wrap and qcow2 to be mutually-referential loop */ virCommandFree(cmd); @@ -933,7 +933,7 @@ mymain(void) qcow2.expBackingStoreRaw =3D "wrap"; /* Behavior of an infinite loop chain */ - TEST_CHAIN(abswrap, VIR_STORAGE_FILE_QCOW2, (&wrap, &qcow2), EXP_WARN); + TEST_CHAIN(abswrap, VIR_STORAGE_FILE_QCOW2, (&wrap, &qcow2), EXP_FAIL); /* Rewrite qcow2 to use an rbd: protocol as backend */ virCommandFree(cmd); --=20 2.23.0 -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list From nobody Sun May 19 23:34:09 2024 Delivered-To: importer@patchew.org Received-SPF: pass (zohomail.com: domain of redhat.com designates 205.139.110.61 as permitted sender) client-ip=205.139.110.61; envelope-from=libvir-list-bounces@redhat.com; helo=us-smtp-delivery-1.mimecast.com; Authentication-Results: mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of redhat.com designates 205.139.110.61 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=1576607843; cv=none; d=zohomail.com; s=zohoarc; b=gS1zcW5JbYGjmwUTSa9h1lWFGr3dvbVNjhu/8wKSRV+yDhhzH1dfHuKQsj+7mPGmicxZQdOi5+BRA4kuerBwWHRasFZBpMxqptqzAb8lwIT6HCn8vjRgDkXy32pjr7WkQjuJdAza/KhOhhvdhpKUIviqOhIROTZTx5rAquJpubE= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1576607843; h=Content-Type:Content-Transfer-Encoding:Date:From:In-Reply-To:List-Subscribe:List-Post:List-Id:List-Archive:List-Help:List-Unsubscribe:MIME-Version:Message-ID:References:Sender:Subject:To; bh=9JsqLy+eJIz9T97nKOK7SmPHTwS7ryrK8Q6GfLpAeiA=; b=VJwkMuwkSTOwxXlmt6fnlQDgOx0BExHwx4wqytdFbwUN+UXTlYcskDPJyYzQhtZu3Qy1yocuLK8NpUNKYsASEpP0SepTgRWcCx+rtF+QdZgp/OTCuuTwoE/g9KTkzRBcj9e9JlnFVNAi/ht8xOwpiOnV6S6bBppXYwlTNwIorps= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of redhat.com designates 205.139.110.61 as permitted sender) smtp.mailfrom=libvir-list-bounces@redhat.com; dmarc=pass header.from= (p=none dis=none) header.from= Return-Path: Received: from us-smtp-delivery-1.mimecast.com (us-smtp-1.mimecast.com [205.139.110.61]) by mx.zohomail.com with SMTPS id 1576607843818198.04496079996193; Tue, 17 Dec 2019 10:37:23 -0800 (PST) Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-294-3gqwGuuGPpiXdk7g9Lo_cw-1; Tue, 17 Dec 2019 13:37:18 -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 78E16106F71D; Tue, 17 Dec 2019 18:37:11 +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 507695C1C3; Tue, 17 Dec 2019 18:37:11 +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 F2D8318089CD; Tue, 17 Dec 2019 18:37:10 +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 xBHIZnw0001018 for ; Tue, 17 Dec 2019 13:35:49 -0500 Received: by smtp.corp.redhat.com (Postfix) id 3B8087C839; Tue, 17 Dec 2019 18:35:49 +0000 (UTC) Received: from angien.redhat.com (unknown [10.43.2.48]) by smtp.corp.redhat.com (Postfix) with ESMTP id B83067C81A for ; Tue, 17 Dec 2019 18:35:48 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1576607842; 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: in-reply-to:in-reply-to:references:references:list-id:list-help: list-unsubscribe:list-subscribe:list-post; bh=9JsqLy+eJIz9T97nKOK7SmPHTwS7ryrK8Q6GfLpAeiA=; b=S4tkxnTXiJLbZKN206L9rVtVApdl3a16KadJ89Y8uXZRIquM8En1lpYYRNUBA8ERFz92UR OcyZ8shzFymVXB7XZm4COn808zb2Nzvp5Oefgvg3PTCWzavs4CHkLrHrpJop9ZBkCEj8yE v6G4snlxzg0pKRnidRHfGk1+NPAYmho= From: Peter Krempa To: libvir-list@redhat.com Date: Tue, 17 Dec 2019 19:35:41 +0100 Message-Id: <53a7d2c5e2404cd675fea65318c195072d84d893.1576607634.git.pkrempa@redhat.com> In-Reply-To: References: MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 X-loop: libvir-list@redhat.com Subject: [libvirt] [PATCH 2/4] tests: storage: Remove unused test modes 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 X-MC-Unique: 3gqwGuuGPpiXdk7g9Lo_cw-1 X-Mimecast-Spam-Score: 0 Content-Transfer-Encoding: quoted-printable X-ZohoMail-DKIM: pass (identity @redhat.com) Content-Type: text/plain; charset="utf-8" EXP_WARN and ALLOW_PROBE flags for the testStorageChain cases are no longer used so we can remove them. Signed-off-by: Peter Krempa Reviewed-by: Michal Privoznik --- tests/virstoragetest.c | 30 +++++++++--------------------- 1 file changed, 9 insertions(+), 21 deletions(-) diff --git a/tests/virstoragetest.c b/tests/virstoragetest.c index 73717b0460..93f3d1604a 100644 --- a/tests/virstoragetest.c +++ b/tests/virstoragetest.c @@ -242,8 +242,6 @@ struct _testFileData enum { EXP_PASS =3D 0, EXP_FAIL =3D 1, - EXP_WARN =3D 2, - ALLOW_PROBE =3D 4, }; struct testChainData @@ -288,25 +286,15 @@ testStorageChain(const void *args) fprintf(stderr, "call should have failed\n"); return -1; } - if (data->flags & EXP_WARN) { - if (virGetLastErrorCode() =3D=3D VIR_ERR_OK) { - fprintf(stderr, "call should have warned\n"); - return -1; - } - virResetLastError(); - if (virStorageFileChainGetBroken(meta, &broken) || !broken) { - fprintf(stderr, "call should identify broken part of chain\n"); - return -1; - } - } else { - if (virGetLastErrorCode()) { - fprintf(stderr, "call should not have warned\n"); - return -1; - } - if (virStorageFileChainGetBroken(meta, &broken) || broken) { - fprintf(stderr, "chain should not be identified as broken\n"); - return -1; - } + + if (virGetLastErrorCode()) { + fprintf(stderr, "call should not have reported error\n"); + return -1; + } + + if (virStorageFileChainGetBroken(meta, &broken) || broken) { + fprintf(stderr, "chain should not be identified as broken\n"); + return -1; } elt =3D meta; --=20 2.23.0 -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list From nobody Sun May 19 23:34:09 2024 Delivered-To: importer@patchew.org Received-SPF: pass (zohomail.com: domain of redhat.com designates 205.139.110.61 as permitted sender) client-ip=205.139.110.61; envelope-from=libvir-list-bounces@redhat.com; helo=us-smtp-delivery-1.mimecast.com; Authentication-Results: mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of redhat.com designates 205.139.110.61 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=1576607828; cv=none; d=zohomail.com; s=zohoarc; b=e7kNXzd7ZPcWnwgweZrFLo+/HWdrusDoiBFU7IUbUfYdpFrSHvEwoMyaRR5ILrreDmYpoZ/vO7L/JohHVTlc9i4Qqv1HrFM/k503y2cB1VW55Dlmzlj+gxQI42jfKndd8EI9w0bv4UuU4/Jnh8oJuzHhmVnxK0ea3ojsIv/r/Vo= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1576607828; h=Content-Type:Content-Transfer-Encoding:Date:From:In-Reply-To:List-Subscribe:List-Post:List-Id:List-Archive:List-Help:List-Unsubscribe:MIME-Version:Message-ID:References:Sender:Subject:To; bh=u+Bo7yRSmiig9I12SajUiMPkd3B4XiR8KgEbiXjvigY=; b=I3bjiXsUIXYJV75bUnMsrEnwslvBbs+XqXn354W97Cavf51BoESGyFiFaDwlO7QRe8z0nsbMyU2dROT991qLPEAca9CHOEUkl4g2CDyNG+Ivx1hHYuOL9yLQkTKW78EUhwIw4onjTMrxlt4DdZzIUCzpp3FEMWA61zPxjEZNGTI= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of redhat.com designates 205.139.110.61 as permitted sender) smtp.mailfrom=libvir-list-bounces@redhat.com; dmarc=pass header.from= (p=none dis=none) header.from= Return-Path: Received: from us-smtp-delivery-1.mimecast.com (us-smtp-1.mimecast.com [205.139.110.61]) by mx.zohomail.com with SMTPS id 1576607828315723.3356897297795; Tue, 17 Dec 2019 10:37:08 -0800 (PST) Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-398-__S0ezELPa-mn_8qx8wmyw-1; Tue, 17 Dec 2019 13:37:05 -0500 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id C13D6107B7EC; Tue, 17 Dec 2019 18:36:59 +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 977A160BE0; Tue, 17 Dec 2019 18:36:59 +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 C543118089C8; Tue, 17 Dec 2019 18:36:56 +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 xBHIZoFi001023 for ; Tue, 17 Dec 2019 13:35:50 -0500 Received: by smtp.corp.redhat.com (Postfix) id 0B9417C839; Tue, 17 Dec 2019 18:35:50 +0000 (UTC) Received: from angien.redhat.com (unknown [10.43.2.48]) by smtp.corp.redhat.com (Postfix) with ESMTP id 88CA67C81A for ; Tue, 17 Dec 2019 18:35:49 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1576607827; 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: in-reply-to:in-reply-to:references:references:list-id:list-help: list-unsubscribe:list-subscribe:list-post; bh=u+Bo7yRSmiig9I12SajUiMPkd3B4XiR8KgEbiXjvigY=; b=KWSyRblQElZo3n3FtWUrPb/OfBiLf8Ia+KeIMpemwTNcixnY6t73fEkw0H1n8Yfj8qYfpV KKl9EfZiyLblcCjBgOYs0Aj2RGOBZ07iPql6y5cbUDPzi/aqAuksNWrrHcrca4Wu2suTuR s1iWWBhOJYbNFCWJ5z5ycz1zkQgpRJM= From: Peter Krempa To: libvir-list@redhat.com Date: Tue, 17 Dec 2019 19:35:42 +0100 Message-Id: <9cd270d2497503eac620cefa51b432f95347ca65.1576607634.git.pkrempa@redhat.com> In-Reply-To: References: MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 X-loop: libvir-list@redhat.com Subject: [libvirt] [PATCH 3/4] util: storage: Don't treat files with missing backing store format as 'raw' 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.12 X-MC-Unique: __S0ezELPa-mn_8qx8wmyw-1 X-Mimecast-Spam-Score: 0 Content-Transfer-Encoding: quoted-printable X-ZohoMail-DKIM: pass (identity @redhat.com) Content-Type: text/plain; charset="utf-8" Assuming that the backing image format is raw is wrong when doing image detection: 1) In -drive mode qemu will still probe the image format of the backing image. This means it will try to open a backing file of the image which will fail if a more advanced security model is in use. 2) In blockdev mode the image will be opened as raw actually which is wrong since it might be qcow. Not opening the backing images will also end up in the guest seeing corrupted data. Rather than attempt to solve various corner cases when us assuming the storage file being raw and actually being right forbid startup when the guest image doesn't have the format specified in the metadata. https://bugzilla.redhat.com/show_bug.cgi?id=3D1588373 Signed-off-by: Peter Krempa Reviewed-by: Michal Privoznik --- src/util/virstoragefile.c | 21 +++++++++++++++++---- tests/virstoragetest.c | 2 +- 2 files changed, 18 insertions(+), 5 deletions(-) diff --git a/src/util/virstoragefile.c b/src/util/virstoragefile.c index 3a3de314b8..e280a646b7 100644 --- a/src/util/virstoragefile.c +++ b/src/util/virstoragefile.c @@ -4981,12 +4981,25 @@ virStorageFileGetMetadataRecurse(virStorageSourcePt= r src, goto cleanup; } - if (backingFormat =3D=3D VIR_STORAGE_FILE_AUTO) + backingStore->format =3D backingFormat; + + if (backingStore->format =3D=3D VIR_STORAGE_FILE_AUTO) { + /* Assuming the backing store to be raw can lead to failures. = We do + * it only when we must not report an error to prevent losing = VMs. + * Otherwise report an error. + */ + if (report_broken) { + virReportError(VIR_ERR_OPERATION_INVALID, + _("format of backing image '%s' of image '%= s' was not specified in the image metadata"), + src->backingStoreRaw, NULLSTR(src->path)); + return -1; + } + backingStore->format =3D VIR_STORAGE_FILE_RAW; - else if (backingFormat =3D=3D VIR_STORAGE_FILE_AUTO_SAFE) + } + + if (backingStore->format =3D=3D VIR_STORAGE_FILE_AUTO_SAFE) backingStore->format =3D VIR_STORAGE_FILE_AUTO; - else - backingStore->format =3D backingFormat; if ((ret =3D virStorageFileGetMetadataRecurse(backingStore, parent, uid, gid, diff --git a/tests/virstoragetest.c b/tests/virstoragetest.c index 93f3d1604a..b9d4a45cdd 100644 --- a/tests/virstoragetest.c +++ b/tests/virstoragetest.c @@ -751,7 +751,7 @@ mymain(void) .format =3D VIR_STORAGE_FILE_QCOW2, }; TEST_CHAIN(abswrap, VIR_STORAGE_FILE_QCOW2, - (&wrap_as_raw, &qcow2_as_raw), EXP_PASS); + (&wrap_as_raw, &qcow2_as_raw), EXP_FAIL); /* Rewrite qcow2 to a missing backing file, with backing type */ virCommandFree(cmd); --=20 2.23.0 -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list From nobody Sun May 19 23:34:09 2024 Delivered-To: importer@patchew.org Received-SPF: pass (zohomail.com: domain of redhat.com designates 207.211.31.81 as permitted sender) client-ip=207.211.31.81; envelope-from=libvir-list-bounces@redhat.com; helo=us-smtp-delivery-1.mimecast.com; Authentication-Results: mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of redhat.com designates 207.211.31.81 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=1576607844; cv=none; d=zohomail.com; s=zohoarc; b=GqNYyZzqci4rPV+KPb/c0RKrZ6rPIYkitaWbZnMCD2Y5bkFUa7w2CgjJhN/l90+fUklMgrpWOcp8yKkAAk5s0aGtXir5+FOcAUCohcDNecG5Wz9hkKZleK6VFf561/CzEq4rYEx6GVeTVjzp6pmauQjC5jdGjfwaIYFICSG7RwI= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1576607844; h=Content-Type:Content-Transfer-Encoding:Date:From:In-Reply-To:List-Subscribe:List-Post:List-Id:List-Archive:List-Help:List-Unsubscribe:MIME-Version:Message-ID:References:Sender:Subject:To; bh=VPIib9PvNZ+YLnoW/4RpeI2ONCJKOoatu/R4JDEf7kQ=; b=BKWIqZ5PM0TiajDmvvhdPALr3g8bgR2udDu7GydUEY1xeCE6psaer8XGFtzpV8ER/hWoRrjVY774BF/1TchXOwgJyzd6CrWGJpEK7zUctqQsMrgl3Il8HR8r7Qt1vliyC3YMmpNrq+xHcdsqmenhMg7ji5ndWvvnYL08gBLdkNs= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of redhat.com designates 207.211.31.81 as permitted sender) smtp.mailfrom=libvir-list-bounces@redhat.com; dmarc=pass header.from= (p=none dis=none) header.from= Return-Path: Received: from us-smtp-delivery-1.mimecast.com (us-smtp-1.mimecast.com [207.211.31.81]) by mx.zohomail.com with SMTPS id 1576607844213200.8838928923949; Tue, 17 Dec 2019 10:37:24 -0800 (PST) Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-247-fvTFGKJiOrW4fuBLD7-6GQ-1; Tue, 17 Dec 2019 13:37:21 -0500 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 1D4A48026A9; Tue, 17 Dec 2019 18:37:15 +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 EC74B5D9E2; Tue, 17 Dec 2019 18:37:14 +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 A66BC18089D6; Tue, 17 Dec 2019 18:37:14 +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 xBHIZo0C001028 for ; Tue, 17 Dec 2019 13:35:50 -0500 Received: by smtp.corp.redhat.com (Postfix) id D1CAA7C839; Tue, 17 Dec 2019 18:35:50 +0000 (UTC) Received: from angien.redhat.com (unknown [10.43.2.48]) by smtp.corp.redhat.com (Postfix) with ESMTP id 59ACE7C81A for ; Tue, 17 Dec 2019 18:35:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1576607842; 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: in-reply-to:in-reply-to:references:references:list-id:list-help: list-unsubscribe:list-subscribe:list-post; bh=VPIib9PvNZ+YLnoW/4RpeI2ONCJKOoatu/R4JDEf7kQ=; b=N01uaVUuNrq3qm3CrYcMWs5tKIj69PSiKyDkRJrXOofM4EHQI0VCxAT/D3ebUgzt0DgYZJ FUTIz4EqvU5lgLTIg+jF07C59OPxNdDfbf6kzeOKZpmgEG236Us8F74G5c0eB3BufeIGKm gasRcwVR2uujNEUM4Co2EgMmQjnY5c0= From: Peter Krempa To: libvir-list@redhat.com Date: Tue, 17 Dec 2019 19:35:43 +0100 Message-Id: In-Reply-To: References: MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 X-loop: libvir-list@redhat.com Subject: [libvirt] [PATCH 4/4] kbase: Add document outlining backing chain XML config and troubleshooting 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.14 X-MC-Unique: fvTFGKJiOrW4fuBLD7-6GQ-1 X-Mimecast-Spam-Score: 0 Content-Transfer-Encoding: quoted-printable X-ZohoMail-DKIM: pass (identity @redhat.com) Content-Type: text/plain; charset="utf-8" Signed-off-by: Peter Krempa Reviewed-by: Michal Privoznik --- docs/kbase.html.in | 4 + docs/kbase/backing_chains.rst | 185 ++++++++++++++++++++++++++++++++++ 2 files changed, 189 insertions(+) create mode 100644 docs/kbase/backing_chains.rst diff --git a/docs/kbase.html.in b/docs/kbase.html.in index a5504a540f..c156414c41 100644 --- a/docs/kbase.html.in +++ b/docs/kbase.html.in @@ -25,6 +25,10 @@
RPM deployment
Explanation of the different RPM packages and illustration of which to pick for installation
+ +
Backing chain management=
+
Explanation of how disk backing chain specification impacts li= bvirt's + behaviour and basic troubleshooting steps of disk problems.
diff --git a/docs/kbase/backing_chains.rst b/docs/kbase/backing_chains.rst new file mode 100644 index 0000000000..ec8f1b33b8 --- /dev/null +++ b/docs/kbase/backing_chains.rst @@ -0,0 +1,185 @@ +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D +Disk image chains +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D + +Modern disk image formats allow users to create an overlay on top of an +existing image which will be the target of the new guest writes. This allo= ws us +to do snapshots of the disk state of a VM efficiently. The following text +describes how libvirt manages such image chains and some problems which can +occur. Note that many of the cases mentioned below are currently only rele= vant +for the qemu driver. + +.. contents:: + +Domain XML image and chain specification +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D + +Disk image chains can be partially or fully configured in the domain XML. = The +basic approach is to use the ```` elements in the configurat= ion. + +The ```` elements present in the live VM xml represent the a= ctual +topology that libvirt knows of. + +Basic disk setup +---------------- + +Any default configuration or example usually refers only to the top (activ= e) +image of the backing chain. + +:: + + + + + +
+ + +This configuration will prompt libvirt to detect the backing image of the = source +image and recursively do the same thing until the end of the chain. + +Importance of properly setup backing chain +------------------------------------------ + +The disk image locations are used by libvirt to properly setup the security +system used on the host so that the hypervisor can access the files and po= ssibly +also directly to configure the hypervisor to use the appropriate images. T= hus +it's important to properly setup the formats and paths of the backing imag= es. + +Image detection caveats +----------------------- + +Detection of the backing chain requires libvirt to read and understand the +``backing file`` field recorded in the image metadata and also being able = to +recurse and read the backing file. Due to security implications libvirt +will not attempt to detect the format of the backing image if the image me= tadata +don't contain it. + +Libvirt also may not support a network disk storage technology and thus ma= y be +unable to visit and detect backing chains on such storage. This may result= in +the backing chain present in the live XML to look incomplete or some opera= tions +not being possible. To prevent this it's possible to specify the image met= adata +explicitly in the XML. + +Advanced backing chain specifications +------------------------------------- + +To specify the topology of disk images explicitly the following XML +specification can be used: + +:: + + + + + + + + + + + + + + + + + + + + + + +
+ + +This makes libvirt follow the settings as configured in the XML. Note that= this +is supported only when the https://libvirt.org/formatdomaincaps.html#featu= reBackingStoreInput +capability is present. + +An empty ```` element signals the end of the chain. Using t= his +will prevent libvirt or qemu from probing the backing chain. + +Note that it's also possible to partially specify the chain in the XML but= omit +the terminating element. This will result into probing from the last speci= fied +```` + + +Manual image creation +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D + +When creating disk images manually outside of libvirt it's important to cr= eate +them properly so that they work with libvirt as expected. The created disk +images must contain the format of the backing image in the metadata. This +means that the **-F** parameter of ``qemu-img`` must always be used. + +Troubleshooting +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D + +Few common problems which occur when managing chains of disk images. + +VM refuses to start due to misconfigured backing store format +------------------------------------------------------------- + +This problem happens on VMs where the backing chain was created manually o= utside +of libvirt and can have multiple symptoms: + +- permission denied error reported on a backing image +- ``format of backing image '%s' of image '%s' was not specified in the im= age metadata`` error reported +- disk image looking corrupt inside the guest + +The cause of the above problem is that the image metadata does not record = the +format of the backing image along with the location of the image. When the +format is not specified libvirt or qemu would have to do image format prob= ing +which is insecure to do as a mallicious guest could rewrite the header of = the +disk leading to access of host files. Libvirt thus does not try to assume +the format of the backing image. The following command can be used to chec= k if +the image has backing image format specified: + +:: + + $ qemu-img info /tmp/copy4.qcow2 + image: /tmp/copy4.qcow2 + file format: qcow2 + virtual size: 10 MiB (10485760 bytes) + disk size: 196 KiB + cluster_size: 65536 + backing file: copy3.qcow2 (actual path: /tmp/copy3.qcow2) + backing file format: qcow2 + Format specific information: + compat: 1.1 + lazy refcounts: false + refcount bits: 16 + corrupt: false + +If the ``backing file format:`` field is missing above the format was not +specified properly. The image can be fixed by the following command: + +:: + + qemu-img rebase -f $IMAGE_FORMAT -F $BACKING_IMAGE_FORMAT -b $BACKING_IMA= GE_PATH $IMAGE_PATH + +It is important to fill out ``$BACKING_IMAGE_FORMAT`` and ``$IMAGE_FORMAT`` +properly. ``$BACKING_IMAGE_PATH`` should be specified as a full absolute p= ath. +If relative referencing of the backing image is desired, the path must be +relative to the location of image described by ``$IMAGE_PATH``. + +Missing images reported after after moving disk images into a different pa= th +--------------------------------------------------------------------------= -- + +The path to the backing image which is recorded in the image metadata often +contains a full path to the backing image. This is the default libvirt-cre= ated +image configuration. When such images are moved to a different location the +top image will no longer point to the correct image. + +To fix such issue you can either fully specify the image chain in the doma= in XML +as pointed out above or the following ``qemu-img`` command can be used: + +:: + + qemu-img rebase -u -f $IMAGE_FORMAT -F $BACKING_IMAGE_FORMAT -b $BACKING_= IMAGE_PATH $IMAGE_PATH + +It is important to fill out ``$BACKING_IMAGE_FORMAT`` and ``$IMAGE_FORMAT`` +properly. ``$BACKING_IMAGE_PATH`` should be specified as a full absolute p= ath. +If relative referencing of the backing image is desired, the path must be +relative to the location of image described by ``$IMAGE_PATH``. --=20 2.23.0 -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list