From nobody Mon Feb 9 04:31:18 2026 Delivered-To: importer@patchew.org Received-SPF: pass (zohomail.com: domain of redhat.com designates 205.139.110.61 as permitted sender) client-ip=205.139.110.61; envelope-from=libvir-list-bounces@redhat.com; helo=us-smtp-delivery-1.mimecast.com; Authentication-Results: mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of redhat.com designates 205.139.110.61 as permitted sender) smtp.mailfrom=libvir-list-bounces@redhat.com; dmarc=pass(p=none dis=none) header.from=redhat.com Return-Path: Received: from us-smtp-delivery-1.mimecast.com (us-smtp-2.mimecast.com [205.139.110.61]) by mx.zohomail.com with SMTPS id 1580284488474157.3205147811991; Tue, 28 Jan 2020 23:54:48 -0800 (PST) Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-296-sao0vHL1OWGcpQ1IDbISuA-1; Wed, 29 Jan 2020 02:54:44 -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 61FFC801E6D; Wed, 29 Jan 2020 07:54:39 +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 379F48E5E9; Wed, 29 Jan 2020 07:54:39 +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 AE0E618089CD; Wed, 29 Jan 2020 07:54:37 +0000 (UTC) Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by lists01.pubmisc.prod.ext.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id 00T7sY7j024219 for ; Wed, 29 Jan 2020 02:54:34 -0500 Received: by smtp.corp.redhat.com (Postfix) id E24C788820; Wed, 29 Jan 2020 07:54:34 +0000 (UTC) Received: from moe.redhat.com (unknown [10.43.2.30]) by smtp.corp.redhat.com (Postfix) with ESMTP id 438D984BB8; Wed, 29 Jan 2020 07:54:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1580284487; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:list-id:list-help: list-unsubscribe:list-subscribe:list-post; bh=t73M3mu/Zk2CvTPrJK2SEyQTDTPgS4w9MopOG7ORQdI=; b=ZkRXmpL9bxqZA++9o6hdaPjjVODVMmH7DlP3WN7cg8OseG3rd8ThC2nW/a36js9jushhZh XTUdPhferS4QPP3x3fDsC5WfR77vlVjp50GpDumP/u24haC77SHP8KrjAhHyarQVj/lFEZ Kn/I58nPtisxSwji03FjL3l9X92ZPzM= From: Michal Privoznik To: libvir-list@redhat.com Subject: [PATCH v2 2/7] conf: expand iotune params if only group name is given Date: Wed, 29 Jan 2020 08:54:13 +0100 Message-Id: <1263a82983572632af847c7c5baa2e94a0f8cc8e.1580284312.git.mprivozn@redhat.com> In-Reply-To: References: MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11 X-loop: libvir-list@redhat.com Cc: nshirokovskiy@virtuozzo.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 X-MC-Unique: sao0vHL1OWGcpQ1IDbISuA-1 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Transfer-Encoding: quoted-printable X-ZohoMail-DKIM: pass (identity @redhat.com) Content-Type: text/plain; charset="utf-8" From: Nikolay Shirokovskiy Currently, if only iotune group name is given for some disk and no any params then later start of domain will fail. I guess it will be convenient to allow such configuration if there is another disk in the same iotune group with iotune params set. The meaning is that the first disk have same iotunes and the latter. Thus one can easily add a disk to iotune group - just add group name parameter and no need to copy all the params. Also let's expand iotunes params in the described case so we don't need to refer to another disk to know iotunes and this will make logic in many places simple. Signed-off-by: Nikolay Shirokovskiy Signed-off-by: Michal Privoznik --- src/conf/domain_conf.c | 27 +++++++++++++++++++++++++++ 1 file changed, 27 insertions(+) diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c index c77901dfa0..0eeffb6ed0 100644 --- a/src/conf/domain_conf.c +++ b/src/conf/domain_conf.c @@ -5110,6 +5110,31 @@ virDomainRNGDefPostParse(virDomainRNGDefPtr rng) } =20 =20 +static void +virDomainDiskExpandGroupIoTune(virDomainDiskDefPtr disk, + const virDomainDef *def) +{ + size_t i; + + if (!disk->blkdeviotune.group_name || + virDomainBlockIoTuneInfoHasAny(&disk->blkdeviotune)) + return; + + for (i =3D 0; i < def->ndisks; i++) { + virDomainDiskDefPtr d =3D def->disks[i]; + char *tmp =3D disk->blkdeviotune.group_name; + + if (STRNEQ_NULLABLE(disk->blkdeviotune.group_name, d->blkdeviotune= .group_name) || + !virDomainBlockIoTuneInfoHasAny(&d->blkdeviotune)) + continue; + + disk->blkdeviotune =3D d->blkdeviotune; + disk->blkdeviotune.group_name =3D tmp; + return; + } +} + + static int virDomainDiskDefPostParse(virDomainDiskDefPtr disk, const virDomainDef *def, @@ -5155,6 +5180,8 @@ virDomainDiskDefPostParse(virDomainDiskDefPtr disk, return -1; } =20 + virDomainDiskExpandGroupIoTune(disk, def); + return 0; } =20 --=20 2.24.1