From nobody Sun Feb 8 18:31:27 2026 Delivered-To: importer@patchew.org Received-SPF: pass (zoho.com: domain of redhat.com designates 209.132.183.28 as permitted sender) client-ip=209.132.183.28; envelope-from=libvir-list-bounces@redhat.com; helo=mx1.redhat.com; Authentication-Results: mx.zohomail.com; spf=pass (zoho.com: domain of redhat.com designates 209.132.183.28 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=1569514978; cv=none; d=zoho.com; s=zohoarc; b=FE30dgbdq5p4JxFy4JxuI/RIVf2tfiS800+vOFYEI+higuq1PK1Z6i71BT2L3d/BSfOgbtwiuAGR08Pxsb2h6fhF58bGJv7Inf9S8nMI9QeZPzvNR38ib4TrNJPDbC4rBiR5gxikTfXkS2uW7oshi8brxjDdLvQgK3U1IfHE1lA= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zoho.com; s=zohoarc; t=1569514978; 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:ARC-Authentication-Results; bh=j/Geh90PZTHgCw+iBegYOh7W4i3KvONoJqKURJCkXeA=; b=QmWv1nO+DQCPPU1PfDs/YcwHu4GtxsoGpOPMXZ8dlZMZs6g3y3ecQqUMnUkGtqKGVGNaM3xoj9h+sLNYsVJEvdh3rxPhXQapn0zTa9dSrNGst7YRnF3NPbOBfvlXTz5wO6JWar0drAyRQQvkiHewskKI1AyKJEhx7VXwUcRbVPU= ARC-Authentication-Results: i=1; mx.zoho.com; spf=pass (zoho.com: domain of redhat.com designates 209.132.183.28 as permitted sender) smtp.mailfrom=libvir-list-bounces@redhat.com; dmarc=pass header.from= (p=none dis=none) header.from= Return-Path: Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by mx.zohomail.com with SMTPS id 1569514978007414.0356137020044; Thu, 26 Sep 2019 09:22:58 -0700 (PDT) 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 mx1.redhat.com (Postfix) with ESMTPS id 5BBBC8980E5; Thu, 26 Sep 2019 16:22: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 37A1C1001DCD; Thu, 26 Sep 2019 16:22: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 EB04A180B76F; Thu, 26 Sep 2019 16:22: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 x8QGEBUY003482 for ; Thu, 26 Sep 2019 12:14:11 -0400 Received: by smtp.corp.redhat.com (Postfix) id 90F375D9C3; Thu, 26 Sep 2019 16:14:11 +0000 (UTC) Received: from moe.brq.redhat.com (unknown [10.43.2.30]) by smtp.corp.redhat.com (Postfix) with ESMTP id 1A5505D9CD for ; Thu, 26 Sep 2019 16:14:09 +0000 (UTC) From: Michal Privoznik To: libvir-list@redhat.com Date: Thu, 26 Sep 2019 18:12:14 +0200 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 Subject: [libvirt] [PATCH v2 18/39] schemas: Introduce disk type NVMe 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: , Content-Transfer-Encoding: quoted-printable Sender: libvir-list-bounces@redhat.com Errors-To: libvir-list-bounces@redhat.com X-Scanned-By: MIMEDefang 2.84 on 10.5.11.22 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.6.2 (mx1.redhat.com [10.5.110.67]); Thu, 26 Sep 2019 16:22:56 +0000 (UTC) Content-Type: text/plain; charset="utf-8" There is this class of PCI devices that act like disks: NVMe. Therefore, they are both PCI devices and disks. While we already have (and can assign a NVMe device to a domain successfully) we don't have disk representation. There are three problems with PCI assignment in case of a NVMe device: 1) domains with can't be migrated 2) NVMe device is assigned whole, there's no way to assign only a namespace 3) Because hypervisors see they don't put block layer on top of it - users don't get all the fancy features like snapshots NVMe namespaces are way of splitting one continuous NVDIMM memory into smaller ones, effectively creating smaller NVMe-s (which can then be partitioned, LVMed, etc.) Because of all of this the following XML was chosen to model a NVMe device:
Signed-off-by: Michal Privoznik --- docs/formatdomain.html.in | 57 +++++++++++++++++++++++-- docs/schemas/domaincommon.rng | 32 ++++++++++++++ tests/qemuxml2argvdata/disk-nvme.xml | 63 ++++++++++++++++++++++++++++ 3 files changed, 149 insertions(+), 3 deletions(-) create mode 100644 tests/qemuxml2argvdata/disk-nvme.xml diff --git a/docs/formatdomain.html.in b/docs/formatdomain.html.in index 93991aa3d1..ad116ff509 100644 --- a/docs/formatdomain.html.in +++ b/docs/formatdomain.html.in @@ -2934,6 +2934,13 @@ </backingStore> <target dev=3D'vdd' bus=3D'virtio'/> </disk> + <disk type=3D'nvme' device=3D'disk'> + <driver name=3D'qemu' type=3D'raw'/> + <source type=3D'pci' managed=3D'yes' namespace=3D'1'> + <address domain=3D'0x0000' bus=3D'0x01' slot=3D'0x00' function=3D= '0x0'/> + </source> + <target dev=3D'vde' bus=3D'virtio'/> + </disk> </devices> ... =20 @@ -2947,7 +2954,8 @@ Valid values are "file", "block", "dir" (since 0.7.5), "network" (since 0.8.7), or - "volume" (since 1.0.5) + "volume" (since 1.0.5), or + "nvme" (since 5.6.0) and refer to the underlying source for the disk. Since 0.0.3 @@ -3130,6 +3138,43 @@ Since 1.0.5

+
nvme
+
+ To specify disk source for NVMe disk the source + element has the following attributes: +
+
type
+
The type of address specified in address + sub-element. Currently, only pci value is + accepted. +
+ +
managed
+
This attribute instructs libvirt to detach NVMe + controller automatically on domain startup (yes) + or expect the controller to be detached by system + administrator (no). +
+ +
namespace
+
The namespace ID which should be assigned to the domai= n. + According to NVMe standard, namespace numbers start from 1, + including. +
+
+ + The difference between <disk type=3D'nvme'> + and <hostdev/> is that the latter is plain + host device assignment with all its limitations (e.g. no live + migration), while the former makes hypervisor to run the NVMe + disk through hypervisor's block layer thus enabling all + features provided by the layer (e.g. snapshots, domain + migration, etc.). Moreover, since the NVMe disk is unbinded + from its PCI driver, the host kernel storage stack is not + involved (compared to passing say /dev/nvme0n1 = via + <disk type=3D'block'> and therefore lower + latencies can be achieved. +
With "file", "block", and "volume", one or more optional sub-elements seclabel, described @@ -3292,11 +3337,17 @@ initiator IQN needed to access the source via mandatory attribute name. +
address
+
For disk of type nvme this element + specifies the PCI address of the host NVMe + controller. + Since 5.6.0 +
=20

- For a "file" or "volume" disk type which represents a cdrom or flo= ppy - (the device attribute), it is possible to define + For a "file" or "volume" disk type which represents a cdrom or + floppy (the device attribute), it is possible to defi= ne policy what to do with the disk if the source file is not accessib= le. (NB, startupPolicy is not valid for "volume" disk unl= ess the specified storage volume is of "file" type). This is done by = the diff --git a/docs/schemas/domaincommon.rng b/docs/schemas/domaincommon.rng index 40eb4a2d75..4871a4c4d4 100644 --- a/docs/schemas/domaincommon.rng +++ b/docs/schemas/domaincommon.rng @@ -1603,6 +1603,7 @@ + =20 @@ -1918,6 +1919,37 @@ =20 + + + nvme + + + + + pci + + + + + + + + + + + + + + + + + + + + + + + (ioemu:)?(fd|hd|sd|vd|xvd|ubd)[a-zA-Z0-9_]+<= /param> diff --git a/tests/qemuxml2argvdata/disk-nvme.xml b/tests/qemuxml2argvdata/= disk-nvme.xml new file mode 100644 index 0000000000..66b2d8450e --- /dev/null +++ b/tests/qemuxml2argvdata/disk-nvme.xml @@ -0,0 +1,63 @@ + + QEMUGuest1 + c7a5fdbd-edaf-9455-926a-d65c16db1809 + 219136 + 219136 + 1 + + hvm + + + + destroy + restart + destroy + + /usr/bin/qemu-system-i686 + + + +

+ + +
+ + + + +
+ + +
+ + + + +
+ + +
+ + + + +
+ + + + + +
+ + +
+ + + +
+ + + + + + --=20 2.21.0 -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list