From nobody Wed May 1 17:41:19 2024 Delivered-To: importer@patchew.org Received-SPF: pass (zohomail.com: domain of redhat.com designates 170.10.133.124 as permitted sender) client-ip=170.10.133.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.133.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=1638543755; cv=none; d=zohomail.com; s=zohoarc; b=Dz6B5gCXTbgGmyYs4gyEfcj3MGnUKSwUOueAnC7AYRGZSA8wOK0Dpmm+XPOIcUT9SuDJ9+YfGcQmJ6YSy88vgOOg+1yxWK+4STUN5UE/rTm6OkJlNSeAw1rGCVSPuCYYBCDRtgX47kgnDItcV51FKssTITUExbVjc8LzVX0CGKk= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1638543755; 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=36vW3jJHsS2A12/+vEH7Nldp0oTI5CHKjfo7vH1YLSU=; b=El1X3S1Li+dYrGk1G+/hyEyuaeXzAS5qNArFtT2Un0JrpkdaWk1bCmLjTIYUsaZd27wDApAfmAO5dJpxoXWuCE5wYzqxurAcDfbSMMz36cQkyKa6rlmDJXPMoJC4ON1TZbMIUOkBBfcCEu5HLUnD2n7NvUWnQHa/NPiRRLmBspg= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of redhat.com designates 170.10.133.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.133.124]) by mx.zohomail.com with SMTPS id 1638543755452894.5868321797916; Fri, 3 Dec 2021 07:02:35 -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-44-mwHZCAF6MYmdBOrohZYYGA-1; Fri, 03 Dec 2021 10:02:29 -0500 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 6A7AA18B9F1D; Fri, 3 Dec 2021 15:02:16 +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 4A7D35F4E1; Fri, 3 Dec 2021 15:02:16 +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 1DBCE1802E34; Fri, 3 Dec 2021 15:02:16 +0000 (UTC) Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) by lists01.pubmisc.prod.ext.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id 1B3F2B3S030701 for ; Fri, 3 Dec 2021 10:02:11 -0500 Received: by smtp.corp.redhat.com (Postfix) id F2DA85DAA5; Fri, 3 Dec 2021 15:02:10 +0000 (UTC) Received: from speedmetal.lan (unknown [10.40.208.10]) by smtp.corp.redhat.com (Postfix) with ESMTP id 526CC5D9D5 for ; Fri, 3 Dec 2021 15:02:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1638543754; 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=36vW3jJHsS2A12/+vEH7Nldp0oTI5CHKjfo7vH1YLSU=; b=Ih3WE8Fhm8SBRcugh5OgxzSFJwkqg7wabl8VwmTfOGkaIkDDw7/ACVGdBWVLHjrfvVTkfJ HigqV8wWu1YWzeMCjR//Iyo27zABBX9ZtjRX274fxySHPED359I3BkAVVydExAeOnlEscS YsrLlIoov0vY3C8nmz6lkyETS6+cs+4= X-MC-Unique: mwHZCAF6MYmdBOrohZYYGA-1 From: Peter Krempa To: libvir-list@redhat.com Subject: [PATCH 01/17] qemu: monitor: Avoid ternary operators in helpers for drive/blockdev-mirror Date: Fri, 3 Dec 2021 16:01:40 +0100 Message-Id: <8dbd11605d894414fb59f87b52af067035762528.1638543496.git.pkrempa@redhat.com> In-Reply-To: References: MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 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.15 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: 1638543757878100001 Content-Type: text/plain; charset="utf-8" Signed-off-by: Peter Krempa Reviewed-by: J=C3=A1n Tomko --- src/qemu/qemu_monitor_json.c | 18 +++++++++++++++--- 1 file changed, 15 insertions(+), 3 deletions(-) diff --git a/src/qemu/qemu_monitor_json.c b/src/qemu/qemu_monitor_json.c index c10ea583fd..1ecb06895c 100644 --- a/src/qemu/qemu_monitor_json.c +++ b/src/qemu/qemu_monitor_json.c @@ -4262,6 +4262,14 @@ qemuMonitorJSONDriveMirror(qemuMonitor *mon, { g_autoptr(virJSONValue) cmd =3D NULL; g_autoptr(virJSONValue) reply =3D NULL; + const char *syncmode =3D "full"; + const char *mode =3D "absolute-paths"; + + if (shallow) + syncmode =3D "top"; + + if (reuse) + mode =3D "existing"; cmd =3D qemuMonitorJSONMakeCommand("drive-mirror", "s:device", device, @@ -4269,8 +4277,8 @@ qemuMonitorJSONDriveMirror(qemuMonitor *mon, "Y:speed", speed, "z:granularity", granularity, "P:buf-size", buf_size, - "s:sync", shallow ? "top" : "full", - "s:mode", reuse ? "existing" : "absol= ute-paths", + "s:sync", syncmode, + "s:mode", mode, "S:format", format, NULL); if (!cmd) @@ -4298,6 +4306,10 @@ qemuMonitorJSONBlockdevMirror(qemuMonitor *mon, g_autoptr(virJSONValue) reply =3D NULL; virTristateBool autofinalize =3D VIR_TRISTATE_BOOL_ABSENT; virTristateBool autodismiss =3D VIR_TRISTATE_BOOL_ABSENT; + const char *syncmode =3D "full"; + + if (shallow) + syncmode =3D "top"; if (persistjob) { autofinalize =3D VIR_TRISTATE_BOOL_YES; @@ -4311,7 +4323,7 @@ qemuMonitorJSONBlockdevMirror(qemuMonitor *mon, "Y:speed", speed, "z:granularity", granularity, "P:buf-size", buf_size, - "s:sync", shallow ? "top" : "full", + "s:sync", syncmode, "T:auto-finalize", autofinalize, "T:auto-dismiss", autodismiss, NULL); --=20 2.31.1 From nobody Wed May 1 17:41:19 2024 Delivered-To: importer@patchew.org Received-SPF: pass (zohomail.com: domain of redhat.com designates 170.10.133.124 as permitted sender) client-ip=170.10.133.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.133.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=1638543743; cv=none; d=zohomail.com; s=zohoarc; b=RETieeV7+vS+E16piwiP89V5JhcX/eMDgaT3YSItfEk4eeqMprXH293iw3dY9ThpjDjdqGlxGwhjkhwkQyubYkGMSE37Kx8P9byGlnfs4F0s2ilIotba+pmcbXl10ndeUXlAELQHdSEToavWD6RIOH7gXQdTZA5jtX8U270mCas= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1638543743; 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=sYY/qGCG4kxzaxTv4cME/63z4or+mp8PQuuRMVLmVEs=; b=LJtrQBFxCty8QPAWRWv2L62NI+/TMSlKQiKCdSTHRNwmO7bVNbinU5HkXWgcYpgdmpkVcRwsdMZvUQeY+C33vWsTTlRD5iVtdO++v10/y2MRGtXbcbaDdIUwMKGvTwESvuXdLL3VeJovr+aBIAVEW809zopVhaCL+c9R+Duhu/s= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of redhat.com designates 170.10.133.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.133.124]) by mx.zohomail.com with SMTPS id 1638543743720986.1307094660407; Fri, 3 Dec 2021 07:02:23 -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-500-FlfyUmmJNaCN7oLkb-uLKw-1; Fri, 03 Dec 2021 10:02:18 -0500 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 15E6780BCB0; Fri, 3 Dec 2021 15:02:13 +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 EEA9845D68; Fri, 3 Dec 2021 15:02:12 +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 BFB361802E2C; Fri, 3 Dec 2021 15:02:12 +0000 (UTC) Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) by lists01.pubmisc.prod.ext.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id 1B3F2C88030724 for ; Fri, 3 Dec 2021 10:02:12 -0500 Received: by smtp.corp.redhat.com (Postfix) id 12A445D9D5; Fri, 3 Dec 2021 15:02:12 +0000 (UTC) Received: from speedmetal.lan (unknown [10.40.208.10]) by smtp.corp.redhat.com (Postfix) with ESMTP id 630465DAA5 for ; Fri, 3 Dec 2021 15:02:11 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1638543742; 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=sYY/qGCG4kxzaxTv4cME/63z4or+mp8PQuuRMVLmVEs=; b=TRhriTX7/Xv65Uh/RvBQ1PJO76rqYDlx/PsJirA60G9jRXql06ECAZTmfgKlK52Oh6EzUt zegiiPMan2vG4mzHzeCSStOWWPALB114EVSjkTFkYmPAL0fwY3vXioh4JkpjHXDmmWMYa8 dyiKS/OlgJbpf8xdfF7G79nvohCDBig= X-MC-Unique: FlfyUmmJNaCN7oLkb-uLKw-1 From: Peter Krempa To: libvir-list@redhat.com Subject: [PATCH 02/17] qemuMonitorJSONHandleShutdown: Use virTristateBoolFromBool Date: Fri, 3 Dec 2021 16:01:41 +0100 Message-Id: <032c5288389e0ea534efe0f495748f629b1d6c12.1638543496.git.pkrempa@redhat.com> In-Reply-To: References: MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 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.11 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: 1638543744497100001 Content-Type: text/plain; charset="utf-8" Instead of a ternary operator we can use the existing helper. Signed-off-by: Peter Krempa Reviewed-by: J=C3=A1n Tomko --- src/qemu/qemu_monitor_json.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/qemu/qemu_monitor_json.c b/src/qemu/qemu_monitor_json.c index 1ecb06895c..4b339db399 100644 --- a/src/qemu/qemu_monitor_json.c +++ b/src/qemu/qemu_monitor_json.c @@ -574,7 +574,7 @@ static void qemuMonitorJSONHandleShutdown(qemuMonitor *= mon, virJSONValue *data) virTristateBool guest_initiated =3D VIR_TRISTATE_BOOL_ABSENT; if (data && virJSONValueObjectGetBoolean(data, "guest", &guest) =3D=3D= 0) - guest_initiated =3D guest ? VIR_TRISTATE_BOOL_YES : VIR_TRISTATE_B= OOL_NO; + guest_initiated =3D virTristateBoolFromBool(guest); qemuMonitorEmitShutdown(mon, guest_initiated); } --=20 2.31.1 From nobody Wed May 1 17:41:19 2024 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=1638543809; cv=none; d=zohomail.com; s=zohoarc; b=MbBtBbUcnjJAlHxGj2YpiIHkfUPIkkMLY6Xm8D0QXGN7tvnas2OuiWYVUE6JM51y7QAgif8ueAGMcwUSE6hrAhB8kdKdCn8Yo6eo0+5pByBspTidqm4Lnqf4HGnna0M7F0DBXjn73F6w8fa6h3DjywTgEpcVrT7x8SIjSa+H9TA= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1638543809; 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=QK+J72082XF4v/odJ3EBM2FSviyvynd1TwQWz3UktK0=; b=JMhQTXdlLNipKHVTItITii3bcIf5MRUB0ljniKWhwGvWD6rdbSnL6oyI1Bfk5VzTBQhzN8w5TdR+kiQUE8Irky5ilw14ZDbqPO6Y75VesdJJq5/M4wDhUCLf3V5kxbmiWVCLK6GvtV+CM/Bg8MGX6xSAob7H7/D9a/JLD2cGfXw= 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 1638543809040969.0838705639242; Fri, 3 Dec 2021 07:03:29 -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-259-0H2McBy3Na6MXYzbT2jt_Q-1; Fri, 03 Dec 2021 10:03:26 -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 867881023F4E; Fri, 3 Dec 2021 15:03:21 +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 6790160C13; Fri, 3 Dec 2021 15:03:21 +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 381E74BB7C; Fri, 3 Dec 2021 15:03:21 +0000 (UTC) Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) by lists01.pubmisc.prod.ext.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id 1B3F3KtY031040 for ; Fri, 3 Dec 2021 10:03:20 -0500 Received: by smtp.corp.redhat.com (Postfix) id 29F264EE1D; Fri, 3 Dec 2021 15:03:20 +0000 (UTC) Received: from speedmetal.lan (unknown [10.40.208.10]) by smtp.corp.redhat.com (Postfix) with ESMTP id 690E55DAA5 for ; Fri, 3 Dec 2021 15:02:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1638543808; 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=QK+J72082XF4v/odJ3EBM2FSviyvynd1TwQWz3UktK0=; b=HQ3Z1fXw0Rc0hxQ1qFJUIfS49xvbR6630keOEq0ybXNDtIVpo13bNIQGs44oZPNhLZJ71Z PobFkxvbPfzZ+y4xYqljP3oDbx3gYIuAdRR3o0iDoU9QSXpVgqTX+oOQ6V9DQveuO8BuZU FRKOAxxnbIqkgZdxJlQKzzpFmnDSJAg= X-MC-Unique: 0H2McBy3Na6MXYzbT2jt_Q-1 From: Peter Krempa To: libvir-list@redhat.com Subject: [PATCH 03/17] qemuMonitorJSONEjectMedia: Use a bool directly for constructing JSON with 'b' modifier Date: Fri, 3 Dec 2021 16:01:42 +0100 Message-Id: <84bb9ca6cd7337d36b9a4e4aeeb3a1e59a9fef27.1638543496.git.pkrempa@redhat.com> In-Reply-To: References: MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 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.12 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: 1638543810282100001 Content-Type: text/plain; charset="utf-8" It actually already expects a bool. Signed-off-by: Peter Krempa Reviewed-by: J=C3=A1n Tomko --- src/qemu/qemu_monitor_json.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/qemu/qemu_monitor_json.c b/src/qemu/qemu_monitor_json.c index 4b339db399..da14eee964 100644 --- a/src/qemu/qemu_monitor_json.c +++ b/src/qemu/qemu_monitor_json.c @@ -2970,7 +2970,7 @@ int qemuMonitorJSONEjectMedia(qemuMonitor *mon, { g_autoptr(virJSONValue) cmd =3D qemuMonitorJSONMakeCommand("eject", "s:device", d= ev_name, - "b:force", fo= rce ? 1 : 0, + "b:force", fo= rce, NULL); g_autoptr(virJSONValue) reply =3D NULL; --=20 2.31.1 From nobody Wed May 1 17:41:19 2024 Delivered-To: importer@patchew.org Received-SPF: pass (zohomail.com: domain of redhat.com designates 216.205.24.124 as permitted sender) client-ip=216.205.24.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 216.205.24.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=1638543845; cv=none; d=zohomail.com; s=zohoarc; b=lJBjXXJwaUUjvV5LcdGXowTUt1kkTrvv8UhkG4hNOKjHCnPA2ctSB7tdUiyQmR/X5tD2B5cwUVYHSzZ7uYpznRoBI34gFVEYSH099U4NU2akJ6JROuAZhSG1xDBJ3xOrXMYPpJZRPyn1Oc3u5YeAaYE8e2ME3tP8caSRZJgRbIg= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1638543845; 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=UZCZ+JW2LPJWQqGkmR0MeiJAhuc2CuiP9aF+G9fks2I=; b=mTEnI2hsgDJ6Pu9dRm/1rI1pIi4kyH7NY6Ewtn07k3P1VfsegjOCDxYkRvsYyKBDHE82c6C7TIbIY5CvOOCY/VytrdM8TnLK7Ev8CtmURTKjJe19Fm5tZTfHieZIRdVM5eWH9eqT+Zr1dR3ubu2bcMK1/1DIyh2hxYfhu9C+nX4= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of redhat.com designates 216.205.24.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 [216.205.24.124]) by mx.zohomail.com with SMTPS id 1638543845636518.6286538756932; Fri, 3 Dec 2021 07:04:05 -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-95-tKc7PIumO6S2ODDqSLCVTg-1; Fri, 03 Dec 2021 10:04:02 -0500 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id B5FA01006AA9; Fri, 3 Dec 2021 15:03:56 +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 8F0725F4E9; Fri, 3 Dec 2021 15:03:56 +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 64E031802E2E; Fri, 3 Dec 2021 15:03:56 +0000 (UTC) Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) by lists01.pubmisc.prod.ext.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id 1B3F3slB031118 for ; Fri, 3 Dec 2021 10:03:54 -0500 Received: by smtp.corp.redhat.com (Postfix) id 64B475E275; Fri, 3 Dec 2021 15:03:54 +0000 (UTC) Received: from speedmetal.lan (unknown [10.40.208.10]) by smtp.corp.redhat.com (Postfix) with ESMTP id A0E635ED2D for ; Fri, 3 Dec 2021 15:03:20 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1638543844; 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=UZCZ+JW2LPJWQqGkmR0MeiJAhuc2CuiP9aF+G9fks2I=; b=bBHasBmsd2Vy/UCBAmFmjR+o/J+CvAlQ4crSX1J608WInkZSYG4+Xsc/BZ+y6ID/tZ0pAE 4LJcV9f1Qx71Htks4q3zKw932JQ8V1r8CpXlxo3QwEgSBCxJG9aCtV0YrcibTyUt1rJgeM 1fVqrMqsQDhOsaAA+G5FdNrWFqEbADE= X-MC-Unique: tKc7PIumO6S2ODDqSLCVTg-1 From: Peter Krempa To: libvir-list@redhat.com Subject: [PATCH 04/17] qemuMonitorJSONMigrate: Extract flags prior to constructing command Date: Fri, 3 Dec 2021 16:01:43 +0100 Message-Id: In-Reply-To: References: MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 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.15 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: 1638543847812100003 Content-Type: text/plain; charset="utf-8" The migration API takes specific flags which are then converted to boolean parameters for the command. Extract the flag into helper variables rather than using ternary operatirs while constructing the command itself. Signed-off-by: Peter Krempa Reviewed-by: J=C3=A1n Tomko --- src/qemu/qemu_monitor_json.c | 16 +++++++++------- 1 file changed, 9 insertions(+), 7 deletions(-) diff --git a/src/qemu/qemu_monitor_json.c b/src/qemu/qemu_monitor_json.c index da14eee964..82631e30e0 100644 --- a/src/qemu/qemu_monitor_json.c +++ b/src/qemu/qemu_monitor_json.c @@ -3440,13 +3440,15 @@ int qemuMonitorJSONMigrate(qemuMonitor *mon, unsigned int flags, const char *uri) { - g_autoptr(virJSONValue) cmd =3D - qemuMonitorJSONMakeCommand("migrate", - "b:detach", flags & QEMU_MONITOR_MIGRATE_= BACKGROUND ? 1 : 0, - "b:blk", flags & QEMU_MONITOR_MIGRATE_NON= _SHARED_DISK ? 1 : 0, - "b:inc", flags & QEMU_MONITOR_MIGRATE_NON= _SHARED_INC ? 1 : 0, - "s:uri", uri, - NULL); + bool detach =3D !!(flags & QEMU_MONITOR_MIGRATE_BACKGROUND); + bool blk =3D !!(flags & QEMU_MONITOR_MIGRATE_NON_SHARED_DISK); + bool inc =3D !!(flags & QEMU_MONITOR_MIGRATE_NON_SHARED_INC); + g_autoptr(virJSONValue) cmd =3D qemuMonitorJSONMakeCommand("migrate", + "b:detach", d= etach, + "b:blk", blk, + "b:inc", inc, + "s:uri", uri, + NULL); g_autoptr(virJSONValue) reply =3D NULL; if (!cmd) --=20 2.31.1 From nobody Wed May 1 17:41:19 2024 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=1638543845; cv=none; d=zohomail.com; s=zohoarc; b=WZoXQxxXOjZ0bMlW2cJhUyM3O9pMLJm3FEx9/irHgHCHqvjWQkEzlHPuJ3QupAMVzfd1EDCPTAhc4b8R+yIAzGNytDGiNGSchljHfsSHa5KiUyov+vD1ZmkKIquutQV2mptjTTRznOKlH8H3Tic/E1AX3AbFVP7j2DnWpe/mRzc= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1638543845; 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=hpxJlf1F/JVeOGdGOa3yq3bZV/8JyOcRNq2yE9t8PG8=; b=QsVbHQ1Xj+GbRt6Du5pdwNYajfvXSvxnWWaQMaQb079oQvA8Hd/LpuXdd4j4McGPqCIJ67zXV9Wo1ID/wfCD05DEMOFAPzFhQHRQ5bDZN35ea3CAIj+mErrsPMnhymQkyaidUhDwVx0zTh4oIDm2ONcI5qsMDFM74wy7JOeQ1UU= 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 1638543845156963.3539531605177; Fri, 3 Dec 2021 07:04:05 -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-439-ielGzzLPMUCLVkBfF3MpNA-1; Fri, 03 Dec 2021 10:04:02 -0500 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 3C94B3E76F; Fri, 3 Dec 2021 15:03:56 +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 20D05694DA; Fri, 3 Dec 2021 15:03:56 +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 EA8CF1802E2B; Fri, 3 Dec 2021 15:03:55 +0000 (UTC) Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) by lists01.pubmisc.prod.ext.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id 1B3F3tBw031123 for ; Fri, 3 Dec 2021 10:03:55 -0500 Received: by smtp.corp.redhat.com (Postfix) id 692335D9D5; Fri, 3 Dec 2021 15:03:55 +0000 (UTC) Received: from speedmetal.lan (unknown [10.40.208.10]) by smtp.corp.redhat.com (Postfix) with ESMTP id C01BE5DAA5 for ; Fri, 3 Dec 2021 15:03:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1638543844; 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=hpxJlf1F/JVeOGdGOa3yq3bZV/8JyOcRNq2yE9t8PG8=; b=Kt0PeWqKb0XhM7ENwpEPNpOVjJqL6kz8QrxvbF+FgC3Gdr54laGnlAaH37F/fZHypwd9lR OBTi4soyikXITGsYMSmR0wXPP43oBsSrsMXokrRz9gRcoMXNRrOeRw7lcVCw8cg5q/+5sP 0WnxifsjwiQMJI5qp8xhuXDcCF3VqRo= X-MC-Unique: ielGzzLPMUCLVkBfF3MpNA-1 From: Peter Krempa To: libvir-list@redhat.com Subject: [PATCH 05/17] qemuMonitorJSONGraphicsRelocate: Clean up command argument construction Date: Fri, 3 Dec 2021 16:01:44 +0100 Message-Id: <6dd9b3d94fc0c0e3d22b7821e44cb80306593b0f.1638543496.git.pkrempa@redhat.com> In-Reply-To: References: MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 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.13 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: 1638543845668100001 Content-Type: text/plain; charset="utf-8" Move the construction of the command from the variable declaration so that it doesn't exceed the line length and we can also move the logic of determining the protocol outside of the command construction. Signed-off-by: Peter Krempa Reviewed-by: J=C3=A1n Tomko --- src/qemu/qemu_monitor_json.c | 21 ++++++++++++--------- 1 file changed, 12 insertions(+), 9 deletions(-) diff --git a/src/qemu/qemu_monitor_json.c b/src/qemu/qemu_monitor_json.c index 82631e30e0..7cb6795a58 100644 --- a/src/qemu/qemu_monitor_json.c +++ b/src/qemu/qemu_monitor_json.c @@ -3590,17 +3590,20 @@ int qemuMonitorJSONGraphicsRelocate(qemuMonitor *mo= n, int tlsPort, const char *tlsSubject) { - g_autoptr(virJSONValue) cmd =3D qemuMonitorJSONMakeCommand("client_mig= rate_info", - "s:protocol", - (type =3D=3D = VIR_DOMAIN_GRAPHICS_TYPE_SPICE ? "spice" : "vnc"), - "s:hostname",= hostname, - "i:port", por= t, - "i:tls-port",= tlsPort, - "S:cert-subje= ct", tlsSubject, - NULL); + const char *protocol =3D "vnc"; + g_autoptr(virJSONValue) cmd =3D NULL; g_autoptr(virJSONValue) reply =3D NULL; - if (!cmd) + if (type =3D=3D VIR_DOMAIN_GRAPHICS_TYPE_SPICE) + protocol =3D "spice"; + + if (!(cmd =3D qemuMonitorJSONMakeCommand("client_migrate_info", + "s:protocol", protocol, + "s:hostname", hostname, + "i:port", port, + "i:tls-port", tlsPort, + "S:cert-subject", tlsSubject, + NULL))) return -1; if (qemuMonitorJSONCommand(mon, cmd, &reply) < 0) --=20 2.31.1 From nobody Wed May 1 17:41:19 2024 Delivered-To: importer@patchew.org Received-SPF: pass (zohomail.com: domain of redhat.com designates 170.10.133.124 as permitted sender) client-ip=170.10.133.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.133.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=1638543848; cv=none; d=zohomail.com; s=zohoarc; b=LVehx1LQcNNZyJgxsVIx5BkD3+YKhpxRrIs9wFAt/Wuq3mxoKp3m8e7J0aodxOzeJHcEd+8IMUXLqZrPfM/LhfLUdhTDk+Hoave5eC20LDq8rt0R5S5JcOpB/y6X2O9skMaAR+B0u2FvYmIkgRFyHEw5VheonoSWYheS/wa70F0= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1638543848; 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=yM2GlECxQzxawmxa7Z0y7wONaaBSqjWQSXOUJ3X2Gu0=; b=O+RXp5ZJ6lf20p6XxldaBV45BqeNvKlC80yTLxBURH2RoR9+qetEMWIhAoCwuV0m87iU6rj+WbC1UazWzgrb3j2LCC++NI+rJa324tUhAGoI5c/DSAv9yRk74QxUSToQslD26TcvvG/Dm/x2qO1wU8S5jXpOB3sTTgw4EAx6uWc= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of redhat.com designates 170.10.133.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.133.124]) by mx.zohomail.com with SMTPS id 1638543848880328.23362826299103; Fri, 3 Dec 2021 07:04:08 -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-252-TCMuaV41OcacvPV5JCLbvw-1; Fri, 03 Dec 2021 10:04:05 -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 2E766801B2E; Fri, 3 Dec 2021 15:03:58 +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 11B921037F39; Fri, 3 Dec 2021 15:03:58 +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 D44C44BB7C; Fri, 3 Dec 2021 15:03:57 +0000 (UTC) Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) by lists01.pubmisc.prod.ext.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id 1B3F3uVg031132 for ; Fri, 3 Dec 2021 10:03:56 -0500 Received: by smtp.corp.redhat.com (Postfix) id 904295DF3F; Fri, 3 Dec 2021 15:03:56 +0000 (UTC) Received: from speedmetal.lan (unknown [10.40.208.10]) by smtp.corp.redhat.com (Postfix) with ESMTP id CC24E5DAA5 for ; Fri, 3 Dec 2021 15:03:55 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1638543847; 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=yM2GlECxQzxawmxa7Z0y7wONaaBSqjWQSXOUJ3X2Gu0=; b=adjClM5fNAgAlnd4NxeCBYNzkq7ch1240dpUqojaapWGkGrnY7TQQYnmXgNkIn+TjpTeMH Mjb6rgLhFsQOiP4mjo63NMpQN24Ssxt3ZF6/ZI1NzIxvE008PAzz9xsr1gp05Ky05z7VIY sZ4yRPS61H3lhXCimVHJWaQKx9Hi3sU= X-MC-Unique: TCMuaV41OcacvPV5JCLbvw-1 From: Peter Krempa To: libvir-list@redhat.com Subject: [PATCH 06/17] qemu: monitor: Add support for 'write-blocking' copy mode for blockdev-mirror Date: Fri, 3 Dec 2021 16:01:45 +0100 Message-Id: In-Reply-To: References: MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 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.84 on 10.5.11.22 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: 1638543849952100001 Content-Type: text/plain; charset="utf-8" Forces the data to be written synchronously to both the original and the mirrored images which ensures that the job will reach synchronized phase. Signed-off-by: Peter Krempa Reviewed-by: J=C3=A1n Tomko --- src/qemu/qemu_driver.c | 3 ++- src/qemu/qemu_migration.c | 3 ++- src/qemu/qemu_monitor.c | 10 ++++++---- src/qemu/qemu_monitor.h | 3 ++- src/qemu/qemu_monitor_json.c | 8 +++++++- src/qemu/qemu_monitor_json.h | 3 ++- tests/qemumonitorjsontest.c | 2 +- 7 files changed, 22 insertions(+), 10 deletions(-) diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c index 6333d0af36..4cc1d20b89 100644 --- a/src/qemu/qemu_driver.c +++ b/src/qemu/qemu_driver.c @@ -15150,7 +15150,8 @@ qemuDomainBlockCopyCommon(virDomainObj *vm, ret =3D qemuMonitorBlockdevMirror(priv->mon, job->name, true, qemuDomainDiskGetTopNodename(disk), mirror->nodeformat, bandwidth, - granularity, buf_size, mirror_shal= low); + granularity, buf_size, mirror_shal= low, + false); } else { /* qemuMonitorDriveMirror needs to honor the REUSE_EXT flag as spe= cified * by the user */ diff --git a/src/qemu/qemu_migration.c b/src/qemu/qemu_migration.c index f2ea73c923..00c33c869e 100644 --- a/src/qemu/qemu_migration.c +++ b/src/qemu/qemu_migration.c @@ -959,7 +959,8 @@ qemuMigrationSrcNBDStorageCopyBlockdev(virQEMUDriver *d= river, if (mon_ret =3D=3D 0) mon_ret =3D qemuMonitorBlockdevMirror(qemuDomainGetMonitor(vm), jo= bname, persistjob, sourcename, copysrc->nodeforma= t, - mirror_speed, 0, 0, mirror_sha= llow); + mirror_speed, 0, 0, mirror_sha= llow, + false); if (mon_ret !=3D 0) qemuBlockStorageSourceAttachRollback(qemuDomainGetMonitor(vm), dat= a); diff --git a/src/qemu/qemu_monitor.c b/src/qemu/qemu_monitor.c index 26b59801b8..072739f5da 100644 --- a/src/qemu/qemu_monitor.c +++ b/src/qemu/qemu_monitor.c @@ -3059,17 +3059,19 @@ qemuMonitorBlockdevMirror(qemuMonitor *mon, unsigned long long bandwidth, unsigned int granularity, unsigned long long buf_size, - bool shallow) + bool shallow, + bool syncWrite) { VIR_DEBUG("jobname=3D%s, persistjob=3D%d, device=3D%s, target=3D%s, ba= ndwidth=3D%lld, " - "granularity=3D%#x, buf_size=3D%lld, shallow=3D%d", + "granularity=3D%#x, buf_size=3D%lld, shallow=3D%d syncWrite= =3D%d", NULLSTR(jobname), persistjob, device, target, bandwidth, gra= nularity, - buf_size, shallow); + buf_size, shallow, syncWrite); QEMU_CHECK_MONITOR(mon); return qemuMonitorJSONBlockdevMirror(mon, jobname, persistjob, device,= target, - bandwidth, granularity, buf_size,= shallow); + bandwidth, granularity, buf_size,= shallow, + syncWrite); } diff --git a/src/qemu/qemu_monitor.h b/src/qemu/qemu_monitor.h index 99ecebc648..b58c637baf 100644 --- a/src/qemu/qemu_monitor.h +++ b/src/qemu/qemu_monitor.h @@ -1079,7 +1079,8 @@ int qemuMonitorBlockdevMirror(qemuMonitor *mon, unsigned long long bandwidth, unsigned int granularity, unsigned long long buf_size, - bool shallow) + bool shallow, + bool syncWrite) ATTRIBUTE_NONNULL(4) ATTRIBUTE_NONNULL(5); int qemuMonitorDrivePivot(qemuMonitor *mon, const char *jobname) diff --git a/src/qemu/qemu_monitor_json.c b/src/qemu/qemu_monitor_json.c index 7cb6795a58..64739762b0 100644 --- a/src/qemu/qemu_monitor_json.c +++ b/src/qemu/qemu_monitor_json.c @@ -4305,17 +4305,22 @@ qemuMonitorJSONBlockdevMirror(qemuMonitor *mon, unsigned long long speed, unsigned int granularity, unsigned long long buf_size, - bool shallow) + bool shallow, + bool syncWrite) { g_autoptr(virJSONValue) cmd =3D NULL; g_autoptr(virJSONValue) reply =3D NULL; virTristateBool autofinalize =3D VIR_TRISTATE_BOOL_ABSENT; virTristateBool autodismiss =3D VIR_TRISTATE_BOOL_ABSENT; const char *syncmode =3D "full"; + const char *copymode =3D NULL; if (shallow) syncmode =3D "top"; + if (syncWrite) + copymode =3D "write-blocking"; + if (persistjob) { autofinalize =3D VIR_TRISTATE_BOOL_YES; autodismiss =3D VIR_TRISTATE_BOOL_NO; @@ -4329,6 +4334,7 @@ qemuMonitorJSONBlockdevMirror(qemuMonitor *mon, "z:granularity", granularity, "P:buf-size", buf_size, "s:sync", syncmode, + "S:copy-mode", copymode, "T:auto-finalize", autofinalize, "T:auto-dismiss", autodismiss, NULL); diff --git a/src/qemu/qemu_monitor_json.h b/src/qemu/qemu_monitor_json.h index f7fb13f56c..0dec49ec28 100644 --- a/src/qemu/qemu_monitor_json.h +++ b/src/qemu/qemu_monitor_json.h @@ -266,7 +266,8 @@ int qemuMonitorJSONBlockdevMirror(qemuMonitor *mon, unsigned long long speed, unsigned int granularity, unsigned long long buf_size, - bool shallow) + bool shallow, + bool syncWrite) ATTRIBUTE_NONNULL(1) ATTRIBUTE_NONNULL(4) ATTRIBUTE_NONNULL(5); int qemuMonitorJSONDrivePivot(qemuMonitor *mon, const char *jobname) diff --git a/tests/qemumonitorjsontest.c b/tests/qemumonitorjsontest.c index 4c882fa5d3..1ad2912b08 100644 --- a/tests/qemumonitorjsontest.c +++ b/tests/qemumonitorjsontest.c @@ -1175,7 +1175,7 @@ GEN_TEST_FUNC(qemuMonitorJSONGraphicsRelocate, VIR_DO= MAIN_GRAPHICS_TYPE_SPICE, GEN_TEST_FUNC(qemuMonitorJSONRemoveNetdev, "net0") GEN_TEST_FUNC(qemuMonitorJSONDelDevice, "ide0") GEN_TEST_FUNC(qemuMonitorJSONDriveMirror, "vdb", "/foo/bar", "formatstr", = 1024, 1234, 31234, true, true) -GEN_TEST_FUNC(qemuMonitorJSONBlockdevMirror, "jobname", true, "vdb", "targ= etnode", 1024, 1234, 31234, true) +GEN_TEST_FUNC(qemuMonitorJSONBlockdevMirror, "jobname", true, "vdb", "targ= etnode", 1024, 1234, 31234, true, true) GEN_TEST_FUNC(qemuMonitorJSONBlockStream, "vdb", "jobname", true, "/foo/ba= r1", "backingnode", "backingfilename", 1024) GEN_TEST_FUNC(qemuMonitorJSONBlockCommit, "vdb", "jobname", true, "/foo/ba= r1", "topnode", "/foo/bar2", "basenode", "backingfilename", 1024) GEN_TEST_FUNC(qemuMonitorJSONDrivePivot, "vdb") --=20 2.31.1 From nobody Wed May 1 17:41:19 2024 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=1638543851; cv=none; d=zohomail.com; s=zohoarc; b=MiEKGqkWPsfV4oXNJLfi3GVcb5eQglg8b+Xiae/XSu3nOJ0mByuF46hoM9X/QifRp1vjOxWsZra4WTEAmFiBC7p+cddnuOKA8i1qhwuOL+eoksXMepjezNoQ3qpabyX4qtv+OZHjBn77SBmcO4JEKdqCi7Z3uZdg9XY0N/HAWes= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1638543851; 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=0RIv5LQ0PLGAzrp8kFqGbS2udm0OEqUs9Aa5k8K7Wrw=; b=O261JJ87Gtw+KsmQRJdo6f3cvxWVAlgmNK7xm1e64sTSb4BlPpIrPS6M7oqmbBqCAVM1W1ox3DCdfJcynLukDsLAXwr6ucZ5sjQnWUeO+NK7IY+NZE0Ildi8RuAVQ8XZLfYPOmwdevrZRxynUlPzX9/MwnSf3yLK3EsreXwFutg= 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 16385438513181020.2054416384547; Fri, 3 Dec 2021 07:04:11 -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-115-4H1b_J0KP-Koq99YAcv-xg-1; Fri, 03 Dec 2021 10:04:06 -0500 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 7FA3F423C7; Fri, 3 Dec 2021 15:03: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 3BBA82B178; Fri, 3 Dec 2021 15:03: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 116E61802E37; Fri, 3 Dec 2021 15:03:59 +0000 (UTC) Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) by lists01.pubmisc.prod.ext.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id 1B3F3vqC031146 for ; Fri, 3 Dec 2021 10:03:57 -0500 Received: by smtp.corp.redhat.com (Postfix) id AF61A5DAA5; Fri, 3 Dec 2021 15:03:57 +0000 (UTC) Received: from speedmetal.lan (unknown [10.40.208.10]) by smtp.corp.redhat.com (Postfix) with ESMTP id 0804F5D9D5 for ; Fri, 3 Dec 2021 15:03:56 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1638543850; 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=0RIv5LQ0PLGAzrp8kFqGbS2udm0OEqUs9Aa5k8K7Wrw=; b=LICjTV06JEmgRtmZsXgl2ddWUHWjiWLXe1/JZF2I+Ob579vzzGSqkFmLllJFvy6q/X8Pzf LXfamkfqR46F2AIBVklYS/N4j3MImz+dSHDSMBA6BazPkeVu7VtZmOz4D/Ahgt20bYt8DF phMynWYtOc3nhWv4TRvygSkCnM+vBvk= X-MC-Unique: 4H1b_J0KP-Koq99YAcv-xg-1 From: Peter Krempa To: libvir-list@redhat.com Subject: [PATCH 07/17] include: virDomainBlockCopyFlags: Convert to prefix comments Date: Fri, 3 Dec 2021 16:01:46 +0100 Message-Id: <9229c616d3be57ac533a83c91dca26d60acb1c4b.1638543496.git.pkrempa@redhat.com> In-Reply-To: References: MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 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.11 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: 1638543853447100001 Content-Type: text/plain; charset="utf-8" Switch to the comment style allowing more text. Signed-off-by: Peter Krempa Reviewed-by: J=C3=A1n Tomko --- include/libvirt/libvirt-domain.h | 15 ++++++++------- 1 file changed, 8 insertions(+), 7 deletions(-) diff --git a/include/libvirt/libvirt-domain.h b/include/libvirt/libvirt-dom= ain.h index 2f017c5b68..dddcae86a4 100644 --- a/include/libvirt/libvirt-domain.h +++ b/include/libvirt/libvirt-domain.h @@ -2590,13 +2590,14 @@ int virDomainBlockRebase(virDomainPtr dom, const ch= ar *disk, * Flags available for virDomainBlockCopy(). */ typedef enum { - VIR_DOMAIN_BLOCK_COPY_SHALLOW =3D 1 << 0, /* Limit copy to top of so= urce - backing chain */ - VIR_DOMAIN_BLOCK_COPY_REUSE_EXT =3D 1 << 1, /* Reuse existing external - file for a copy */ - VIR_DOMAIN_BLOCK_COPY_TRANSIENT_JOB =3D 1 << 2, /* Don't force usage of - recoverable job for t= he - copy operation */ + /* Limit copy to top of source backing chain */ + VIR_DOMAIN_BLOCK_COPY_SHALLOW =3D 1 << 0, + + /* Reuse existing external file for a copy */ + VIR_DOMAIN_BLOCK_COPY_REUSE_EXT =3D 1 << 1, + + /* Don't force usage of recoverable job for the copy operation */ + VIR_DOMAIN_BLOCK_COPY_TRANSIENT_JOB =3D 1 << 2, } virDomainBlockCopyFlags; /** --=20 2.31.1 From nobody Wed May 1 17:41:19 2024 Delivered-To: importer@patchew.org Received-SPF: pass (zohomail.com: domain of redhat.com designates 170.10.133.124 as permitted sender) client-ip=170.10.133.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.133.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=1638543853; cv=none; d=zohomail.com; s=zohoarc; b=eAZLH2yeNnPjOc3uHl+1sD5en9nbQKZ5Tb1cOvgdVAXPxZcs6bg4z4Hg+ZuhDeMLMUZQQBOdTKMneiPHrf7Gr6/tXkkI8cxw//2WMbRRV9PEcTy6mxEpFvh6mtHRXSdafUssszPER1ZtOPebRmeXZCT7pRaFBEoaPj/f+fu40C4= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1638543853; 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=RK/710aojKOq98WZ0R1xy/uQqZWQhZgNRFlnt/L3s3M=; b=QD++ppbjf+fmK4BQl/LtPK2Wt3v7rGmZJb7l6BZ8CygrSWEPh2YRj9Ns1sS8EeDCC72+EE1DrhujBfxdF3DzHjlGLTIF5f2W2uvUoE8msH7ZkFIHMxgArCybcrqxujXq+Z0JrxAUEvzjKRvgH0U4mWGMzHI28brEMwpGV1ZcxPI= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of redhat.com designates 170.10.133.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.133.124]) by mx.zohomail.com with SMTPS id 1638543853102634.6933957867009; Fri, 3 Dec 2021 07:04:13 -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-374-Vkt7W0VBPOagvln3Gl7f-g-1; Fri, 03 Dec 2021 10:04:09 -0500 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 8CD97835E22; Fri, 3 Dec 2021 15:04: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 6D6942B178; Fri, 3 Dec 2021 15:04:00 +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 1529C4A7C8; Fri, 3 Dec 2021 15:04:00 +0000 (UTC) Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) by lists01.pubmisc.prod.ext.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id 1B3F3wlq031156 for ; Fri, 3 Dec 2021 10:03:58 -0500 Received: by smtp.corp.redhat.com (Postfix) id CBC705DF4C; Fri, 3 Dec 2021 15:03:58 +0000 (UTC) Received: from speedmetal.lan (unknown [10.40.208.10]) by smtp.corp.redhat.com (Postfix) with ESMTP id 1FC405DF21 for ; Fri, 3 Dec 2021 15:03:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1638543852; 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=RK/710aojKOq98WZ0R1xy/uQqZWQhZgNRFlnt/L3s3M=; b=Lk1Zeta/JA1nuRCfxWko89Mn8i4K51WieAEZX3KyUoY7oA50F54oX1XVuC6k9wkI7UMte3 5YKAwgA1GAtfXo1EvEYaZhiKcJ7L+OJk2CqaqJy3qqqmCHLG6LKKggFrXE15Jj/ZzauXR5 vv3hmm/6QmiiQlflfB4naHCLEWj+Ugw= X-MC-Unique: Vkt7W0VBPOagvln3Gl7f-g-1 From: Peter Krempa To: libvir-list@redhat.com Subject: [PATCH 08/17] virDomainBlockCopy: Introduce VIR_DOMAIN_BLOCK_COPY_SYNCHRONOUS_WRITES flag Date: Fri, 3 Dec 2021 16:01:47 +0100 Message-Id: <2822ff5cf0d30f146d185fc608d54ad95faf64d0.1638543496.git.pkrempa@redhat.com> In-Reply-To: References: MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 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.11 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: 1638543854154100003 Content-Type: text/plain; charset="utf-8" In cases when the destination storage is slower than the normal VM storage and the VM does intensive I/O to the disk a block copy job may never converge. Switching it to synchronous mode will ensure that all writes done by the guest are propagated to the destination at the cost of slowing down I/O of the guest to the synchronous speed. This patch adds the new API flag and implements virsh support. Signed-off-by: Peter Krempa Reviewed-by: J=C3=A1n Tomko --- docs/manpages/virsh.rst | 7 ++++++- include/libvirt/libvirt-domain.h | 4 ++++ src/libvirt-domain.c | 6 ++++++ tools/virsh-domain.c | 9 ++++++++- 4 files changed, 24 insertions(+), 2 deletions(-) diff --git a/docs/manpages/virsh.rst b/docs/manpages/virsh.rst index 39636a565e..9728f36a78 100644 --- a/docs/manpages/virsh.rst +++ b/docs/manpages/virsh.rst @@ -1218,7 +1218,7 @@ blockcopy [--shallow] [--reuse-external] [bandwidth] [--wait [--async] [--verbose]] [{--pivot | --finish}] [--timeout seconds] [granularity] [buf-size] [--bytes] - [--transient-job] + [--transient-job] [--synchronous-writes] Copy a disk backing image chain to a destination. Either *dest* as the destination file name, or *--xml* with the name of an XML file contain= ing @@ -1278,6 +1278,11 @@ be recovered if the VM crashes or is turned off befo= re the job completes. This flag removes the restriction of copy jobs to transient domains if that restriction is applied by the hypervisor. +If *--synchronous-writes* is specified the block job will wait for guest w= rites +to be propagated both to the original image and to the destination of the = copy +so that it's guaranteed that the job converges if the destination storage = is +slower. This may impact performance of writes while the blockjob is runnin= g. + blockjob -------- diff --git a/include/libvirt/libvirt-domain.h b/include/libvirt/libvirt-dom= ain.h index dddcae86a4..3a76aec90f 100644 --- a/include/libvirt/libvirt-domain.h +++ b/include/libvirt/libvirt-domain.h @@ -2598,6 +2598,10 @@ typedef enum { /* Don't force usage of recoverable job for the copy operation */ VIR_DOMAIN_BLOCK_COPY_TRANSIENT_JOB =3D 1 << 2, + + /* Force the copy job to synchronously propagate guest writes into + * the destination image, so that the copy is guaranteed to converge */ + VIR_DOMAIN_BLOCK_COPY_SYNCHRONOUS_WRITES =3D 1 << 3, } virDomainBlockCopyFlags; /** diff --git a/src/libvirt-domain.c b/src/libvirt-domain.c index ce7cafde36..8ee2490867 100644 --- a/src/libvirt-domain.c +++ b/src/libvirt-domain.c @@ -10509,6 +10509,12 @@ virDomainBlockRebase(virDomainPtr dom, const char = *disk, * remove the restriction of copy jobs to transient domains. Note that thi= s flag * is automatically implied if the VM is transient at the time it's starte= d. * + * If @flags contains VIR_DOMAIN_BLOCK_COPY_SYNCHRONOUS_WRITES the job wil= l wait + * for guest writes to be propagated both to the original image and to the + * destination of the copy so that it's guaranteed that the job converges = if + * the destination storage is slower. This may impact performance of writes + * while the blockjob is running. + * * The @disk parameter is either an unambiguous source name of the * block device (the sub-element, such as * "/path/to/image"), or the device target shorthand (the diff --git a/tools/virsh-domain.c b/tools/virsh-domain.c index e179e24ca9..a00b4cc243 100644 --- a/tools/virsh-domain.c +++ b/tools/virsh-domain.c @@ -2284,6 +2284,10 @@ static const vshCmdOptDef opts_blockcopy[] =3D { .type =3D VSH_OT_BOOL, .help =3D N_("the copy job is not persisted if VM is turned off") }, + {.name =3D "synchronous-writes", + .type =3D VSH_OT_BOOL, + .help =3D N_("the copy job forces guest writes to be synchronously wr= itten to the destination") + }, {.name =3D NULL} }; @@ -2306,6 +2310,7 @@ cmdBlockcopy(vshControl *ctl, const vshCmd *cmd) bool async =3D vshCommandOptBool(cmd, "async"); bool bytes =3D vshCommandOptBool(cmd, "bytes"); bool transientjob =3D vshCommandOptBool(cmd, "transient-job"); + bool syncWrites =3D vshCommandOptBool(cmd, "synchronous-writes"); int timeout =3D 0; const char *path =3D NULL; int abort_flags =3D 0; @@ -2337,6 +2342,8 @@ cmdBlockcopy(vshControl *ctl, const vshCmd *cmd) flags |=3D VIR_DOMAIN_BLOCK_REBASE_REUSE_EXT; if (transientjob) flags |=3D VIR_DOMAIN_BLOCK_COPY_TRANSIENT_JOB; + if (syncWrites) + flags |=3D VIR_DOMAIN_BLOCK_COPY_SYNCHRONOUS_WRITES; if (vshCommandOptTimeoutToMs(ctl, cmd, &timeout) < 0) return false; @@ -2386,7 +2393,7 @@ cmdBlockcopy(vshControl *ctl, const vshCmd *cmd) } if (granularity || buf_size || (format && STRNEQ(format, "raw")) || xm= l || - transientjob) { + transientjob || syncWrites) { /* New API */ if (bandwidth || granularity || buf_size) { params =3D g_new0(virTypedParameter, 3); --=20 2.31.1 From nobody Wed May 1 17:41:19 2024 Delivered-To: importer@patchew.org Received-SPF: pass (zohomail.com: domain of redhat.com designates 170.10.133.124 as permitted sender) client-ip=170.10.133.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.133.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=1638543856; cv=none; d=zohomail.com; s=zohoarc; b=JlGaSodd8DMdAisfjRoCTNvYJAM5mJUfD2neADurhCqzff0ejzt41kzczU0ASVKSQbnWLKLqsVG/VoogN+iLfu8KK6b3DzRBA0JwvGgzbW94z8wLVyipK1trTSJN9q7615KjPOcqO1XehSZtLEhbUPWGP/WY3PO1uuZ/B6H9SI4= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1638543856; 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=76kNjy7YiN1xdug6tMa7EK6brhQwMglflBYSYSwPPdk=; b=nPxP2bHKluxCh8vxlnSDMyNAo0BnRF7+F8FntSsexbWkazX3DTHRQFJFqwhxrJQtgKkmbtYBqNGyWUXrTog8bPc4+6T0ZSUOj0IKdxCoAuW7k2oHu/lAyEKeIES+AeedTOyeaXadGpu6eFrsTsd82lT3uQuTpRDAUloY4YGXFGM= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of redhat.com designates 170.10.133.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.133.124]) by mx.zohomail.com with SMTPS id 1638543856662414.9006502456533; Fri, 3 Dec 2021 07:04:16 -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-190-5F0_enSPMBSexJ5rd8M5sQ-1; Fri, 03 Dec 2021 10:04:13 -0500 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 68FC4190A7B8; Fri, 3 Dec 2021 15:04:03 +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 374C95F4E1; Fri, 3 Dec 2021 15:04:03 +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 0301B4A7C8; Fri, 3 Dec 2021 15:04:03 +0000 (UTC) Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) by lists01.pubmisc.prod.ext.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id 1B3F3xEs031166 for ; Fri, 3 Dec 2021 10:03:59 -0500 Received: by smtp.corp.redhat.com (Postfix) id E56345D9D5; Fri, 3 Dec 2021 15:03:59 +0000 (UTC) Received: from speedmetal.lan (unknown [10.40.208.10]) by smtp.corp.redhat.com (Postfix) with ESMTP id 4987A5ED49 for ; Fri, 3 Dec 2021 15:03:59 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1638543855; 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=76kNjy7YiN1xdug6tMa7EK6brhQwMglflBYSYSwPPdk=; b=M8GEk32D/CtYH6/qs22yF8dSt76uWo9tp3qadKyawyPlGXM4BaA0eP6VqiuDaPZZXEjnCx RuirIbZQcERZ/eBh2MvX9vt4Fjs19V+3cZ2RufbV7cIOyiCpZbLH1W0rxAr3ezg5I+SGhE jzkVNeFf7if7+UAC3gz/sBswxADg/KI= X-MC-Unique: 5F0_enSPMBSexJ5rd8M5sQ-1 From: Peter Krempa To: libvir-list@redhat.com Subject: [PATCH 09/17] qemuDomainBlockCopy: Implement VIR_DOMAIN_BLOCK_COPY_SYNCHRONOUS_WRITES Date: Fri, 3 Dec 2021 16:01:48 +0100 Message-Id: <975c8013b8a6ea42688c879a2fded24a603c73ac.1638543496.git.pkrempa@redhat.com> In-Reply-To: References: MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 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.15 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: 1638543858544100001 Content-Type: text/plain; charset="utf-8" Wire up the flag to enable the 'write-blocking' 'copy-mode' of 'blockdev-mirror'. It's not supported by all qemu versions but it is with those which we use -blockdev with so we can use that instead of adding another custom capability as we use blockdev for some time now. Signed-off-by: Peter Krempa Reviewed-by: J=C3=A1n Tomko --- src/qemu/qemu_driver.c | 16 +++++++++++++--- 1 file changed, 13 insertions(+), 3 deletions(-) diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c index 4cc1d20b89..a9fb840628 100644 --- a/src/qemu/qemu_driver.c +++ b/src/qemu/qemu_driver.c @@ -14902,12 +14902,14 @@ qemuDomainBlockCopyCommon(virDomainObj *vm, virStorageSource *n; virStorageSource *mirrorBacking =3D NULL; g_autoptr(GHashTable) blockNamedNodeData =3D NULL; + bool syncWrites =3D !!(flags & VIR_DOMAIN_BLOCK_COPY_SYNCHRONOUS_WRITE= S); int rc =3D 0; /* Preliminaries: find the disk we are editing, sanity checks */ virCheckFlags(VIR_DOMAIN_BLOCK_COPY_SHALLOW | VIR_DOMAIN_BLOCK_COPY_REUSE_EXT | - VIR_DOMAIN_BLOCK_COPY_TRANSIENT_JOB, -1); + VIR_DOMAIN_BLOCK_COPY_TRANSIENT_JOB | + VIR_DOMAIN_BLOCK_COPY_SYNCHRONOUS_WRITES, -1); if (virStorageSourceIsRelative(mirror)) { virReportError(VIR_ERR_INVALID_ARG, "%s", @@ -14945,6 +14947,12 @@ qemuDomainBlockCopyCommon(virDomainObj *vm, virDomainDiskDefSourceLUNValidate(mirror) < 0) goto endjob; + if (syncWrites && !blockdev) { + virReportError(VIR_ERR_OPERATION_UNSUPPORTED, "%s", + _("VIR_DOMAIN_BLOCK_COPY_SYNCHRONOUS_WRITES is not = supported by this VM")); + goto endjob; + } + if (!(flags & VIR_DOMAIN_BLOCK_COPY_TRANSIENT_JOB) && vm->persistent) { /* XXX if qemu ever lets us start a new domain with mirroring @@ -15151,7 +15159,7 @@ qemuDomainBlockCopyCommon(virDomainObj *vm, qemuDomainDiskGetTopNodename(disk), mirror->nodeformat, bandwidth, granularity, buf_size, mirror_shal= low, - false); + syncWrites); } else { /* qemuMonitorDriveMirror needs to honor the REUSE_EXT flag as spe= cified * by the user */ @@ -15286,7 +15294,9 @@ qemuDomainBlockCopy(virDomainPtr dom, const char *d= isk, const char *destxml, virCheckFlags(VIR_DOMAIN_BLOCK_COPY_SHALLOW | VIR_DOMAIN_BLOCK_COPY_REUSE_EXT | - VIR_DOMAIN_BLOCK_COPY_TRANSIENT_JOB, -1); + VIR_DOMAIN_BLOCK_COPY_TRANSIENT_JOB | + VIR_DOMAIN_BLOCK_COPY_SYNCHRONOUS_WRITES, -1); + if (virTypedParamsValidate(params, nparams, VIR_DOMAIN_BLOCK_COPY_BANDWIDTH, VIR_TYPED_PARAM_ULLONG, --=20 2.31.1 From nobody Wed May 1 17:41:19 2024 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=1638543857; cv=none; d=zohomail.com; s=zohoarc; b=NaeRXmTpGQ8PVeAd/8Y82tKKFmNHrH+GFL7WXFInQx1gHpr0b5fWx3tz2OmivpuWhltvsgL5MneMTyha0JbwrtQF7L5Cgqz053Tk7X8+HN55juUl4JBHn/VUOqCkiS52gkgWjLIY2CGb9OMG0qPv9WHAj2PGSz9wmF4oiGndRmM= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1638543857; 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=f61Yk9MzwG3PvCPpTkV/dApKojj0qWy7GPI9c4mYh2w=; b=HBoN2RRpajI4KTyTjL4hhb+nHY/3NTTT0PK7/U11l12gv7usBnW0GtBi5Fy3FQp9DJYnZVyaI3VhWfBJjlEzLtY8K66OGWay4zNVYhkSnUibM2KpLlrfIj6VTuYxBjLDITtowuLSIxumk4mHcmnLT0j93YbXcXNcj1Ea159Zcx4= 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 1638543857151650.6108512527376; Fri, 3 Dec 2021 07:04:17 -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-35-1rFlTPebOEGKNdCnOyXX2g-1; Fri, 03 Dec 2021 10:04:13 -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 015CB5A08E; Fri, 3 Dec 2021 15:04:03 +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 CBDA35C3E0; Fri, 3 Dec 2021 15:04:02 +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 912B84A7C8; Fri, 3 Dec 2021 15:04:02 +0000 (UTC) Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) by lists01.pubmisc.prod.ext.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id 1B3F41md031176 for ; Fri, 3 Dec 2021 10:04:01 -0500 Received: by smtp.corp.redhat.com (Postfix) id 13B275DF4F; Fri, 3 Dec 2021 15:04:01 +0000 (UTC) Received: from speedmetal.lan (unknown [10.40.208.10]) by smtp.corp.redhat.com (Postfix) with ESMTP id 5505A5DF21 for ; Fri, 3 Dec 2021 15:04:00 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1638543856; 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=f61Yk9MzwG3PvCPpTkV/dApKojj0qWy7GPI9c4mYh2w=; b=VI+gA/eeJQWxL4hN3K3Y+CTxwKBtW1WnbevsX8krm0BMO9y6vLV5/1uUwrTnpZciOgFmwC B7jU5SY8BOU7N5Y/owQNHBgtw8aHKndU1T26oM5XRin0rwuDv6lrkoTH6BtFJx1R+9UV/7 7yAbQhOdnh7Dtm4ig8ZL0Cf0IExhQ4k= X-MC-Unique: 1rFlTPebOEGKNdCnOyXX2g-1 From: Peter Krempa To: libvir-list@redhat.com Subject: [PATCH 10/17] include: virDomainMigrateFlags: Remove "block alignment" whitespace Date: Fri, 3 Dec 2021 16:01:49 +0100 Message-Id: <72c885eccb5b322c058c403b8cc6beb100697755.1638543496.git.pkrempa@redhat.com> In-Reply-To: References: MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 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: 1638543858786100003 Content-Type: text/plain; charset="utf-8" Using whitespace to align the '=3D' and values doesn't make sense for the virDomainMigrateFlags enum as the visual block is interrupted by comments. Signed-off-by: Peter Krempa Reviewed-by: J=C3=A1n Tomko --- include/libvirt/libvirt-domain.h | 34 ++++++++++++++++---------------- 1 file changed, 17 insertions(+), 17 deletions(-) diff --git a/include/libvirt/libvirt-domain.h b/include/libvirt/libvirt-dom= ain.h index 3a76aec90f..f81e96d374 100644 --- a/include/libvirt/libvirt-domain.h +++ b/include/libvirt/libvirt-domain.h @@ -710,7 +710,7 @@ typedef enum { * faster then it can be transferred. The domain can be manually paused * anytime during migration using virDomainSuspend. */ - VIR_MIGRATE_LIVE =3D (1 << 0), + VIR_MIGRATE_LIVE =3D (1 << 0), /* Tell the source libvirtd to connect directly to the destination hos= t. * Without this flag the client (e.g., virsh) connects to both hosts a= nd @@ -718,7 +718,7 @@ typedef enum { * libvirtd controls the migration by calling the destination daemon * directly. */ - VIR_MIGRATE_PEER2PEER =3D (1 << 1), + VIR_MIGRATE_PEER2PEER =3D (1 << 1), /* Tunnel migration data over libvirtd connection. Without this flag t= he * source hypervisor sends migration data directly to the destination @@ -728,25 +728,25 @@ typedef enum { * Note the less-common spelling that we're stuck with: * VIR_MIGRATE_TUNNELLED should be VIR_MIGRATE_TUNNELED. */ - VIR_MIGRATE_TUNNELLED =3D (1 << 2), + VIR_MIGRATE_TUNNELLED =3D (1 << 2), /* Define the domain as persistent on the destination host after succe= ssful * migration. If the domain was persistent on the source host and * VIR_MIGRATE_UNDEFINE_SOURCE is not used, it will end up persistent = on * both hosts. */ - VIR_MIGRATE_PERSIST_DEST =3D (1 << 3), + VIR_MIGRATE_PERSIST_DEST =3D (1 << 3), /* Undefine the domain on the source host once migration successfully * finishes. */ - VIR_MIGRATE_UNDEFINE_SOURCE =3D (1 << 4), + VIR_MIGRATE_UNDEFINE_SOURCE =3D (1 << 4), /* Leave the domain suspended on the destination host. virDomainResume= (on * the virDomainPtr returned by the migration API) has to be called * explicitly to resume domain's virtual CPUs. */ - VIR_MIGRATE_PAUSED =3D (1 << 5), + VIR_MIGRATE_PAUSED =3D (1 << 5), /* Migrate full disk images in addition to domain's memory. By default * only non-shared non-readonly disk images are transferred. The @@ -755,7 +755,7 @@ typedef enum { * * This flag and VIR_MIGRATE_NON_SHARED_INC are mutually exclusive. */ - VIR_MIGRATE_NON_SHARED_DISK =3D (1 << 6), + VIR_MIGRATE_NON_SHARED_DISK =3D (1 << 6), /* Migrate disk images in addition to domain's memory. This is similar= to * VIR_MIGRATE_NON_SHARED_DISK, but only the top level of each disk's @@ -765,7 +765,7 @@ typedef enum { * * This flag and VIR_MIGRATE_NON_SHARED_DISK are mutually exclusive. */ - VIR_MIGRATE_NON_SHARED_INC =3D (1 << 7), + VIR_MIGRATE_NON_SHARED_INC =3D (1 << 7), /* Protect against domain configuration changes during the migration * process. This flag is used automatically when both sides support it. @@ -782,7 +782,7 @@ typedef enum { * is unsafe unless the disk images are stored on coherent clustered * filesystem, such as GFS2 or GPFS. */ - VIR_MIGRATE_UNSAFE =3D (1 << 9), + VIR_MIGRATE_UNSAFE =3D (1 << 9), /* Migrate a domain definition without starting the domain on the * destination and without stopping it on the source host. Offline @@ -791,19 +791,19 @@ typedef enum { * Offline migration may not copy disk storage or any other file based * storage (such as UEFI variables). */ - VIR_MIGRATE_OFFLINE =3D (1 << 10), + VIR_MIGRATE_OFFLINE =3D (1 << 10), /* Compress migration data. The compression methods can be specified u= sing * VIR_MIGRATE_PARAM_COMPRESSION. A hypervisor default method will be = used * if this parameter is omitted. Individual compression methods can be * tuned via their specific VIR_MIGRATE_PARAM_COMPRESSION_* parameters. */ - VIR_MIGRATE_COMPRESSED =3D (1 << 11), + VIR_MIGRATE_COMPRESSED =3D (1 << 11), /* Cancel migration if a soft error (such as I/O error) happens during * migration. */ - VIR_MIGRATE_ABORT_ON_ERROR =3D (1 << 12), + VIR_MIGRATE_ABORT_ON_ERROR =3D (1 << 12), /* Enable algorithms that ensure a live migration will eventually conv= erge. * This usually means the domain will be slowed down to make sure it d= oes @@ -811,7 +811,7 @@ typedef enum { * memory to the destination host. VIR_MIGRATE_PARAM_AUTO_CONVERGE_* * parameters can be used to tune the algorithm. */ - VIR_MIGRATE_AUTO_CONVERGE =3D (1 << 13), + VIR_MIGRATE_AUTO_CONVERGE =3D (1 << 13), /* This flag can be used with RDMA migration (i.e., when * VIR_MIGRATE_PARAM_URI starts with "rdma://") to tell the hypervisor @@ -828,27 +828,27 @@ typedef enum { * domain and the host itself since the host's kernel may run out of * memory. */ - VIR_MIGRATE_RDMA_PIN_ALL =3D (1 << 14), + VIR_MIGRATE_RDMA_PIN_ALL =3D (1 << 14), /* Setting the VIR_MIGRATE_POSTCOPY flag tells libvirt to enable post-= copy * migration. However, the migration will start normally and * virDomainMigrateStartPostCopy needs to be called to switch it into = the * post-copy mode. See virDomainMigrateStartPostCopy for more details. */ - VIR_MIGRATE_POSTCOPY =3D (1 << 15), + VIR_MIGRATE_POSTCOPY =3D (1 << 15), /* Setting the VIR_MIGRATE_TLS flag will cause the migration to attempt * to use the TLS environment configured by the hypervisor in order to * perform the migration. If incorrectly configured on either source or * destination, the migration will fail. */ - VIR_MIGRATE_TLS =3D (1 << 16), + VIR_MIGRATE_TLS =3D (1 << 16), /* Send memory pages to the destination host through several network * connections. See VIR_MIGRATE_PARAM_PARALLEL_* parameters for * configuring the parallel migration. */ - VIR_MIGRATE_PARALLEL =3D (1 << 17), + VIR_MIGRATE_PARALLEL =3D (1 << 17), } virDomainMigrateFlags; --=20 2.31.1 From nobody Wed May 1 17:41:19 2024 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=1638543861; cv=none; d=zohomail.com; s=zohoarc; b=S/UuXDLy+O7Fb7iN4fo8lVkA2WDwRzE2lBIk/gprNAWgn638loo8eEGKNx+T/z32G2k2cty7S3fZ1gycH3YpcMsIZtC9VT8s9p1xVRHP8yCl0RLPLEVBPJkMJI2tU8at+jDv8yiLOayf/uBt+QZhJoXeb6q5jXw8ABLq2EZoy00= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1638543861; 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=NEp1V8xOA7DdGliJ0japrSpsekbasPX2K1lFoFDjK20=; b=Renx0i2BvxZe2R/+WyjjOSPM1PmRyf+gdXQLtr3o7OOwTJ3HCergzhJnwaP1vMN61MeZPKMQm505s90Lt/xxdjAC1Ra68oj1DHRSY9H5z5HXmjh59fP7M2he4/rYQc6NdYXFQUJStpjdhHn+Mqdwh0tM6PgD1v8CTdX2xKSilyo= 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 1638543861051336.1229538679552; Fri, 3 Dec 2021 07:04:21 -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-321-Y5fDTQj2PkWJt8RApOqAjA-1; Fri, 03 Dec 2021 10:04:16 -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 2442C835E38; Fri, 3 Dec 2021 15:04:06 +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 EE3887945A; Fri, 3 Dec 2021 15:04:05 +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 AED1D4A700; Fri, 3 Dec 2021 15:04:05 +0000 (UTC) Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) by lists01.pubmisc.prod.ext.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id 1B3F42oU031185 for ; Fri, 3 Dec 2021 10:04:02 -0500 Received: by smtp.corp.redhat.com (Postfix) id 1FFA05D9D5; Fri, 3 Dec 2021 15:04:02 +0000 (UTC) Received: from speedmetal.lan (unknown [10.40.208.10]) by smtp.corp.redhat.com (Postfix) with ESMTP id 73F815E24E for ; Fri, 3 Dec 2021 15:04:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1638543860; 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=NEp1V8xOA7DdGliJ0japrSpsekbasPX2K1lFoFDjK20=; b=QvbKlz3vUpDczOdTqgek42dVfnaYTGzKBeo5gCVraQpfBK8K/RiKFymVrvmtQxkLR23I7I kRON/unSBwDQgkZXhoh0tjTY0ZYpDCvHfSpVhh2CpYZPFHuLvmR46xDnsAhQ2Sd2k5t5k4 z0UHJylqukQ2KSLpnBqEmaIbivIdUkQ= X-MC-Unique: Y5fDTQj2PkWJt8RApOqAjA-1 From: Peter Krempa To: libvir-list@redhat.com Subject: [PATCH 11/17] man: virsh: Separate paragrapsh describing distinct flags Date: Fri, 3 Dec 2021 16:01:50 +0100 Message-Id: <94c7e63b718bca0398b6dbe76444ca931be3f22e.1638543496.git.pkrempa@redhat.com> In-Reply-To: References: MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 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: 1638543862210100002 Content-Type: text/plain; charset="utf-8" Separate the paragragraphs where the topic changes to simplify further additions. Signed-off-by: Peter Krempa Reviewed-by: J=C3=A1n Tomko --- docs/manpages/virsh.rst | 32 ++++++++++++++++++++------------ 1 file changed, 20 insertions(+), 12 deletions(-) diff --git a/docs/manpages/virsh.rst b/docs/manpages/virsh.rst index 9728f36a78..7c50388216 100644 --- a/docs/manpages/virsh.rst +++ b/docs/manpages/virsh.rst @@ -3187,9 +3187,12 @@ for peer-2-peer migration; *--direct* for direct mig= ration; or *--tunnelled* for tunnelled migration. *--offline* migrates domain definition without starting the domain on destination and without stopping it on source host. Offline migration may be used with inactive domains and it must be used wi= th -*--persistent* option. *--persistent* leaves the domain persistent on -destination host, *--undefinesource* undefines the domain on the source ho= st, -and *--suspend* leaves the domain paused on the destination host. +*--persistent* option. + +*--persistent* leaves the domain persistent on destination host, +*--undefinesource* undefines the domain on the source host, and *--suspend* +leaves the domain paused on the destination host. + *--copy-storage-all* indicates migration with non-shared storage with full disk copy, *--copy-storage-inc* indicates migration with non-shared storage with incremental copy (same base image shared between source and destinati= on). @@ -3198,15 +3201,20 @@ In both cases the disk images have to exist on dest= ination host, the images on source host to the images found at the same place on the destina= tion host. By default only non-shared non-readonly images are transferred. Use *--migrate-disks* to explicitly specify a list of disk targets to -transfer via the comma separated ``disk-list`` argument. *--change-protect= ion* -enforces that no incompatible configuration changes will be made to the do= main -while the migration is underway; this flag is implicitly enabled when supp= orted -by the hypervisor, but can be explicitly used to reject the migration if t= he -hypervisor lacks change protection support. *--verbose* displays the prog= ress -of migration. *--abort-on-error* cancels -the migration if a soft error (for example I/O error) happens during the -migration. *--postcopy* enables post-copy logic in migration, but does not -actually start post-copy, i.e., migration is started in pre-copy mode. +transfer via the comma separated ``disk-list`` argument. + +*--change-protection* enforces that no incompatible configuration changes = will +be made to the domain while the migration is underway; this flag is implic= itly +enabled when supported by the hypervisor, but can be explicitly used to re= ject +the migration if the hypervisor lacks change protection support. + +*--verbose* displays the progress of migration. + +*--abort-on-error* cancels the migration if a soft error (for example I/O = error) +happens during the migration. + +*--postcopy* enables post-copy logic in migration, but does not actually s= tart +post-copy, i.e., migration is started in pre-copy mode. Once migration is running, the user may switch to post-copy using the ``migrate-postcopy`` command sent from another virsh instance or use *--postcopy-after-precopy* along with *--postcopy* to let libvirt --=20 2.31.1 From nobody Wed May 1 17:41:19 2024 Delivered-To: importer@patchew.org Received-SPF: pass (zohomail.com: domain of redhat.com designates 170.10.133.124 as permitted sender) client-ip=170.10.133.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.133.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=1638543860; cv=none; d=zohomail.com; s=zohoarc; b=QJ9JU6OTh/6y7VOZ5Esi1jlHKxRz2KNYTd862tS6K9vcoMi0vqOGvHp6lKDlMiFuQ9dZfhnWcGx3YsO1LvnUmEEKXn/9wRLmbasMfeUoIgAi+2sh5nqwNhqcn/eJ06icWz/znrj7vr0qplW0ITIbSeYX3IMQRsUpMV6wm8XCvRg= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1638543860; 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=Q925W1vXz0D8Po7oDXK0n8CSdt8ZjJO4iZvM+wsAkIc=; b=GfsNl4hHq9D/0UTUshyu9dfgfh6Vry2Pbq/PUrLmyRY7ZcpKuxDn1UGMYQ6ekcjz0f6fg6zhDvQKjrcjpeZX2T11ZL7Hdp8Si3noEKDlcUsDsZZkRudlR5aDTuEzw23VGgP2pN0ZC/6mvtMLWyRa0CmK+AWfwW0TKrQrbNzK+T8= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of redhat.com designates 170.10.133.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.133.124]) by mx.zohomail.com with SMTPS id 1638543860624265.73813605258056; Fri, 3 Dec 2021 07:04:20 -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-180-BJgrmfNaPz6awULwkQD08Q-1; Fri, 03 Dec 2021 10:04:16 -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 96BFD835E32; Fri, 3 Dec 2021 15:04:05 +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 77AAB10016FE; Fri, 3 Dec 2021 15:04:05 +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 215181802E34; Fri, 3 Dec 2021 15:04:05 +0000 (UTC) Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) by lists01.pubmisc.prod.ext.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id 1B3F43Ml031193 for ; Fri, 3 Dec 2021 10:04:03 -0500 Received: by smtp.corp.redhat.com (Postfix) id 454F75ED2F; Fri, 3 Dec 2021 15:04:03 +0000 (UTC) Received: from speedmetal.lan (unknown [10.40.208.10]) by smtp.corp.redhat.com (Postfix) with ESMTP id 8C4815DAA5 for ; Fri, 3 Dec 2021 15:04:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1638543859; 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=Q925W1vXz0D8Po7oDXK0n8CSdt8ZjJO4iZvM+wsAkIc=; b=OdItGEJM9kw2LfA82QzJ21hfwDzc9JJGWRM5y2HP6oPviorTsp3PhX8Kioea0d41JgrI1u OWvjpl+1ZgJgmgX3lvlvjjnnGQoXXrH+j5OVKZvetrQ1cOhTzp/8NGqrk4SHjVzDi8RjKl o9502CMgfovsEhXV4EL49jbSIq4aDxw= X-MC-Unique: BJgrmfNaPz6awULwkQD08Q-1 From: Peter Krempa To: libvir-list@redhat.com Subject: [PATCH 12/17] VIR_REQUIRE_FLAG_(GOTO|RET): Add parens around arguments in expansion Date: Fri, 3 Dec 2021 16:01:51 +0100 Message-Id: <9dbe0a2f0afe58c652a6dc634cdf35357be14ae8.1638543496.git.pkrempa@redhat.com> In-Reply-To: References: MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 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.84 on 10.5.11.22 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: 1638543862111100001 Content-Type: text/plain; charset="utf-8" Make the macro useful also for cases when one of multiple flags is required. Signed-off-by: Peter Krempa Reviewed-by: J=C3=A1n Tomko --- src/internal.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/internal.h b/src/internal.h index 2e404cd705..b6e4332542 100644 --- a/src/internal.h +++ b/src/internal.h @@ -374,7 +374,7 @@ */ #define VIR_REQUIRE_FLAG_RET(FLAG1, FLAG2, RET) \ do { \ - if ((flags & FLAG1) && !(flags & FLAG2)) { \ + if ((flags & (FLAG1)) && !(flags & (FLAG2))) { \ virReportInvalidArg(ctl, \ _("Flag '%s' is required by flag '%s'"), \ #FLAG2, #FLAG1); \ @@ -396,7 +396,7 @@ */ #define VIR_REQUIRE_FLAG_GOTO(FLAG1, FLAG2, LABEL) \ do { \ - if ((flags & FLAG1) && !(flags & FLAG2)) { \ + if ((flags & (FLAG1)) && !(flags & (FLAG2))) { \ virReportInvalidArg(ctl, \ _("Flag '%s' is required by flag '%s'"), \ #FLAG2, #FLAG1); \ --=20 2.31.1 From nobody Wed May 1 17:41:19 2024 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=1638543858; cv=none; d=zohomail.com; s=zohoarc; b=MNYGLKpUIfpVy2nH+MjnZL0X+3/c8VsF1vfitDow5A6l59LHxx6wgjneya12xay4RSxJOnRu7OXzwTwCbdY4620pxUuXPXrsXroYGG8JSgI7DqdkBrYm7vfSoRGVP3M0zYk3cvTxo8WQbnDrYBo+4v43i+eEy9aaMG3c/fC2P50= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1638543858; 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=R86AHGcsUTcq3Nw8varfGJ4PcyuzD077JibZTf2UqPA=; b=kq025Vkl2O8HJ3i4YQSuICnP37lNOyNFmTWwxK3kZG1s0+JX4AYUYfbjrLCBCEEDY/I7xaHor1wE353KJ35SSv2rVknHOjEv39sySMKT8ZHF6gejQ0SRWknkU7lBWunEikEQA0l0t55DBfZLOt/SQFdNf0gYnMUxlYcccwNOL5A= 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 1638543858723888.2139129384227; Fri, 3 Dec 2021 07:04:18 -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-37-R2Y_Sx3lNcu-IZhMNIuHDQ-1; Fri, 03 Dec 2021 10:04:13 -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 AD09683DBF5; Fri, 3 Dec 2021 15:04:06 +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 82D705E26C; Fri, 3 Dec 2021 15:04:06 +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 4E14B1802E38; Fri, 3 Dec 2021 15:04:06 +0000 (UTC) Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) by lists01.pubmisc.prod.ext.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id 1B3F44gr031209 for ; Fri, 3 Dec 2021 10:04:04 -0500 Received: by smtp.corp.redhat.com (Postfix) id 588BA5DAA5; Fri, 3 Dec 2021 15:04:04 +0000 (UTC) Received: from speedmetal.lan (unknown [10.40.208.10]) by smtp.corp.redhat.com (Postfix) with ESMTP id A47CF5D9D5 for ; Fri, 3 Dec 2021 15:04:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1638543857; 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=R86AHGcsUTcq3Nw8varfGJ4PcyuzD077JibZTf2UqPA=; b=N7O0/qoa8zhVcey8xdNf9XCvQzNZweo8NVLeI1wmdezYPBBXEX7U5UGyP6twSLPzJFeRWh 9xJdCqu6WOavOrV/XCOxURqDcRtifGcwGJHzYUa2s2zrRH5CZ7Zw5xvBroF59iBa+/CVCt GDLXF08BW3v8CDQ9WgcIL82uHoSfZeI= X-MC-Unique: R2Y_Sx3lNcu-IZhMNIuHDQ-1 From: Peter Krempa To: libvir-list@redhat.com Subject: [PATCH 13/17] virDomainMigrate: Introduce VIR_MIGRATE_NON_SHARED_SYNCHRONOUS_WRITES flag Date: Fri, 3 Dec 2021 16:01:52 +0100 Message-Id: In-Reply-To: References: MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 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.14 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: 1638543859160100006 Content-Type: text/plain; charset="utf-8" Non-shared storage migration of guests which are disk I/O intensive and have fast local storage may actually never converge if the guest happens to dirty the disk faster than it can be copied. This patch introduces a new flag 'VIR_MIGRATE_NON_SHARED_SYNCHRONOUS_WRITES' which will instruct hypervisors to synchronize local I/O writes with the writes to remote storage used for migration so that the guest can't overwhelm the migration. This comes at a cost of decreased local I/O performance for guests which behave well on average. Signed-off-by: Peter Krempa Reviewed-by: J=C3=A1n Tomko --- docs/manpages/virsh.rst | 6 +++++- include/libvirt/libvirt-domain.h | 10 ++++++++++ src/libvirt-domain.c | 20 ++++++++++++++++++++ tools/virsh-domain.c | 13 +++++++++++++ 4 files changed, 48 insertions(+), 1 deletion(-) diff --git a/docs/manpages/virsh.rst b/docs/manpages/virsh.rst index 7c50388216..1ce3e77c9f 100644 --- a/docs/manpages/virsh.rst +++ b/docs/manpages/virsh.rst @@ -3180,7 +3180,7 @@ migrate [--postcopy-bandwidth bandwidth] [--parallel [--parallel-connections connections]] [--bandwidth bandwidth] [--tls-destination hostname] - [--disks-uri URI] + [--disks-uri URI] [--copy-storage-synchronous-writes] Migrate domain to another host. Add *--live* for live migration; <--p2p> for peer-2-peer migration; *--direct* for direct migration; or *--tunnelle= d* @@ -3202,6 +3202,10 @@ images on source host to the images found at the sam= e place on the destination host. By default only non-shared non-readonly images are transferred. Use *--migrate-disks* to explicitly specify a list of disk targets to transfer via the comma separated ``disk-list`` argument. +With *--copy-storage-synchronous-writes* flag used the disk data migration= will +synchronous handle guest disk writes to both the original soure and the +destination to ensure that the disk migration coverges at the price of pos= sibly +decreased burst performance. *--change-protection* enforces that no incompatible configuration changes = will be made to the domain while the migration is underway; this flag is implic= itly diff --git a/include/libvirt/libvirt-domain.h b/include/libvirt/libvirt-dom= ain.h index f81e96d374..d0dd11ab01 100644 --- a/include/libvirt/libvirt-domain.h +++ b/include/libvirt/libvirt-domain.h @@ -850,6 +850,16 @@ typedef enum { */ VIR_MIGRATE_PARALLEL =3D (1 << 17), + /* Force the guest writes which happen when copying disk images for + * non-shared storage migration to be synchronously written to the + * destination. This ensures the storage migration converges for VMs + * doing heavy I/O on fast local storage and slow mirror. + * + * Requires one of VIR_MIGRATE_NON_SHARED_DISK, VIR_MIGRATE_NON_SHARE= D_INC + * to be present as well. + */ + VIR_MIGRATE_NON_SHARED_SYNCHRONOUS_WRITES =3D (1 << 18), + } virDomainMigrateFlags; diff --git a/src/libvirt-domain.c b/src/libvirt-domain.c index 8ee2490867..5708ff839b 100644 --- a/src/libvirt-domain.c +++ b/src/libvirt-domain.c @@ -3567,6 +3567,10 @@ virDomainMigrate(virDomainPtr domain, VIR_MIGRATE_PARALLEL, error); + VIR_REQUIRE_FLAG_GOTO(VIR_MIGRATE_NON_SHARED_SYNCHRONOUS_WRITES, + VIR_MIGRATE_NON_SHARED_DISK | VIR_MIGRATE_NON_SH= ARED_INC, + error); + if (flags & VIR_MIGRATE_OFFLINE) { rc =3D VIR_DRV_SUPPORTS_FEATURE(domain->conn->driver, domain->conn, VIR_DRV_FEATURE_MIGRATION_OFFLINE); @@ -3760,6 +3764,10 @@ virDomainMigrate2(virDomainPtr domain, VIR_MIGRATE_PARALLEL, error); + VIR_REQUIRE_FLAG_GOTO(VIR_MIGRATE_NON_SHARED_SYNCHRONOUS_WRITES, + VIR_MIGRATE_NON_SHARED_DISK | VIR_MIGRATE_NON_SH= ARED_INC, + error); + if (flags & VIR_MIGRATE_OFFLINE) { rc =3D VIR_DRV_SUPPORTS_FEATURE(domain->conn->driver, domain->conn, VIR_DRV_FEATURE_MIGRATION_OFFLINE); @@ -3966,6 +3974,14 @@ virDomainMigrate3(virDomainPtr domain, VIR_MIGRATE_NON_SHARED_INC, error); + VIR_REQUIRE_FLAG_GOTO(VIR_MIGRATE_NON_SHARED_SYNCHRONOUS_WRITES, + VIR_MIGRATE_NON_SHARED_DISK | VIR_MIGRATE_NON_SH= ARED_INC, + error); + + VIR_REQUIRE_FLAG_GOTO(VIR_MIGRATE_NON_SHARED_SYNCHRONOUS_WRITES, + VIR_MIGRATE_NON_SHARED_DISK | VIR_MIGRATE_NON_SH= ARED_INC, + error); + if (flags & VIR_MIGRATE_PEER2PEER) { virReportInvalidArg(flags, "%s", _("use virDomainMigrateToURI3 for peer-to-peer= " @@ -4137,6 +4153,10 @@ int virDomainMigrateUnmanagedCheckCompat(virDomainPt= r domain, VIR_MIGRATE_NON_SHARED_INC, -1); + VIR_REQUIRE_FLAG_RET(VIR_MIGRATE_NON_SHARED_SYNCHRONOUS_WRITES, + VIR_MIGRATE_NON_SHARED_DISK | VIR_MIGRATE_NON_SHA= RED_INC, + -1); + if (flags & VIR_MIGRATE_OFFLINE) { rc =3D VIR_DRV_SUPPORTS_FEATURE(domain->conn->driver, domain->conn, VIR_DRV_FEATURE_MIGRATION_OFFLINE); diff --git a/tools/virsh-domain.c b/tools/virsh-domain.c index a00b4cc243..8379f9f135 100644 --- a/tools/virsh-domain.c +++ b/tools/virsh-domain.c @@ -10543,6 +10543,10 @@ static const vshCmdOptDef opts_migrate[] =3D { .type =3D VSH_OT_BOOL, .help =3D N_("migration with non-shared storage with incremental copy= (same base image shared between source and destination)") }, + {.name =3D "copy-storage-synchronous-writes", + .type =3D VSH_OT_BOOL, + .help =3D N_("force guest disk writes to be synchronously written to = the destination to improve storage migration convergence") + }, {.name =3D "change-protection", .type =3D VSH_OT_BOOL, .help =3D N_("prevent any configuration changes to domain until migra= tion ends") @@ -10949,6 +10953,15 @@ doMigrate(void *opaque) if (vshCommandOptBool(cmd, "copy-storage-inc")) flags |=3D VIR_MIGRATE_NON_SHARED_INC; + if (vshCommandOptBool(cmd, "copy-storage-synchronous-writes")) { + if (!(flags & VIR_MIGRATE_NON_SHARED_DISK) && + !(flags & VIR_MIGRATE_NON_SHARED_INC)) { + vshError(ctl, "'--copy-storage-synchronous-writes' requires on= e of '--copy-storage-all', 'copy-storage-inc'"); + goto out; + } + flags |=3D VIR_MIGRATE_NON_SHARED_SYNCHRONOUS_WRITES; + } + if (vshCommandOptBool(cmd, "change-protection")) flags |=3D VIR_MIGRATE_CHANGE_PROTECTION; --=20 2.31.1 From nobody Wed May 1 17:41:19 2024 Delivered-To: importer@patchew.org Received-SPF: pass (zohomail.com: domain of redhat.com designates 170.10.133.124 as permitted sender) client-ip=170.10.133.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.133.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=1638543858; cv=none; d=zohomail.com; s=zohoarc; b=nh885hjlIfi2lQOvLUQxlwpx/opwcvsRRQbMkHIYn0v2WGFNeIb+rH+9yXqGombrjVhENO2uMYx9mBL0m4kX6NMlyZcA3srrnLubVkcDXPmgCuLMFx6NADzkcpuJyUB6On4lCV1h8AzA5hYBQeWziKvRZ0y4fd+V6j7AtPzwP4k= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1638543858; 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=A6n5nCY4V+NbwC/OajgJsaAkByftGKbTR0FjmLimnoc=; b=Q6SU+akkaYOL+i43Uo4XFHuMwUaQkDczIrAJ7fIa6yja5tO6NuS6eQOuv2jOo8NE9/UPQd1TR33zliccQiQr7eduAa3Crt3RUr8Uea3i2d4P9VpEEW4tPqTxXyPJkhi0do4lXCuR5axajysoWRrBHwvWyDYuO12nQTZyFiNjg5g= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of redhat.com designates 170.10.133.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.133.124]) by mx.zohomail.com with SMTPS id 1638543858640164.65131799327116; Fri, 3 Dec 2021 07:04:18 -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-390-qzzK9AeUNTiIIUcxSZlV7w-1; Fri, 03 Dec 2021 10:04:15 -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 A3177190A7D2; Fri, 3 Dec 2021 15:04:08 +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 820BA79453; Fri, 3 Dec 2021 15:04:08 +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 4BA96180126E; Fri, 3 Dec 2021 15:04:08 +0000 (UTC) Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) by lists01.pubmisc.prod.ext.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id 1B3F45FP031222 for ; Fri, 3 Dec 2021 10:04:05 -0500 Received: by smtp.corp.redhat.com (Postfix) id 9613C5ED33; Fri, 3 Dec 2021 15:04:05 +0000 (UTC) Received: from speedmetal.lan (unknown [10.40.208.10]) by smtp.corp.redhat.com (Postfix) with ESMTP id C60625D9D5 for ; Fri, 3 Dec 2021 15:04:04 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1638543857; 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=A6n5nCY4V+NbwC/OajgJsaAkByftGKbTR0FjmLimnoc=; b=GImYepKkTXTjB+z7S7D1A8BSJsy22JzxlgvQt1YpqqrtNc2nVzqbgTz6w7XcVj7r1BbVIV 8T1WQNUfTYNShx60bQKyNiR6M+n4YUa/sp7QtW9zJnGZX0pMmVWWE7i/fXc6vKQb58H7a8 BIEMD4SkfRcavTgwKo9B5AduSHlDw10= X-MC-Unique: qzzK9AeUNTiIIUcxSZlV7w-1 From: Peter Krempa To: libvir-list@redhat.com Subject: [PATCH 14/17] qemu: migration: Implement VIR_MIGRATE_NON_SHARED_SYNCHRONOUS_WRITES Date: Fri, 3 Dec 2021 16:01:53 +0100 Message-Id: <7767ec14373d109391848135d5442bca51ec1d5f.1638543496.git.pkrempa@redhat.com> In-Reply-To: References: MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 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: 1638543859104100005 Content-Type: text/plain; charset="utf-8" Use it to enable the 'write-blocking' mode of 'blockdev-mirror'. Signed-off-by: Peter Krempa Reviewed-by: J=C3=A1n Tomko --- src/qemu/qemu_migration.c | 16 +++++++++++++--- src/qemu/qemu_migration.h | 1 + 2 files changed, 14 insertions(+), 3 deletions(-) diff --git a/src/qemu/qemu_migration.c b/src/qemu/qemu_migration.c index 00c33c869e..e32c5865f9 100644 --- a/src/qemu/qemu_migration.c +++ b/src/qemu/qemu_migration.c @@ -931,7 +931,8 @@ qemuMigrationSrcNBDStorageCopyBlockdev(virQEMUDriver *d= river, const char *socket, unsigned long long mirror_speed, unsigned int mirror_shallow, - const char *tlsAlias) + const char *tlsAlias, + bool syncWrites) { g_autoptr(qemuBlockStorageSourceAttachData) data =3D NULL; qemuDomainDiskPrivate *diskPriv =3D QEMU_DOMAIN_DISK_PRIVATE(disk); @@ -960,7 +961,7 @@ qemuMigrationSrcNBDStorageCopyBlockdev(virQEMUDriver *d= river, mon_ret =3D qemuMonitorBlockdevMirror(qemuDomainGetMonitor(vm), jo= bname, persistjob, sourcename, copysrc->nodeforma= t, mirror_speed, 0, 0, mirror_sha= llow, - false); + syncWrites); if (mon_ret !=3D 0) qemuBlockStorageSourceAttachRollback(qemuDomainGetMonitor(vm), dat= a); @@ -1034,6 +1035,7 @@ qemuMigrationSrcNBDStorageCopyOne(virQEMUDriver *driv= er, const char *jobname =3D NULL; const char *sourcename =3D NULL; bool persistjob =3D false; + bool syncWrites =3D !!(flags & VIR_MIGRATE_NON_SHARED_SYNCHRONOUS_WRIT= ES); int rc; int ret =3D -1; @@ -1063,7 +1065,8 @@ qemuMigrationSrcNBDStorageCopyOne(virQEMUDriver *driv= er, host, port, socket, mirror_speed, mirror_shallow, - tlsAlias); + tlsAlias, + syncWrites); } else { rc =3D qemuMigrationSrcNBDStorageCopyDriveMirror(driver, vm, diskA= lias, host, port, socket, @@ -2364,6 +2367,13 @@ qemuMigrationSrcBeginPhase(virQEMUDriver *driver, } if (flags & (VIR_MIGRATE_NON_SHARED_DISK | VIR_MIGRATE_NON_SHARED_INC)= ) { + if (flags & VIR_MIGRATE_NON_SHARED_SYNCHRONOUS_WRITES && + !virQEMUCapsGet(priv->qemuCaps, QEMU_CAPS_BLOCKDEV)) { + virReportError(VIR_ERR_OPERATION_UNSUPPORTED, "%s", + _("VIR_MIGRATE_NON_SHARED_SYNCHRONOUS_WRITES is= not supported by this QEMU")); + return NULL; + } + if (flags & VIR_MIGRATE_TUNNELLED) { if (virQEMUCapsGet(priv->qemuCaps, QEMU_CAPS_BLOCKDEV)) { virReportError(VIR_ERR_OPERATION_UNSUPPORTED, "%s", diff --git a/src/qemu/qemu_migration.h b/src/qemu/qemu_migration.h index dd74f8bc88..b233358a51 100644 --- a/src/qemu/qemu_migration.h +++ b/src/qemu/qemu_migration.h @@ -59,6 +59,7 @@ VIR_MIGRATE_POSTCOPY | \ VIR_MIGRATE_TLS | \ VIR_MIGRATE_PARALLEL | \ + VIR_MIGRATE_NON_SHARED_SYNCHRONOUS_WRITES | \ 0) /* All supported migration parameters and their types. */ --=20 2.31.1 From nobody Wed May 1 17:41:19 2024 Delivered-To: importer@patchew.org Received-SPF: pass (zohomail.com: domain of redhat.com designates 170.10.133.124 as permitted sender) client-ip=170.10.133.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.133.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=1638543909; cv=none; d=zohomail.com; s=zohoarc; b=PhXsKKz22bDKfkoiR2c+0cwt1rko1wqJI89Juhes1CxPUYO3Yq8EI+TLIM52NkdMqeZ4DtyiHqN2RFwpLo5o2Vwi03ijd9coS5XamhpFyTvN9Av1cymq8ci/PN56RYCEW4gf63SPMKJLQz98GiEYORoveVDmNxxEElximDsfCtw= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1638543909; 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=3YWZMWw4A/ncIkK7Fbwa7ZMLEpPn26GDGD6YpMQdjas=; b=MxuBkiBvG2LmWKdyRw4oW9PyVw/qcKVVZuyA0MEWgaX0HZM3muzh3KelBCoBstriZsxi7dGnWSI2Sr6Im2nXsg2ZLkbUejn0wUTLPaH2LfAFscIj2peRlH+F+HMJK5mX9hxAJ0VPxCPglobAW1CWn9hs4r/WPpK6UiQn0Zl6/mQ= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of redhat.com designates 170.10.133.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.133.124]) by mx.zohomail.com with SMTPS id 1638543909490785.2987642853456; Fri, 3 Dec 2021 07:05:09 -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-479-mXV3dG6JMQ2lqyAiblxYmA-1; Fri, 03 Dec 2021 10:04:23 -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 7A80B190B2AA; Fri, 3 Dec 2021 15:04: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 1A76F5DF21; Fri, 3 Dec 2021 15:04: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 DACA9181844F; Fri, 3 Dec 2021 15:04:10 +0000 (UTC) Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) by lists01.pubmisc.prod.ext.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id 1B3F47gt031232 for ; Fri, 3 Dec 2021 10:04:07 -0500 Received: by smtp.corp.redhat.com (Postfix) id 24F755D9D5; Fri, 3 Dec 2021 15:04:07 +0000 (UTC) Received: from speedmetal.lan (unknown [10.40.208.10]) by smtp.corp.redhat.com (Postfix) with ESMTP id EBC405ED2A for ; Fri, 3 Dec 2021 15:04:05 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1638543908; 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=3YWZMWw4A/ncIkK7Fbwa7ZMLEpPn26GDGD6YpMQdjas=; b=OZfRlw4gdwegjmaGZM8nlgEdft6yXhzdJaLDc+ElHLvoN6S5asCv145NblFl2C7/RVZ6Zp VDVtGK8mGOftoNMF3aZWcNOGmk5ecRaVbpGC3+dRozbFIlkDPe271qiC+xSUKbrhjBOco5 uchVvWuwELTSjoesmav8KCudxu4nc5M= X-MC-Unique: mXV3dG6JMQ2lqyAiblxYmA-1 From: Peter Krempa To: libvir-list@redhat.com Subject: [PATCH 15/17] docs: Convert 'migration' doc to RST Date: Fri, 3 Dec 2021 16:01:54 +0100 Message-Id: In-Reply-To: References: MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 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.14 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: 1638543910362100001 Content-Type: text/plain; charset="utf-8" After conversion the table doesn't have to custom colors, but otherwise seems to hold well. Signed-off-by: Peter Krempa Reviewed-by: J=C3=A1n Tomko --- docs/meson.build | 2 +- docs/migration.html.in | 688 ----------------------------------------- docs/migration.rst | 458 +++++++++++++++++++++++++++ 3 files changed, 459 insertions(+), 689 deletions(-) delete mode 100644 docs/migration.html.in create mode 100644 docs/migration.rst diff --git a/docs/meson.build b/docs/meson.build index fb6e0029d0..3aabb52950 100644 --- a/docs/meson.build +++ b/docs/meson.build @@ -77,7 +77,6 @@ docs_html_in_files =3D [ 'internals', 'java', 'logging', - 'migration', 'nss', 'pci-hotplug', 'php', @@ -121,6 +120,7 @@ docs_rst_files =3D [ 'hacking', 'libvirt-go', 'libvirt-go-xml', + 'migration', 'newreposetup', 'pci-addresses', 'platforms', diff --git a/docs/migration.html.in b/docs/migration.html.in deleted file mode 100644 index 627200f96a..0000000000 --- a/docs/migration.html.in +++ /dev/null @@ -1,688 +0,0 @@ - - - - -

Guest migration

- -
    - -

    - Migration of guests between hosts is a complicated problem with many= possible - solutions, each with their own positive and negative points. For max= imum - flexibility of both hypervisor integration, and administrator deploy= ment, - libvirt implements several options for migration. -

    - -

    Network data transports

    - -

    - There are two options for the data transport used during migration, = either - the hypervisor's own native transport, or t= unnelled - over a libvirtd connection. -

    - -

    Hypervisor native transport

    -

    - Native data transports may or may not support encryption, d= epending - on the hypervisor in question, but will typically have the lowest co= mputational costs - by minimising the number of data copies involved. The native data tr= ansports will also - require extra hypervisor-specific network configuration steps by the= administrator when - deploying a host. For some hypervisors, it might be necessary to ope= n up a large range - of ports on the firewall to allow multiple concurrent migration oper= ations. -

    - -

    - Modern hypervisors support TLS for encryption and authentication of = the - migration connections which can be enabled using the - VIR_MIGRATE_TLS flag. The qemu hypervisor driv= er - allows users to force use of TLS via the migrate_tls_force - knob configured in /etc/libvirt/qemu.conf. -

    - -

    - 3D"Migration= -

    - -

    libvirt tunnelled transport

    -

    - Tunnelled data transports will always be capable of strong = encryption - since they are able to leverage the capabilities built in to the lib= virt RPC protocol. - The downside of a tunnelled transport, however, is that there will b= e extra data copies - involved on both the source and destinations hosts as the data is mo= ved between libvirtd - and the hypervisor. This is likely to be a more significant problem = for guests with - very large RAM sizes, which dirty memory pages quickly. On the deplo= yment side, tunnelled - transports do not require any extra network configuration over and a= bove what's already - required for general libvirtd remote access<= /a>, and there is only - need for a single port to be open on the firewall to support multipl= e concurrent - migration operations. -

    - -

    - Note: Certain features such as migration of non-shared stor= age - (VIR_MIGRATE_NON_SHARED_DISK), the multi-connection mig= ration - (VIR_MIGRATE_PARALLEL), or post-copy migration - (VIR_MIGRATE_POSTCOPY) may not be available when using - libvirt's tunnelling. -

    - -

    - 3D"Migration= -

    - -

    Communication control paths/flows

    - -

    - Migration of virtual machines requires close co-ordination of the two - hosts involved, as well as the application invoking the migration, - which may be on the source, the destination, or a third host. -

    - -

    Managed direct migration

    - -

    - With managed direct migration, the libvirt client process - controls the various phases of migration. The client application must - be able to connect and authenticate with the libvirtd daemons on both - the source and destination hosts. There is no need for the two libvi= rtd - daemons to communicate with each other. If the client application - crashes, or otherwise loses its connection to libvirtd during the - migration process, an attempt will be made to abort the migration and - restart the guest CPUs on the source host. There may be scenarios - where this cannot be safely done, in which cases the guest will be - left paused on one or both of the hosts. -

    - -

    - 3D"M= -

    - - -

    Managed peer to peer migration

    - -

    - With peer to peer migration, the libvirt client process only - talks to the libvirtd daemon on the source host. The source libvirtd - daemon controls the entire migration process itself, by directly - connecting the destination host libvirtd. If the client application = crashes, - or otherwise loses its connection to libvirtd, the migration process - will continue uninterrupted until completion. Note that the - source libvirtd uses its own credentials (typically root) to - connect to the destination, rather than the credentials used - by the client to connect to the source; if these differ, it is - common to run into a situation where a client can connect to the - destination directly but the source cannot make the connection to - set up the peer-to-peer migration. -

    - -

    - 3D"Migr= -

    - - -

    Unmanaged direct migration

    - -

    - With unmanaged direct migration, neither the libvirt client - or libvirtd daemon control the migration process. Control is instead - delegated to the hypervisor's over management services (if any). The - libvirt client merely initiates the migration via the hypervisor's - management layer. If the libvirt client or libvirtd crash, the - migration process will continue uninterrupted until completion. -

    - -

    - 3D= -

    - - -

    Data security

    - -

    - Since the migration data stream includes a complete copy of the guest - OS RAM, snooping of the migration data stream may allow compromise - of sensitive guest information. If the virtualization hosts have - multiple network interfaces, or if the network switches support - tagged VLANs, then it is very desirable to separate guest network - traffic from migration or management traffic. -

    - -

    - In some scenarios, even a separate network for migration data may - not offer sufficient security. In this case it is possible to apply - encryption to the migration data stream. If the hypervisor does not - itself offer encryption, then the libvirt tunnelled migration - facility should be used. -

    - -

    Offline migration

    - -

    - Offline migration transfers the inactive definition of a domain - (which may or may not be active). After successful completion, the - domain remains in its current state on the source host and is defined - but inactive on the destination host. It's a bit more clever than - virsh dumpxml on source host followed by - virsh define on destination host, as offline migration - will run the pre-migration hook to update the domain XML on - destination host. Currently, copying non-shared storage or other file - based storages (e.g. UEFI variable storage) is not supported during - offline migration. -

    - -

    Migration URIs

    - -

    - Initiating a guest migration requires the client application to - specify up to three URIs, depending on the choice of control - flow and/or APIs used. The first URI is that of the libvirt - connection to the source host, where the virtual guest is - currently running. The second URI is that of the libvirt - connection to the destination host, where the virtual guest - will be moved to (and in peer-to-peer migrations, this is from - the perspective of the source, not the client). The third URI is - a hypervisor specific - URI used to control how the guest will be migrated. With - any managed migration flow, the first and second URIs are - compulsory, while the third URI is optional. With the - unmanaged direct migration mode, the first and third URIs are - compulsory and the second URI is not used. -

    - -

    - Ordinarily management applications only need to care about the - first and second URIs, which are both in the normal libvirt - connection URI format. Libvirt will then automatically determine - the hypervisor specific URI, by looking up the target host's - configured hostname. There are a few scenarios where the management - application may wish to have direct control over the third URI. -

    - -
      -
    1. The configured hostname is incorrect, or DNS is broken. If a - host has a hostname which will not resolve to match one of its - public IP addresses, then libvirt will generate an incorrect - URI. In this case the management application should specify the - hypervisor specific URI explicitly, using an IP address, or a - correct hostname.
      2. -
    2. The host has multiple network interfaces. If a host has multiple - network interfaces, it might be desirable for the migration data - stream to be sent over a specific interface for either security - or performance reasons. In this case the management application - should specify the hypervisor specific URI, using an IP address - associated with the network to be used.
      3. -
    3. The firewall restricts what ports are available. When libvirt - generates a migration URI it will pick a port number using hypervi= sor - specific rules. Some hypervisors only require a single port to be - open in the firewalls, while others require a whole range of port - numbers. In the latter case the management application may wish - to choose a specific port number outside the default range in order - to comply with local firewall policies.
      4. -
    4. The second URI uses UNIX transport method. In this advanced case - libvirt should not guess a *migrateuri* and it should be specified= using - UNIX socket path URI: unix:///path/to/socket.
      5. -
    - -

    Configuration file handling

    - -

    - There are two types of virtual machines known to libvirt. A tran= sient - guest only exists while it is running, and has no configuration file= stored - on disk. A persistent guest maintains a configuration file = on disk - even when it is not running. -

    - -

    - By default, a migration operation will not attempt to modify any con= figuration - files that may be stored on either the source or destination host. I= t is the - administrator, or management application's, responsibility to manage= distribution - of configuration files (if desired). It is important to note that th= e /etc/libvirt - directory MUST NEVER BE SHARED BETWEEN HOSTS. There= are some - typical scenarios that might be applicable: -

    - -
      -
    • Centralized configuration files outside libvirt, in shared stora= ge. A cluster - aware management application may maintain all the master guest co= nfiguration - files in a cluster filesystem. When attempting to start a guest, t= he config - will be read from the cluster FS and used to deploy a persistent g= uest. - For migration the configuration will need to be copied to the dest= ination - host and removed on the original. -
      • -
    • Centralized configuration files outside libvirt, in a database. = A data center - management application may not store configuration files at all. I= nstead it - may generate libvirt XML on the fly when a guest is booted. It wil= l typically - use transient guests, and thus not have to consider configuration = files during - migration. -
      • -
    • Distributed configuration inside libvirt. The configuration file= for each - guest is copied to every host where the guest is able to run. Upon= migration - the existing config merely needs to be updated with any changes. -
      • -
    • Ad-hoc configuration management inside libvirt. Each guest is ti= ed to a - specific host and rarely migrated. When migration is required, the= config - is moved from one host to the other. -
      • -
    - -

    - As mentioned above, libvirt will not modify configuration files duri= ng - migration by default. The virsh command has two flags to - influence this behaviour. The --undefinesource flag - will cause the configuration file to be removed on the source host - after a successful migration. The --persistent flag will - cause a configuration file to be created on the destination host - after a successful migration. The following table summarizes the - configuration file handling in all possible state and flag - combinations. -

    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    Before migrationFlagsAfter migration
    Source typeSource configDest config--undefinesource--persistentDest typeSource configDest config
    TransientNNNNTransientNN
    TransientNNYNTransientNN
    TransientNNNYPersistentNY
    TransientNNYYPersistentNY
    TransientNYNNPersistentNY
    (unchanged dest config)
    TransientNYYNPersistentNY
    (unchanged dest config)
    TransientNYNYPersistentNY
    (replaced with source)
    TransientNYYYPersistentNY
    (replaced with source)
    PersistentYNNNTransientYN
    PersistentYNYNTransientNN
    PersistentYNNYPersistentYY
    PersistentYNYYPersistentNY
    PersistentYYNNPersistentYY
    (unchanged dest config)
    PersistentYYYNPersistentNY
    (unchanged dest config)
    PersistentYYNYPersistentYY
    (replaced with source)
    PersistentYYYYPersistentNY
    (replaced with source)
    - -

    Migration scenarios

    - - -

    Native migration, client to two lib= virtd servers

    - -

    - At an API level this requires use of virDomainMigrate, without the - VIR_MIGRATE_PEER2PEER flag set. The destination libvirtd server - will automatically determine the native hypervisor URI for migration - based off the primary hostname. To force migration over an alternate - network interface the optional hypervisor specific URI must be provi= ded -

    - - 
    -syntax: virsh migrate GUESTNAME DEST-LIBVIRT-URI [HV-URI]
-
-
-eg using default network interface
-
-virsh migrate web1 qemu+ssh://desthost/system
-virsh migrate web1 xen+tls://desthost/system
-
-
-eg using secondary network interface
-
-virsh migrate web1 qemu://desthost/system tcp://10.0.0.1/
-
    - -

    - Supported by Xen, QEMU, VMware and VirtualBox drivers -

    - -

    Native migration, client to and = peer2peer between, two libvirtd servers

    - -

    - virDomainMigrate, with the VIR_MIGRATE_PEER2PEER flag set, - using the libvirt URI format for the 'uri' parameter. The - destination libvirtd server will automatically determine - the native hypervisor URI for migration, based off the - primary hostname. The optional uri parameter controls how - the source libvirtd connects to the destination libvirtd, - in case it is not accessible using the same address that - the client uses to connect to the destination, or a different - encryption/auth scheme is required. There is no - scope for forcing an alternative network interface for the - native migration data with this method. -

    - -

    - This mode cannot be invoked from virsh -

    - -

    - Supported by QEMU driver -

    - -

    Tunnelled migration, client and= peer2peer between two libvirtd servers

    - -

    - virDomainMigrate, with the VIR_MIGRATE_PEER2PEER & VIR_MIGRATE_T= UNNELLED - flags set, using the libvirt URI format for the 'uri' parameter. The - destination libvirtd server will automatically determine - the native hypervisor URI for migration, based off the - primary hostname. The optional uri parameter controls how - the source libvirtd connects to the destination libvirtd, - in case it is not accessible using the same address that - the client uses to connect to the destination, or a different - encryption/auth scheme is required. The native hypervisor URI - format is not used at all. -

    - -

    - This mode cannot be invoked from virsh -

    - -

    - Supported by QEMU driver -

    - -

    Native migration, client to one li= bvirtd server

    - -

    - virDomainMigrateToURI, without the VIR_MIGRATE_PEER2PEER flag set, - using a hypervisor specific URI format for the 'uri' parameter. - There is no use or requirement for a destination libvirtd instance - at all. This is typically used when the hypervisor has its own - native management daemon available to handle incoming migration - attempts on the destination. -

    - - 
    -syntax: virsh migrate GUESTNAME HV-URI
-
-
-eg using same libvirt URI for all connections
-
-
    - -

    Native migration, peer2peer between two = libvirtd servers

    - -

    - virDomainMigrateToURI, with the VIR_MIGRATE_PEER2PEER flag set, - using the libvirt URI format for the 'uri' parameter. The - destination libvirtd server will automatically determine - the native hypervisor URI for migration, based off the - primary hostname. There is no scope for forcing an alternative - network interface for the native migration data with this - method. The destination URI must be reachable using the source - libvirtd credentials (which are not necessarily the same as the - credentials of the client in connecting to the source). -

    - - 
    -syntax: virsh migrate GUESTNAME DEST-LIBVIRT-URI [ALT-DEST-LIBVIRT-URI]
-
-
-eg using same libvirt URI for all connections
-
-virsh migrate --p2p web1 qemu+ssh://desthost/system
-
-
-eg using different libvirt URI auth scheme for peer2peer connections
-
-virsh migrate --p2p web1 qemu+ssh://desthost/system qemu+tls:/desthost/sys=
tem
-
-
-eg using different libvirt URI hostname for peer2peer connections
-
-virsh migrate --p2p web1 qemu+ssh://desthost/system qemu+ssh://10.0.0.1/sy=
stem
-
    - -

    - Supported by the QEMU driver -

    - -

    Tunnelled migration, peer2peer = between two libvirtd servers

    - -

    - virDomainMigrateToURI, with the VIR_MIGRATE_PEER2PEER & VIR_MIGR= ATE_TUNNELLED - flags set, using the libvirt URI format for the 'uri' parameter. The - destination libvirtd server will automatically determine - the native hypervisor URI for migration, based off the - primary hostname. The optional uri parameter controls how - the source libvirtd connects to the destination libvirtd, - in case it is not accessible using the same address that - the client uses to connect to the destination, or a different - encryption/auth scheme is required. The native hypervisor URI - format is not used at all. The destination URI must be - reachable using the source libvirtd credentials (which are not - necessarily the same as the credentials of the client in - connecting to the source). -

    - - 
    -syntax: virsh migrate GUESTNAME DEST-LIBVIRT-URI [ALT-DEST-LIBVIRT-URI]
-
-
-eg using same libvirt URI for all connections
-
-virsh migrate --p2p --tunnelled web1 qemu+ssh://desthost/system
-
-
-eg using different libvirt URI auth scheme for peer2peer connections
-
-virsh migrate --p2p --tunnelled web1 qemu+ssh://desthost/system qemu+tls:/=
desthost/system
-
-
-eg using different libvirt URI hostname for peer2peer connections
-
-virsh migrate --p2p --tunnelled web1 qemu+ssh://desthost/system qemu+ssh:/=
/10.0.0.1/system
-
    - -

    - Supported by QEMU driver -

    - - -

    Migration using only UNIX sockets=

    - -

    - In niche scenarios where libvirt daemon does not have access to the - network (e.g. running in a restricted container on a host that has - accessible network), when a management application wants to have com= plete - control over the transfer or when migrating between two containers o= n the - same host all the communication can be done using UNIX sockets. This - includes connecting to non-standard socket path for the destination - daemon, using UNIX sockets for hypervisor's communication or for the= NBD - data transfer. All of that can be used with both peer2peer and dire= ct - migration options. -

    - -

    - Example using /tmp/migdir as a directory representing t= he - same path visible from both libvirt daemons. That can be achieved by - bind-mounting the same directory to different containers running sep= arate - daemons or forwarding connections to these sockets manually - (using socat, netcat or a custom piece of - software): -

    - 
    -virsh migrate --domain web1 [--p2p] --copy-storage-all
-  --desturi 'qemu+unix:///system?socket=3D/tmp/migdir/test-sock-driver'
-  --migrateuri 'unix:///tmp/migdir/test-sock-qemu'
-  --disks-uri unix:///tmp/migdir/test-sock-nbd
-
    - -

    - One caveat is that on SELinux-enabled systems all the sockets that t= he - hypervisor is going to connect to needs to have the proper context a= nd - that is chosen before its creation by the process that creates it. = That - is usually done by using setsockcreatecon{,raw}() funct= ions. - Generally *system_r:system_u:svirt_socket_t:s0* should do the trick,= but - check the SELinux rules and settings of your system. -

    - -

    - Supported by QEMU driver -

    - - - diff --git a/docs/migration.rst b/docs/migration.rst new file mode 100644 index 0000000000..0a40600462 --- /dev/null +++ b/docs/migration.rst @@ -0,0 +1,458 @@ +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D +Guest migration +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D + +.. contents:: + +Migration of guests between hosts is a complicated problem with many possi= ble +solutions, each with their own positive and negative points. For maximum +flexibility of both hypervisor integration, and administrator deployment, +libvirt implements several options for migration. + +Network data transports +----------------------- + +There are two options for the data transport used during migration, either= the +hypervisor's own **native** transport, or **tunnelled** over a libvirtd +connection. + +Hypervisor native transport +~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +*Native* data transports may or may not support encryption, depending on t= he +hypervisor in question, but will typically have the lowest computational c= osts +by minimising the number of data copies involved. The native data transpor= ts +will also require extra hypervisor-specific network configuration steps by= the +administrator when deploying a host. For some hypervisors, it might be nec= essary +to open up a large range of ports on the firewall to allow multiple concur= rent +migration operations. + +Modern hypervisors support TLS for encryption and authentication of the +migration connections which can be enabled using the ``VIR_MIGRATE_TLS`` f= lag. +The *qemu* hypervisor driver allows users to force use of TLS via the +``migrate_tls_force`` knob configured in ``/etc/libvirt/qemu.conf``. + +|Migration native path| + +libvirt tunnelled transport +~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +*Tunnelled* data transports will always be capable of strong encryption si= nce +they are able to leverage the capabilities built in to the libvirt RPC pro= tocol. +The downside of a tunnelled transport, however, is that there will be extr= a data +copies involved on both the source and destinations hosts as the data is m= oved +between libvirtd and the hypervisor. This is likely to be a more significa= nt +problem for guests with very large RAM sizes, which dirty memory pages qui= ckly. +On the deployment side, tunnelled transports do not require any extra netw= ork +configuration over and above what's already required for general libvirtd +`remote access `__, and there is only need for a single port = to be +open on the firewall to support multiple concurrent migration operations. + +*Note:* Certain features such as migration of non-shared storage +(``VIR_MIGRATE_NON_SHARED_DISK``), the multi-connection migration +(``VIR_MIGRATE_PARALLEL``), or post-copy migration (``VIR_MIGRATE_POSTCOPY= ``) +may not be available when using libvirt's tunnelling. + +|Migration tunnel path| + +Communication control paths/flows +--------------------------------- + +Migration of virtual machines requires close co-ordination of the two hosts +involved, as well as the application invoking the migration, which may be = on the +source, the destination, or a third host. + +Managed direct migration +~~~~~~~~~~~~~~~~~~~~~~~~ + +With *managed direct* migration, the libvirt client process controls the v= arious +phases of migration. The client application must be able to connect and +authenticate with the libvirtd daemons on both the source and destination = hosts. +There is no need for the two libvirtd daemons to communicate with each oth= er. If +the client application crashes, or otherwise loses its connection to libvi= rtd +during the migration process, an attempt will be made to abort the migrati= on and +restart the guest CPUs on the source host. There may be scenarios where th= is +cannot be safely done, in which cases the guest will be left paused on one= or +both of the hosts. + +|Migration direct, managed| + +Managed peer to peer migration +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +With *peer to peer* migration, the libvirt client process only talks to the +libvirtd daemon on the source host. The source libvirtd daemon controls the +entire migration process itself, by directly connecting the destination ho= st +libvirtd. If the client application crashes, or otherwise loses its connec= tion +to libvirtd, the migration process will continue uninterrupted until compl= etion. +Note that the source libvirtd uses its own credentials (typically root) to +connect to the destination, rather than the credentials used by the client= to +connect to the source; if these differ, it is common to run into a situati= on +where a client can connect to the destination directly but the source cann= ot +make the connection to set up the peer-to-peer migration. + +|Migration peer-to-peer| + +Unmanaged direct migration +~~~~~~~~~~~~~~~~~~~~~~~~~~ + +With *unmanaged direct* migration, neither the libvirt client or libvirtd = daemon +control the migration process. Control is instead delegated to the hypervi= sor's +over management services (if any). The libvirt client merely initiates the +migration via the hypervisor's management layer. If the libvirt client or +libvirtd crash, the migration process will continue uninterrupted until +completion. + +|Migration direct, unmanaged| + +Data security +------------- + +Since the migration data stream includes a complete copy of the guest OS R= AM, +snooping of the migration data stream may allow compromise of sensitive gu= est +information. If the virtualization hosts have multiple network interfaces,= or if +the network switches support tagged VLANs, then it is very desirable to se= parate +guest network traffic from migration or management traffic. + +In some scenarios, even a separate network for migration data may not offer +sufficient security. In this case it is possible to apply encryption to the +migration data stream. If the hypervisor does not itself offer encryption,= then +the libvirt tunnelled migration facility should be used. + +Offline migration +----------------- + +Offline migration transfers the inactive definition of a domain (which may= or +may not be active). After successful completion, the domain remains in its +current state on the source host and is defined but inactive on the destin= ation +host. It's a bit more clever than ``virsh dumpxml`` on source host followe= d by +``virsh define`` on destination host, as offline migration will run the +pre-migration hook to update the domain XML on destination host. Currently, +copying non-shared storage or other file based storages (e.g. UEFI variable +storage) is not supported during offline migration. + +Migration URIs +-------------- + +Initiating a guest migration requires the client application to specify up= to +three URIs, depending on the choice of control flow and/or APIs used. The = first +URI is that of the libvirt connection to the source host, where the virtual +guest is currently running. The second URI is that of the libvirt connecti= on to +the destination host, where the virtual guest will be moved to (and in +peer-to-peer migrations, this is from the perspective of the source, not t= he +client). The third URI is a hypervisor specific URI used to control how the +guest will be migrated. With any managed migration flow, the first and sec= ond +URIs are compulsory, while the third URI is optional. With the unmanaged d= irect +migration mode, the first and third URIs are compulsory and the second URI= is +not used. + +Ordinarily management applications only need to care about the first and s= econd +URIs, which are both in the normal libvirt connection URI format. Libvirt = will +then automatically determine the hypervisor specific URI, by looking up the +target host's configured hostname. There are a few scenarios where the +management application may wish to have direct control over the third URI. + +#. The configured hostname is incorrect, or DNS is broken. If a host has a + hostname which will not resolve to match one of its public IP addresses= , then + libvirt will generate an incorrect URI. In this case the management + application should specify the hypervisor specific URI explicitly, usin= g an + IP address, or a correct hostname. +#. The host has multiple network interfaces. If a host has multiple network + interfaces, it might be desirable for the migration data stream to be s= ent + over a specific interface for either security or performance reasons. I= n this + case the management application should specify the hypervisor specific = URI, + using an IP address associated with the network to be used. +#. The firewall restricts what ports are available. When libvirt generates= a + migration URI it will pick a port number using hypervisor specific rule= s. + Some hypervisors only require a single port to be open in the firewalls, + while others require a whole range of port numbers. In the latter case = the + management application may wish to choose a specific port number outsid= e the + default range in order to comply with local firewall policies. +#. The second URI uses UNIX transport method. In this advanced case libvirt + should not guess a \*migrateuri\* and it should be specified using UNIX + socket path URI: ``unix:///path/to/socket``. + +Configuration file handling +--------------------------- + +There are two types of virtual machines known to libvirt. A *transient* gu= est +only exists while it is running, and has no configuration file stored on d= isk. A +*persistent* guest maintains a configuration file on disk even when it is = not +running. + +By default, a migration operation will not attempt to modify any configura= tion +files that may be stored on either the source or destination host. It is t= he +administrator, or management application's, responsibility to manage +distribution of configuration files (if desired). It is important to note = that +the ``/etc/libvirt`` directory **MUST NEVER BE SHARED BETWEEN HOSTS**. The= re are +some typical scenarios that might be applicable: + +- Centralized configuration files outside libvirt, in shared storage. A c= luster + aware management application may maintain all the master guest configur= ation + files in a cluster filesystem. When attempting to start a guest, the co= nfig + will be read from the cluster FS and used to deploy a persistent guest.= For + migration the configuration will need to be copied to the destination h= ost + and removed on the original. +- Centralized configuration files outside libvirt, in a database. A data = center + management application may not store configuration files at all. Instea= d it + may generate libvirt XML on the fly when a guest is booted. It will typ= ically + use transient guests, and thus not have to consider configuration files + during migration. +- Distributed configuration inside libvirt. The configuration file for ea= ch + guest is copied to every host where the guest is able to run. Upon migr= ation + the existing config merely needs to be updated with any changes. +- Ad-hoc configuration management inside libvirt. Each guest is tied to a + specific host and rarely migrated. When migration is required, the conf= ig is + moved from one host to the other. + +As mentioned above, libvirt will not modify configuration files during mig= ration +by default. The ``virsh`` command has two flags to influence this behaviou= r. The +``--undefinesource`` flag will cause the configuration file to be removed = on the +source host after a successful migration. The ``--persistent`` flag will c= ause a +configuration file to be created on the destination host after a successful +migration. The following table summarizes the configuration file handling = in all +possible state and flag combinations. + ++-------------------+-------------------+-------------------+-------------= ------+-------------------+-------------------+-------------------+--------= -----------+ +| Before migration | Flags = | After migration = | ++-------------------+-------------------+-------------------+-------------= ------+-------------------+-------------------+-------------------+--------= -----------+ +| Source type | Source config | Dest config | --undefineso= urce | --persistent | Dest type | Source config | Dest co= nfig | ++=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=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=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= =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+ +| Transient | N | N | N = | N | Transient | N | N = | ++-------------------+-------------------+-------------------+-------------= ------+-------------------+-------------------+-------------------+--------= -----------+ +| Transient | N | N | Y = | N | Transient | N | N = | ++-------------------+-------------------+-------------------+-------------= ------+-------------------+-------------------+-------------------+--------= -----------+ +| Transient | N | N | N = | Y | Persistent | N | Y = | ++-------------------+-------------------+-------------------+-------------= ------+-------------------+-------------------+-------------------+--------= -----------+ +| Transient | N | N | Y = | Y | Persistent | N | Y = | ++-------------------+-------------------+-------------------+-------------= ------+-------------------+-------------------+-------------------+--------= -----------+ +| Transient | N | Y | N = | N | Persistent | N | Y = | +| | | | = | | | | (unchan= ged dest | +| | | | = | | | | config)= | ++-------------------+-------------------+-------------------+-------------= ------+-------------------+-------------------+-------------------+--------= -----------+ +| Transient | N | Y | Y = | N | Persistent | N | Y = | +| | | | = | | | | (unchan= ged dest | +| | | | = | | | | config)= | ++-------------------+-------------------+-------------------+-------------= ------+-------------------+-------------------+-------------------+--------= -----------+ +| Transient | N | Y | N = | Y | Persistent | N | Y = | +| | | | = | | | | (replac= ed with | +| | | | = | | | | source)= | ++-------------------+-------------------+-------------------+-------------= ------+-------------------+-------------------+-------------------+--------= -----------+ +| Transient | N | Y | Y = | Y | Persistent | N | Y = | +| | | | = | | | | (replac= ed with | +| | | | = | | | | source)= | ++-------------------+-------------------+-------------------+-------------= ------+-------------------+-------------------+-------------------+--------= -----------+ +| Persistent | Y | N | N = | N | Transient | Y | N = | ++-------------------+-------------------+-------------------+-------------= ------+-------------------+-------------------+-------------------+--------= -----------+ +| Persistent | Y | N | Y = | N | Transient | N | N = | ++-------------------+-------------------+-------------------+-------------= ------+-------------------+-------------------+-------------------+--------= -----------+ +| Persistent | Y | N | N = | Y | Persistent | Y | Y = | ++-------------------+-------------------+-------------------+-------------= ------+-------------------+-------------------+-------------------+--------= -----------+ +| Persistent | Y | N | Y = | Y | Persistent | N | Y = | ++-------------------+-------------------+-------------------+-------------= ------+-------------------+-------------------+-------------------+--------= -----------+ +| Persistent | Y | Y | N = | N | Persistent | Y | Y = | +| | | | = | | | | (unchan= ged dest | +| | | | = | | | | config)= | ++-------------------+-------------------+-------------------+-------------= ------+-------------------+-------------------+-------------------+--------= -----------+ +| Persistent | Y | Y | Y = | N | Persistent | N | Y = | +| | | | = | | | | (unchan= ged dest | +| | | | = | | | | config)= | ++-------------------+-------------------+-------------------+-------------= ------+-------------------+-------------------+-------------------+--------= -----------+ +| Persistent | Y | Y | N = | Y | Persistent | Y | Y = | +| | | | = | | | | (replac= ed with | +| | | | = | | | | source)= | ++-------------------+-------------------+-------------------+-------------= ------+-------------------+-------------------+-------------------+--------= -----------+ +| Persistent | Y | Y | Y = | Y | Persistent | N | Y = | +| | | | = | | | | (replac= ed with | +| | | | = | | | | source)= | ++-------------------+-------------------+-------------------+-------------= ------+-------------------+-------------------+-------------------+--------= -----------+ + +Migration scenarios +------------------- + +Native migration, client to two libvirtd servers +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +At an API level this requires use of virDomainMigrate, without the +VIR_MIGRATE_PEER2PEER flag set. The destination libvirtd server will +automatically determine the native hypervisor URI for migration based off = the +primary hostname. To force migration over an alternate network interface t= he +optional hypervisor specific URI must be provided + +:: + + syntax: virsh migrate GUESTNAME DEST-LIBVIRT-URI [HV-URI] + + + eg using default network interface + + virsh migrate web1 qemu+ssh://desthost/system + virsh migrate web1 xen+tls://desthost/system + + + eg using secondary network interface + + virsh migrate web1 qemu://desthost/system tcp://10.0.0.1/ + +Supported by Xen, QEMU, VMware and VirtualBox drivers + +Native migration, client to and peer2peer between, two libvirtd servers +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +virDomainMigrate, with the VIR_MIGRATE_PEER2PEER flag set, using the libvi= rt URI +format for the 'uri' parameter. The destination libvirtd server will +automatically determine the native hypervisor URI for migration, based off= the +primary hostname. The optional uri parameter controls how the source libvi= rtd +connects to the destination libvirtd, in case it is not accessible using t= he +same address that the client uses to connect to the destination, or a diff= erent +encryption/auth scheme is required. There is no scope for forcing an alter= native +network interface for the native migration data with this method. + +This mode cannot be invoked from virsh + +Supported by QEMU driver + +Tunnelled migration, client and peer2peer between two libvirtd servers +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +virDomainMigrate, with the VIR_MIGRATE_PEER2PEER & VIR_MIGRATE_TUNNELLED f= lags +set, using the libvirt URI format for the 'uri' parameter. The destination +libvirtd server will automatically determine the native hypervisor URI for +migration, based off the primary hostname. The optional uri parameter cont= rols +how the source libvirtd connects to the destination libvirtd, in case it i= s not +accessible using the same address that the client uses to connect to the +destination, or a different encryption/auth scheme is required. The native +hypervisor URI format is not used at all. + +This mode cannot be invoked from virsh + +Supported by QEMU driver + +Native migration, client to one libvirtd server +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +virDomainMigrateToURI, without the VIR_MIGRATE_PEER2PEER flag set, using a +hypervisor specific URI format for the 'uri' parameter. There is no use or +requirement for a destination libvirtd instance at all. This is typically = used +when the hypervisor has its own native management daemon available to hand= le +incoming migration attempts on the destination. + +:: + + syntax: virsh migrate GUESTNAME HV-URI + + + eg using same libvirt URI for all connections + + +Native migration, peer2peer between two libvirtd servers +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +virDomainMigrateToURI, with the VIR_MIGRATE_PEER2PEER flag set, using the +libvirt URI format for the 'uri' parameter. The destination libvirtd serve= r will +automatically determine the native hypervisor URI for migration, based off= the +primary hostname. There is no scope for forcing an alternative network int= erface +for the native migration data with this method. The destination URI must be +reachable using the source libvirtd credentials (which are not necessarily= the +same as the credentials of the client in connecting to the source). + +:: + + syntax: virsh migrate GUESTNAME DEST-LIBVIRT-URI [ALT-DEST-LIBVIRT-URI] + + + eg using same libvirt URI for all connections + + virsh migrate --p2p web1 qemu+ssh://desthost/system + + + eg using different libvirt URI auth scheme for peer2peer connections + + virsh migrate --p2p web1 qemu+ssh://desthost/system qemu+tls:/desthost/= system + + + eg using different libvirt URI hostname for peer2peer connections + + virsh migrate --p2p web1 qemu+ssh://desthost/system qemu+ssh://10.0.0.1= /system + +Supported by the QEMU driver + +Tunnelled migration, peer2peer between two libvirtd servers +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +virDomainMigrateToURI, with the VIR_MIGRATE_PEER2PEER & VIR_MIGRATE_TUNNEL= LED +flags set, using the libvirt URI format for the 'uri' parameter. The desti= nation +libvirtd server will automatically determine the native hypervisor URI for +migration, based off the primary hostname. The optional uri parameter cont= rols +how the source libvirtd connects to the destination libvirtd, in case it i= s not +accessible using the same address that the client uses to connect to the +destination, or a different encryption/auth scheme is required. The native +hypervisor URI format is not used at all. The destination URI must be reac= hable +using the source libvirtd credentials (which are not necessarily the same = as the +credentials of the client in connecting to the source). + +:: + + syntax: virsh migrate GUESTNAME DEST-LIBVIRT-URI [ALT-DEST-LIBVIRT-URI] + + + eg using same libvirt URI for all connections + + virsh migrate --p2p --tunnelled web1 qemu+ssh://desthost/system + + + eg using different libvirt URI auth scheme for peer2peer connections + + virsh migrate --p2p --tunnelled web1 qemu+ssh://desthost/system qemu+tl= s:/desthost/system + + + eg using different libvirt URI hostname for peer2peer connections + + virsh migrate --p2p --tunnelled web1 qemu+ssh://desthost/system qemu+ss= h://10.0.0.1/system + +Supported by QEMU driver + +Migration using only UNIX sockets +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +In niche scenarios where libvirt daemon does not have access to the network +(e.g. running in a restricted container on a host that has accessible netw= ork), +when a management application wants to have complete control over the tran= sfer +or when migrating between two containers on the same host all the communic= ation +can be done using UNIX sockets. This includes connecting to non-standard s= ocket +path for the destination daemon, using UNIX sockets for hypervisor's +communication or for the NBD data transfer. All of that can be used with b= oth +peer2peer and direct migration options. + +Example using ``/tmp/migdir`` as a directory representing the same path vi= sible +from both libvirt daemons. That can be achieved by bind-mounting the same +directory to different containers running separate daemons or forwarding +connections to these sockets manually (using ``socat``, ``netcat`` or a cu= stom +piece of software): + +:: + + virsh migrate --domain web1 [--p2p] --copy-storage-all + --desturi 'qemu+unix:///system?socket=3D/tmp/migdir/test-sock-driver' + --migrateuri 'unix:///tmp/migdir/test-sock-qemu' + --disks-uri unix:///tmp/migdir/test-sock-nbd + +One caveat is that on SELinux-enabled systems all the sockets that the +hypervisor is going to connect to needs to have the proper context and tha= t is +chosen before its creation by the process that creates it. That is usually= done +by using ``setsockcreatecon{,raw}()`` functions. Generally +\*system_r:system_u:svirt_socket_t:s0\* should do the trick, but check the +SELinux rules and settings of your system. + +Supported by QEMU driver + +.. |Migration native path| image:: migration-native.png + :class: diagram +.. |Migration tunnel path| image:: migration-tunnel.png + :class: diagram +.. |Migration direct, managed| image:: migration-managed-direct.png + :class: diagram +.. |Migration peer-to-peer| image:: migration-managed-p2p.png + :class: diagram +.. |Migration direct, unmanaged| image:: migration-unmanaged-direct.png + :class: diagram --=20 2.31.1 From nobody Wed May 1 17:41:19 2024 Delivered-To: importer@patchew.org Received-SPF: pass (zohomail.com: domain of redhat.com designates 170.10.133.124 as permitted sender) client-ip=170.10.133.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.133.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=1638543918; cv=none; d=zohomail.com; s=zohoarc; b=Eq+Y0WN8MUBVjfMvp4StHc5+sLNLsCx0xRy2ysACcaB5Pisb3jkwj8O4+dhxNN2l9v6/ksKdfy1hZh5JDOLevo0himQUyFkT5Gm+/7yBNhktswHWLNQOzBbaGgBJh7XRboO/IpQOCddvKrqABT89oops3G85K7X8R7vEC4zssAk= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1638543918; 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=pgxX9jF4RggdrsV/z00rUcKvprOULNSJvWoVb/iuxdk=; b=Cntk1kFwBjihuhBFeYBT+nHZ1RkQBJaxYBsuP32bE4OOsz0PjYOdrruD5eSQdy8KqzZPK4eIRVSVAvcG9TXAbX3GiR/+s6a+l08lRLGbRLyL/3zVEVbpYN5syBZsFApwbp211Kritnshg/dhLsJeiqBdCoWAOD7k9x3BG9c5xno= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of redhat.com designates 170.10.133.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.133.124]) by mx.zohomail.com with SMTPS id 1638543918112601.0061118425564; Fri, 3 Dec 2021 07:05:18 -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-82-_oiUQZftOhmZxQhu9OGoAw-1; Fri, 03 Dec 2021 10:04:23 -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 358C86409B; Fri, 3 Dec 2021 15:04:09 +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 168C076606; Fri, 3 Dec 2021 15:04:09 +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 DA2274A700; Fri, 3 Dec 2021 15:04:08 +0000 (UTC) Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) by lists01.pubmisc.prod.ext.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id 1B3F488G031249 for ; Fri, 3 Dec 2021 10:04:08 -0500 Received: by smtp.corp.redhat.com (Postfix) id 4706E5DF4C; Fri, 3 Dec 2021 15:04:08 +0000 (UTC) Received: from speedmetal.lan (unknown [10.40.208.10]) by smtp.corp.redhat.com (Postfix) with ESMTP id 8A7605DF21 for ; Fri, 3 Dec 2021 15:04:07 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1638543917; 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=pgxX9jF4RggdrsV/z00rUcKvprOULNSJvWoVb/iuxdk=; b=crJ8Rtmol76G24ePCylFsld6sMCyePAWOnNlTeyswJx6x68d2ShWTaHhMueK8WarzXLBx5 JzP3c0K/Xxn9060ZjeO3AjmasRgydrN1nMoeID1Lt7VaFtwrRB3fTKLHJkV0nx91N1vTdO S1ZQKDewdVHyd2z5sgZ8ptlbQ95uJFU= X-MC-Unique: _oiUQZftOhmZxQhu9OGoAw-1 From: Peter Krempa To: libvir-list@redhat.com Subject: [PATCH 16/17] docs: migration: Add a paragraph about non-shared storage migration Date: Fri, 3 Dec 2021 16:01:55 +0100 Message-Id: <3dd42bcdd54c7de347a09b92976e755393aa8446.1638543496.git.pkrempa@redhat.com> In-Reply-To: References: MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 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: 1638543918759100001 Content-Type: text/plain; charset="utf-8" Outline some of the basics and the caveats of the non-shared migration code. Signed-off-by: Peter Krempa Reviewed-by: J=C3=A1n Tomko --- docs/migration.rst | 32 ++++++++++++++++++++++++++++++++ 1 file changed, 32 insertions(+) diff --git a/docs/migration.rst b/docs/migration.rst index 0a40600462..247f345f8c 100644 --- a/docs/migration.rst +++ b/docs/migration.rst @@ -446,6 +446,38 @@ SELinux rules and settings of your system. Supported by QEMU driver + +Migration of VMs using non-shared images for disks +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Libvirt by default expects that the disk images which are not explicitly n= etwork +accessed are shared between the hosts by means of a network filesystem or = remote +block storage. + +By default it's expected that they are in the same location, but this can = be +modified by providing an updated domain XML with appropriate paths to the = images +using ``--xml`` argument for ``virsh migrate``. + +In case when one or more of the images are residing on local storage libvi= rt +can migrate them as part of the migration flow. This is enabled using +``--copy-storage-all`` flag for ``virsh migrate``. Additionally +``--migrate-disks`` parameter allows control which disks need to actually = be +migrated. Without the flag all read-write disks are migrated. + +On the destination the images must be either pre-created by the user having +correct format and size or alternatively if the target path resides within= a +libvirt storage pool they will be automatically created. + +In case when the user wishes to migrate only the topmost image from a back= ing +chain of images for each disks ``--copy-storage-inc`` can be used instead.= User +must pre-create the images unconditionally. + +In order to ensure that the migration of disks will not be overwhelmed by a +guest doing a lot of I/O to a local fast storage the +``--copy-storage-synchronous-writes`` flag ensures that newly written data= is +synchronously written to the destination. This may harm I/O performance du= ring +the migration. + .. |Migration native path| image:: migration-native.png :class: diagram .. |Migration tunnel path| image:: migration-tunnel.png --=20 2.31.1 From nobody Wed May 1 17:41:19 2024 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=1638543862; cv=none; d=zohomail.com; s=zohoarc; b=fJHnxVqRDuTYlSJi5XW+wDkdj85r6vO59RjsvYfjN4ikAq7S5bJrZ8M/vCQpCm1YMPfhv6t7jwtkJXJLbtxlZ7NvqfZYX3HnbFDaVJEMoBdaTJ+Mvukl5d6AlTbBZ/iS3+++QvYQxZE2gRbadKGWQZZgaN2vVgoDoGWDdhI1Ogk= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1638543862; 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=IwdQqJ1eCFIte4SXVFQUqOXXnb0M62E2a2YvgP37XsY=; b=e745jjw0sxBFkuUrObRWXqW0eFTLwXhiFhXXQEkUjLiLEi5ppNW2v7AuysAHjYJ8/NW5mOhgAcy3wWqksWJP2VUyzY4RWjVZFqfZEUXjsBEFvRQUDxEZIni8zVTzyvypwB91GntWpZz2tNIgetQFN/q+bWMF0kPkA6G5/svNLTM= 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 1638543862593268.09357497043845; Fri, 3 Dec 2021 07:04:22 -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-335-zJtRXaF3MWmJuVmIHlmMew-1; Fri, 03 Dec 2021 10:04:19 -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 2B89910168C8; Fri, 3 Dec 2021 15:04:10 +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 08BFE4EC7F; Fri, 3 Dec 2021 15:04:10 +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 CF9024A706; Fri, 3 Dec 2021 15:04:09 +0000 (UTC) Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) by lists01.pubmisc.prod.ext.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id 1B3F49af031259 for ; Fri, 3 Dec 2021 10:04:09 -0500 Received: by smtp.corp.redhat.com (Postfix) id 568FE5DF2B; Fri, 3 Dec 2021 15:04:09 +0000 (UTC) Received: from speedmetal.lan (unknown [10.40.208.10]) by smtp.corp.redhat.com (Postfix) with ESMTP id A949F5ED42 for ; Fri, 3 Dec 2021 15:04:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1638543861; 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=IwdQqJ1eCFIte4SXVFQUqOXXnb0M62E2a2YvgP37XsY=; b=XyN74X0UJNO/dpt++jFZKCl672jSLr2V7BPvg6+xd52ahOx7I1Yr1iIS5jq9ko86vkhgOG uVWDYII3d9MlCyGeM/lrUQBGNL5umCYyYmw0bJL0ToArwQco/F0rvfBOWMf3dR1Dh+V31D 0PSvN9WjboXbaBIBKpcJBigVWCjnrZk= X-MC-Unique: zJtRXaF3MWmJuVmIHlmMew-1 From: Peter Krempa To: libvir-list@redhat.com Subject: [PATCH 17/17] NEWS: Mention synchronous copy job additions Date: Fri, 3 Dec 2021 16:01:56 +0100 Message-Id: In-Reply-To: References: MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 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.14 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: 1638543863552100005 Content-Type: text/plain; charset="utf-8" Signed-off-by: Peter Krempa Reviewed-by: J=C3=A1n Tomko --- NEWS.rst | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/NEWS.rst b/NEWS.rst index 4d690ff64b..a4252d555d 100644 --- a/NEWS.rst +++ b/NEWS.rst @@ -17,6 +17,18 @@ v8.0.0 (unreleased) * **New features** + * qemu: Synchronous write mode for disk copy operations + + The ``blockdev-mirror`` block job supports a mode where writes from th= e VM + are synchronously propagated to the destination of the copy. This ensu= res + that the job will converge under heavy I/O. + + Implement the mode for the copy blockjob as + ``VIR_DOMAIN_BLOCK_COPY_SYNCHRONOUS_WRITES`` flag exposed via + ``virsh blockcopy --synchronous-writes`` and for non-shared storage mi= gration + as ``VIR_MIGRATE_NON_SHARED_SYNCHRONOUS_WRITES`` exposed via + ``virsh migrate --copy-storage-synchronous-writes``. + * **Improvements** * **Bug fixes** --=20 2.31.1