CA-426556: register VM.set_NVRAM_EFI_variables_v2 on the main XAPI dispatcher

The UEFI certificate-expiry feature added a new RPC,
VM.set_NVRAM_EFI_variables_v2, on the varstored-guard wire interface.
In the original design we only considered the indirect call path
(varstored daemon -> varstored-guard -> XAPI), so we reused the existing
set_NVRAM_EFI_variables declaration in the XAPI datamodel and only
registered V2 on varstored-guard.

What we overlooked: both the varstored daemon and the varstored CLI
tools (varstore-set, varstore-rm, ...) emit set_NVRAM_EFI_variables_v2
via the shared xapidb-lib code. Whether the call goes through guard or
straight to XAPI depends on the socket= argument the binary is started
with -- not on whether it is the daemon or a CLI tool. In typical
deployments the daemon is given a varstored-guard per-VM socket and the
CLI tools are run without that argument, so they land on XAPI directly,
where V2 is not declared and the dispatcher returns "Device Error".

Fix: declare set_NVRAM_EFI_variables_v2 in datamodel_vm.ml so it is
also registered on the main XAPI dispatcher. Semantics are identical
to V1; the only schema difference is that [update] is mandatory in V2.

Signed-off-by: Stephen Cheng <stephen.cheng@citrix.com>

Author: Stephen Cheng

ocaml/idl/datamodel_vm.ml

@@ -2349,6 +2349,27 @@ let set_HVM_boot_policy =
        effect when it is next started"
     ~allowed_roles:_R_VM_ADMIN ()
 
+(* Shared definitions for set_NVRAM_EFI_variables / _v2: the [update]
+   parameter has identical semantics in both, only its presence on the wire
+   differs (optional in V1, required in V2). *)
+let _update_status_enum =
+  Enum
+    ( "update_status"
+    , [
+        ("yes", "Set secureboot_certificates_state to ok")
+      ; ("no", "Leave secureboot_certificates_state unchanged")
+      ; ( "unspecified"
+        , "Check certificates and update secureboot_certificates_state \
+           accordingly"
+        )
+      ]
+    )
+
+let _update_param_doc =
+  "If 'yes', set secureboot_certificates_state to ok. If 'no', keep the \
+   current secureboot_certificates_state unchanged. If 'unspecified', run \
+   certificate check to determine the state."
+
 let set_NVRAM_EFI_variables =
   call ~flags:[`Session] ~name:"set_NVRAM_EFI_variables"
     ~lifecycle:[(Published, rel_naples, "")]
@@ -2369,30 +2390,40 @@ let set_NVRAM_EFI_variables =
         ; param_default= None
         }
       ; {
-          param_type=
-            Enum
-              ( "update_status"
-              , [
-                  ("yes", "Set secureboot_certificates_state to ok")
-                ; ("no", "Leave secureboot_certificates_state unchanged")
-                ; ( "unspecified"
-                  , "Check certificates and update \
-                     secureboot_certificates_state accordingly"
-                  )
-                ]
-              )
+          param_type= _update_status_enum
         ; param_name= "update"
         ; param_doc=
-            "If 'yes', set secureboot_certificates_state to ok. If 'no', keep \
-             the current secureboot_certificates_state unchanged. If omitted \
-             (defaults to 'unspecified'), run certificate check to determine \
-             the state."
-        ; param_release= numbered_release "26.7.0-next"
+            _update_param_doc ^ " If omitted, defaults to 'unspecified'."
+        ; param_release= numbered_release "26.10.0-next"
         ; param_default= Some (VEnum "unspecified")
         }
       ]
     ~hide_from_docs:true ~allowed_roles:_R_LOCAL_ROOT_ONLY ()
 
+(* Both the varstored daemon and the varstored CLI tools (varstore-set,
+   varstore-rm, ...) emit the same [set_NVRAM_EFI_variables_v2] call via
+   the shared xapidb-lib code. Whether that call reaches XAPI directly
+   or goes through varstored-guard depends on the [socket=] argument the
+   binary is started with: if it points at a varstored-guard per-VM
+   socket the call is relayed through guard (where V2 is already
+   registered); if it is absent (or points at XAPI's own socket) the
+   call lands on XAPI's main dispatcher. In typical deployments the
+   daemon takes the guard path and the CLI tools take the direct path,
+   but either binary can take either path. V2 must therefore be
+   registered here so the direct path works. The semantics are
+   identical to V1; the only schema difference is that [update] is a
+   mandatory parameter in V2. *)
+let set_NVRAM_EFI_variables_v2 =
+  call ~flags:[`Session] ~name:"set_NVRAM_EFI_variables_v2"
+    ~lifecycle:[(Published, "26.10.0-next", "")]
+    ~params:
+      [
+        (Ref _vm, "self", "The VM")
+      ; (String, "value", "The EFI-variables value")
+      ; (_update_status_enum, "update", _update_param_doc)
+      ]
+    ~hide_from_docs:true ~allowed_roles:_R_LOCAL_ROOT_ONLY ()
+
 let restart_device_models =
   call ~name:"restart_device_models" ~lifecycle:[]
     ~params:[(Ref _vm, "self", "The VM")]
@@ -2651,6 +2682,7 @@ let t =
       ; set_domain_type
       ; set_HVM_boot_policy
       ; set_NVRAM_EFI_variables
+      ; set_NVRAM_EFI_variables_v2
       ; restart_device_models
       ; set_uefi_mode
       ; get_secureboot_readiness

ocaml/xapi-guard/lib/server_interface.ml

@@ -198,7 +198,8 @@ let make_server_varstored _persist ~cache path vm_uuid =
      let update =
        match update with "yes" -> `yes | "no" -> `no | _ -> `unspecified
      in
-     with_xapi ~cache @@ VM.set_NVRAM_EFI_variables ~self ~value:nvram ~update
+     with_xapi ~cache
+     @@ VM.set_NVRAM_EFI_variables_v2 ~self ~value:nvram ~update
     )
     |> ret
   in

ocaml/xapi/message_forwarding.ml

@@ -3135,6 +3135,13 @@ functor
         info "VM.set_NVRAM_EFI_variables: self = '%s'" (vm_uuid ~__context self) ;
         Local.VM.set_NVRAM_EFI_variables ~__context ~self ~value ~update
 
+      let set_NVRAM_EFI_variables_v2 ~__context ~self ~value ~update =
+        (* called by varstored CLI tools (which connect to XAPI directly,
+           bypassing varstored-guard); same semantics as V1 *)
+        info "VM.set_NVRAM_EFI_variables_v2: self = '%s'"
+          (vm_uuid ~__context self) ;
+        Local.VM.set_NVRAM_EFI_variables_v2 ~__context ~self ~value ~update
+
       let restart_device_models ~__context ~self =
         info "VM.restart_device_models: self = '%s'" (vm_uuid ~__context self) ;
         Local.VM.restart_device_models ~__context ~self

ocaml/xapi/xapi_vm.ml

@@ -1674,6 +1674,11 @@ let set_NVRAM_EFI_variables ~__context ~self ~value ~update =
       in
       Db.VM.set_secureboot_certificates_state ~__context ~self ~value:new_state
 
+(* V2 has the same semantics as V1; it exists only to provide an RPC method
+   whose [update] parameter is mandatory on the wire (V1's [update] is
+   optional with default [`unspecified]). See datamodel_vm.ml. *)
+let set_NVRAM_EFI_variables_v2 = set_NVRAM_EFI_variables
+
 let restart_device_models ~__context ~self =
   let power_state = Db.VM.get_power_state ~__context ~self in
   if power_state <> `Running then

ocaml/xapi/xapi_vm.mli

@@ -431,6 +431,13 @@ val set_NVRAM_EFI_variables :
   -> update:[`yes | `no | `unspecified]
   -> unit
 
+val set_NVRAM_EFI_variables_v2 :
+     __context:Context.t
+  -> self:API.ref_VM
+  -> value:string
+  -> update:[`yes | `no | `unspecified]
+  -> unit
+
 val restart_device_models : __context:Context.t -> self:API.ref_VM -> unit
 
 val set_uefi_mode :