[PATCH qemu-server] fix #8120: config: allow 'import' lock in the schema

[PATCH qemu-server] fix #8120: config: allow 'import' lock in the schema

[Lucas Barros]

A live import ('import-from' with 'live-restore', for example from the
ESXi import wizard) sets 'lock: import' on the new VM until the import
is done, but 'import' is not part of the enumeration of the 'lock'
property. Reading such a config through the API works, but every
consumer that verifies the result against the schema fails, most
prominently 'qm config', which exits with:

  400 Result verification failed
  lock: value 'import' does not have a value in the enumeration ...

This holds for the whole duration of the import, and also afterwards
if it failed or was aborted, as the lock is only removed on success.

Add 'import' to the allowed values, so that the lock is reported like
any other one.

Signed-off-by: Lucas Barros <lucasbarros.kam@gmail.com>
---
Tested on a PVE 9 node (qemu-server 9.2.15), with a real live import
from a local raw image and with the lock set by hand:

before:
  $ qm create 9904 --name live-test --memory 256 --live-restore 1 \
      --scsi0 local:0,import-from=/root/src.raw &
  $ grep '^lock' /etc/pve/qemu-server/9904.conf
  lock: import
  $ qm config 9904; echo "exit=$?"
  400 Result verification failed
  lock: value 'import' does not have a value in the enumeration 'backup,
  clone, create, migrate, rollback, snapshot, snapshot-delete,
  suspending, suspended'
  qm config <vmid> [OPTIONS]
  exit=255
  ('qm config --current' fails the same way, while
  'pvesh get /nodes/<node>/qemu/<vmid>/config' shows "lock":"import")

after:
  $ qm config 9904; echo "exit=$?"
  boot: order=scsi0
  lock: import
  ...
  exit=0

The live import itself finishes and removes the lock as before.

As mentioned in the report, 'import' can now also be passed to
'qm set --lock', like the other lock values. A VM locked that way
refuses to start ("VM is locked (import)") and 'qm unlock' removes it
again. Apart from the schema checks, I did not find code that depends
on the list of lock values.

The 'destroyed' lock that destroy_vm() writes is missing from the
enumeration as well (pve-container has it), but that config only exists
for a short moment, so I left it out here.

The parse-config tests do not verify the property values, so I did not
add a test case there. 'make test' passes before and after.
proxmox-perltidy reports no changes; the enumeration needed to be split
into two qw() lists to stay within 100 columns.

This patch was prepared with the help of an LLM based coding assistant;
I reviewed the change and ran the tests mentioned above myself.

 src/PVE/QemuServer.pm | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/src/PVE/QemuServer.pm b/src/PVE/QemuServer.pm
index 8045c07e..8eb98fbd 100644
--- a/src/PVE/QemuServer.pm
+++ b/src/PVE/QemuServer.pm
@@ -274,7 +274,9 @@ my $confdesc = {
         type => 'string',
         description => "Lock/unlock the VM.",
         enum => [
-            qw(backup clone create migrate rollback snapshot snapshot-delete suspending suspended)],
+            qw(backup clone create import migrate rollback snapshot snapshot-delete),
+            qw(suspending suspended),
+        ],
     },
     cpulimit => {
         optional => 1,
-- 
2.47.3

applied: [PATCH qemu-server] fix #8120: config: allow 'import' lock in the schema

[Fabian Grünbichler]

On Mon, 09 Nov 2026 11:25:27 -0300, Lucas Barros wrote:
> A live import ('import-from' with 'live-restore', for example from the
> ESXi import wizard) sets 'lock: import' on the new VM until the import
> is done, but 'import' is not part of the enumeration of the 'lock'
> property. Reading such a config through the API works, but every
> consumer that verifies the result against the schema fails, most
> prominently 'qm config', which exits with:
> 
> [...]

Applied with a follow-up converting the qw calls to strings, one per line,
thanks!

[1/1] fix #8120: config: allow 'import' lock in the schema
      commit: 4e5dc1b718e826012c063cb22616f6c2b073df58

Best regards,
-- 
Fabian Grünbichler <f.gruenbichler@proxmox.com>