[PATCH v3 3/5] Update schema, docs, and validation logic to support network backed NVRAM

Rohit Kumar rohit.kumar3 at nutanix.com
Wed May 4 16:51:13 UTC 2022


Update NVRAM element schema, docs and validation logic
for supporting network backed NVRAM. NVRAM backed over network
would give the flexibility to start the VM on any host without
having to worry about where to get the latest nvram image.

Signed-off-by: Prerna Saxena <prerna.saxena at nutanix.com>
Signed-off-by: Florian Schmidt <flosch at nutanix.com>
Signed-off-by: Rohit Kumar <rohit.kumar3 at nutanix.com>
---
 NEWS.rst                          |  5 +++++
 docs/formatdomain.rst             | 34 ++++++++++++++++++++++++++++++-
 src/conf/schemas/domaincommon.rng | 21 ++++++++++++++++++-
 src/qemu/qemu_validate.c          | 14 +++++++++++--
 4 files changed, 70 insertions(+), 4 deletions(-)

diff --git a/NEWS.rst b/NEWS.rst
index 4a213682a4..592bedfec0 100644
--- a/NEWS.rst
+++ b/NEWS.rst
@@ -34,6 +34,11 @@ v8.3.0 (2022-05-02)
 
 * **New features**
 
+  * qemu: Introduce support for network backed NVRAM
+
+    Users can now use remote store NVRAM image by specifying attribute
+    `type='network'` with `<nvram>` element.
+
   * qemu: Introduce support for virtio-iommu
 
     This IOMMU device can be used with both Q35 and ARM virt guests.
diff --git a/docs/formatdomain.rst b/docs/formatdomain.rst
index 9be305f3e6..a27346f6fa 100644
--- a/docs/formatdomain.rst
+++ b/docs/formatdomain.rst
@@ -141,6 +141,34 @@ harddisk, cdrom, network) determining where to obtain/find the boot image.
    </os>
    ...
 
+   <!-- QEMU with UEFI manual firmware, secure boot and with NVRAM type 'file'-->
+   ...
+   <os>
+     <type>hvm</type>
+     <loader readonly='yes' secure='yes' type='pflash'>/usr/share/OVMF/OVMF_CODE.fd</loader>
+     <nvram type='file' template='/usr/share/OVMF/OVMF_VARS.fd'>
+       <source file='/var/lib/libvirt/nvram/guest_VARS.fd'/>
+     <boot dev='hd'/>
+   </os>
+   ...
+
+   <!-- QEMU with UEFI manual firmware, secure boot and with network backed NVRAM'-->
+   ...
+   <os>
+     <type>hvm</type>
+     <loader readonly='yes' secure='yes' type='pflash'>/usr/share/OVMF/OVMF_CODE.fd</loader>
+     <nvram type='network'>
+       <source protocol='iscsi' name='iqn.2013-07.com.example:iscsi-nopool/0'>
+         <host name='example.com' port='6000'/>
+         <auth username='myname'>
+           <secret type='iscsi' usage='mycluster_myname'/>
+         </auth>
+       </source>
+     </nvram>
+     <boot dev='hd'/>
+   </os>
+   ...
+
    <!-- QEMU with automatic UEFI firmware and secure boot -->
    ...
    <os firmware='efi'>
@@ -222,7 +250,11 @@ harddisk, cdrom, network) determining where to obtain/find the boot image.
    :since:`Since 2.1.0`
 ``nvram``
    Some UEFI firmwares may want to use a non-volatile memory to store some
-   variables. In the host, this is represented as a file and the absolute path
+   variables. They can be present on host or on some network storage.
+   :since:`Since 8.3.0`,  it's possible for the element to have ``type`` attribute
+   (accepts values ``file`` and ``network``). For remote store NVRAM, please refer
+   back to ``<source>`` element definition at `Disk configuration <#hard-drives-floppy-disks-cdroms>`__
+   section. In the host, this is represented as a file and the absolute path
    to the file is stored in this element. Moreover, when the domain is started
    up libvirt copies so called master NVRAM store file defined in ``qemu.conf``.
    If needed, the ``template`` attribute can be used to per domain override map
diff --git a/src/conf/schemas/domaincommon.rng b/src/conf/schemas/domaincommon.rng
index 8afb0dadd4..acebaa8295 100644
--- a/src/conf/schemas/domaincommon.rng
+++ b/src/conf/schemas/domaincommon.rng
@@ -333,7 +333,26 @@
               </attribute>
             </optional>
             <optional>
-              <ref name="absFilePath"/>
+              <choice>
+                <group>
+                  <ref name="absFilePath"/>
+                </group>
+                <group>
+                  <attribute name="type">
+                    <value>file</value>
+                  </attribute>
+                  <element name="source">
+                    <attribute name="file">
+                      <choice>
+                        <ref name="absFilePath"/>
+                      </choice>
+                    </attribute>
+                  </element>
+                </group>
+                <group>
+                  <ref name="diskSourceNetwork"/>
+                </group>
+              </choice>
             </optional>
           </element>
         </optional>
diff --git a/src/qemu/qemu_validate.c b/src/qemu/qemu_validate.c
index 28597ac702..e7fc2b9772 100644
--- a/src/qemu/qemu_validate.c
+++ b/src/qemu/qemu_validate.c
@@ -621,6 +621,13 @@ qemuValidateDomainDefNvram(const virDomainDef *def,
         break;
 
     case VIR_STORAGE_TYPE_NETWORK:
+        if (!virQEMUCapsGet(qemuCaps, QEMU_CAPS_BLOCKDEV)) {
+            virReportError(VIR_ERR_CONFIG_UNSUPPORTED, "%s",
+                           _("remote NVRAM is not supported by this QEMU"));
+            return -1;
+        }
+        break;
+
     case VIR_STORAGE_TYPE_BLOCK:
     case VIR_STORAGE_TYPE_DIR:
     case VIR_STORAGE_TYPE_VOLUME:
@@ -651,9 +658,12 @@ qemuValidateDomainDefNvram(const virDomainDef *def,
         return -1;
     }
 
-    if (def->os.loader->nvram->auth) {
+    if (def->os.loader->nvram->auth &&
+        !(actualType == VIR_STORAGE_TYPE_NETWORK &&
+        (def->os.loader->nvram->protocol == VIR_STORAGE_NET_PROTOCOL_ISCSI ||
+         def->os.loader->nvram->protocol == VIR_STORAGE_NET_PROTOCOL_RBD))) {
         virReportError(VIR_ERR_INTERNAL_ERROR, "%s",
-                        _("Auth is not supported with NVRAM"));
+                        _("Auth is only supported with 'iSCSI' and 'nbd' protocols"));
         return -1;
     }
 
-- 
2.25.1



More information about the libvir-list mailing list