Inconsistent id and internal name in DB after failed import VM attempts

[rajujith]

problem

Usually, the vm_instance table records will have the internal name (instance_name)of the instance matching the ID in the table. This changes when there is a failed attempt to import a VM using the importVm API. One scenario is passing an incorrect zone ID, there can be more.

mysql> select id,instance_name,created from vm_instance;
+----+---------------+---------------------+
| id | instance_name | created             |
+----+---------------+---------------------+
|  1 | s-1-VM        | 2025-08-26 08:25:12 |
|  2 | v-2-VM        | 2025-08-26 08:25:07 |
|  3 | i-2-3-VM      | 2025-08-26 13:00:47 |
|  4 | r-4-VM        | 2025-08-26 13:00:49 |
|  6 | i-2-5-VM      | 2025-08-26 13:24:30 |
|  8 | i-2-7-VM      | 2025-08-26 13:25:03 |
| 10 | i-2-9-VM      | 2025-08-26 13:27:51 |
| 12 | i-2-11-VM     | 2025-08-26 13:35:13 |
| 14 | i-2-13-VM     | 2025-08-26 16:47:20 |
| 15 | i-2-15-VM     | 2025-09-08 06:21:18 |
| 17 | i-2-16-VM     | 2025-09-08 06:23:12 |
| 19 | i-2-18-VM     | 2025-09-08 06:27:06 |
| 20 | i-2-20-VM     | 2025-09-08 06:30:14 |
| 22 | i-2-21-VM     | 2025-09-08 06:31:00 |
| 24 | i-2-23-VM     | 2025-09-08 06:36:37 |
| 26 | i-2-25-VM     | 2025-09-08 06:54:35 |
| 28 | i-2-27-VM     | 2025-09-08 07:04:44 |
| 30 | i-2-29-VM     | 2025-09-08 11:13:39 |
| 34 | i-2-33-VM     | 2025-09-12 09:47:25 |
| 36 | i-2-35-VM     | 2025-09-12 13:34:34 |
| 38 | i-2-37-VM     | 2025-09-12 14:09:33 |
| 39 | i-2-39-VM     | 2025-09-17 10:35:43 |
| 40 | i-2-40-VM     | 2025-09-17 10:37:01 |
| 42 | i-2-41-VM     | 2025-09-17 12:05:28 |
+----+---------------+---------------------+

API/CMK example:
cmk import vm name=Sept17-1 displayname=Sept17-1 importsource=shared hypervisor=kvm storageid=d1289b49-db52-33f7-bd0e-3f7feeb3527b diskpath=Sept17-1.qcow2 networkid=a03547c4-4fed-42e8-aa1c-43fed36b6fc9 serviceofferingid=e96cd0d6-2f4c-4bd2-a5b1-be311cb8e911 migrateallowed=true zoneid=664da58b-ab80-409a-a320-b0d6afad1b82 clusterid=0d7ec7cf-d63a-48ab-9391-8c4b5c794a1c details[1].UEFI="LEGACY" details[0].cpuNumber="1" details[0].cpuSpeed="1000" details[0].memory="1024"

versions

4.20.1, KVM

The steps to reproduce the bug

1. Attempt the importVm API with an incorrect zoneid
   2.Try again with correct zoneid
   3.Check the id and intance_name in table vm_instance

What to do about it?

Fix it so that it remains consistent.

[weizhouapache]

fixed by #11659

thanks @nvazquez @rajujith