Open
Conversation
Add virtiofs-based model mounting capability for user VMs: - Add VmModelMountVO database table and schema with hostUuid tracking - Add AttachVirtiofsCmd/DetachVirtiofsCmd for KVM agent - Add MountModelCenterCmd with storageUrl field - Add SDK actions for mount/unmount/query operations - Add error codes 10138-10149 Resolves: ZSTAC-83157 Change-Id: I746679736f7a7176646e646d797969766f697a76
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: http://open.zstack.ai:20001/code-reviews/zstack-cloud.yaml (via .coderabbit.yaml) Review profile: CHILL Plan: Pro Run ID: ⛔ Files ignored due to path filters (11)
📒 Files selected for processing (1)
🚧 Files skipped from review as they are similar to previous changes (1)
Walkthrough新增虚拟机模型挂载相关数据库表与列（含回填与索引）、dGPU/ tensor fusion 表、KVM virtiofs 与模型挂载路径常量、测试库中三个 API 帮助方法，以及若干云操作错误码常量。所有更改均为新增或扩展，无删除现有接口。 Changes
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes Poem
🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Warning There were issues while running some tools. Please review the errors and either fix the tool's configuration or disable the tool if it's a critical failure. 🔧 ast-grep (0.42.1)utils/src/main/java/org/zstack/utils/clouderrorcode/CloudOperationsErrorCode.javaComment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@conf/db/upgrade/V5.5.16__schema.sql`:
- Around line 347-366: The VmModelMountVO table is missing the historical UNIQUE
constraint uk_vm_model (vmInstanceUuid, modelUuid) and its createDate TIMESTAMP
uses DEFAULT '0000-00-00 00:00:00'; restore the uk_vm_model unique key and
change createDate to DEFAULT CURRENT_TIMESTAMP to ensure consistent schema
across installs/upgrades: update the CREATE TABLE for VmModelMountVO to include
UNIQUE KEY `uk_vm_model` (`vmInstanceUuid`, `modelUuid`) and replace `createDate
TIMESTAMP NOT NULL DEFAULT '0000-00-00 00:00:00'` with `createDate TIMESTAMP NOT
NULL DEFAULT CURRENT_TIMESTAMP`; if the removal was intentional instead, add
explicit ALTER TABLE ... DROP KEY `uk_vm_model` in the intermediate upgrade
scripts rather than leaving behavior divergent.
In
`@utils/src/main/java/org/zstack/utils/clouderrorcode/CloudOperationsErrorCode.java`:
- Line 14910: The constant ORG_ZSTACK_AI_10157 is defined in
CloudOperationsErrorCode but has no corresponding entries in the global-error
JSON i18n files; add a localized error message mapping for "ORG_ZSTACK_AI_10157"
to every global-error-*.json (e.g., global-error-zh_CN.json,
global-error-en_US.json) following the same key/value pattern used by
ORG_ZSTACK_AI_10150 (use equivalent localized text for each language), and while
editing confirm and document why codes 10151–10156 are absent (either add
mappings if they should exist or leave a comment/placeholder noting intentional
gap). Ensure the key string exactly matches ORG_ZSTACK_AI_10157 and the message
formats are consistent with other ORG_ZSTACK_AI_* entries so lookups succeed at
runtime.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: http://open.zstack.ai:20001/code-reviews/zstack-cloud.yaml (via .coderabbit.yaml)
Review profile: CHILL
Plan: Pro
Run ID: 8c3de1ae-585f-4e6a-ac50-ac17c9cc7d74
⛔ Files ignored due to path filters (10)
conf/i18n/globalErrorCodeMapping/global-error-zh_CN.jsonis excluded by!**/*.jsonsdk/src/main/java/SourceClassMap.javais excluded by!sdk/**sdk/src/main/java/org/zstack/sdk/MountModelToVmInstanceAction.javais excluded by!sdk/**sdk/src/main/java/org/zstack/sdk/MountModelToVmInstanceResult.javais excluded by!sdk/**sdk/src/main/java/org/zstack/sdk/QueryVmModelMountAction.javais excluded by!sdk/**sdk/src/main/java/org/zstack/sdk/QueryVmModelMountResult.javais excluded by!sdk/**sdk/src/main/java/org/zstack/sdk/UnmountModelFromVmInstanceAction.javais excluded by!sdk/**sdk/src/main/java/org/zstack/sdk/UnmountModelFromVmInstanceResult.javais excluded by!sdk/**sdk/src/main/java/org/zstack/sdk/VmModelMountInventory.javais excluded by!sdk/**sdk/src/main/java/org/zstack/sdk/VmModelMountStatus.javais excluded by!sdk/**
📒 Files selected for processing (5)
conf/db/upgrade/V5.5.12__schema.sqlconf/db/upgrade/V5.5.16__schema.sqlplugin/kvm/src/main/java/org/zstack/kvm/KVMConstant.javatestlib/src/main/java/org/zstack/testlib/ApiHelper.groovyutils/src/main/java/org/zstack/utils/clouderrorcode/CloudOperationsErrorCode.java
Comment on lines
+347
to
+366
| -- ZSTAC-83157: VM model mount feature | ||
| CREATE TABLE IF NOT EXISTS `zstack`.`VmModelMountVO` ( | ||
| `uuid` VARCHAR(32) NOT NULL, | ||
| `vmInstanceUuid` VARCHAR(32) NOT NULL, | ||
| `modelUuid` VARCHAR(32) NOT NULL, | ||
| `modelName` VARCHAR(256) DEFAULT NULL, | ||
| `mountPath` VARCHAR(512) NOT NULL, | ||
| `sourcePath` VARCHAR(1024) NOT NULL, | ||
| `status` VARCHAR(32) NOT NULL, | ||
| `hostUuid` VARCHAR(32) DEFAULT NULL, | ||
| `accountUuid` VARCHAR(32) DEFAULT NULL, | ||
| `createDate` TIMESTAMP NOT NULL DEFAULT '0000-00-00 00:00:00', | ||
| `lastOpDate` TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, | ||
| PRIMARY KEY (`uuid`), | ||
| UNIQUE KEY `uk_vm_mountpath` (`vmInstanceUuid`, `mountPath`(255)), | ||
| CONSTRAINT `fk_vm_model_mount_vm` | ||
| FOREIGN KEY (`vmInstanceUuid`) REFERENCES `zstack`.`VmInstanceEO`(`uuid`) ON DELETE CASCADE, | ||
| CONSTRAINT `fk_vm_model_mount_model` | ||
| FOREIGN KEY (`modelUuid`) REFERENCES `zstack`.`ModelVO`(`uuid`) ON DELETE CASCADE | ||
| ) ENGINE=InnoDB DEFAULT CHARSET=utf8; |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# 只读核验：检查两个升级脚本里 VmModelMountVO 的约束是否一致
rg -n "VmModelMountVO|uk_vm_mountpath|uk_vm_model" conf/db/upgrade/V5.5.12__schema.sql conf/db/upgrade/V5.5.16__schema.sqlRepository: MatheMatrix/zstack
Length of output: 575
🏁 Script executed:
#!/bin/bash
# 查看 V5.5.12 到 V5.5.16 之间的所有升级脚本，检查是否有 DROP/ALTER 语句处理 uk_vm_model
fd -e sql "V5\.5\.(1[2-5]|16)__schema\.sql" conf/db/upgrade/ | sort
echo "---"
# 搜索所有涉及 uk_vm_model 的操作
rg -n "uk_vm_model|DROP.*CONSTRAINT|ALTER TABLE.*VmModelMountVO" conf/db/upgrade/ | grep -E "V5\.5\.(1[2-6])"Repository: MatheMatrix/zstack
Length of output: 239
🏁 Script executed:
#!/bin/bash
# 查看 V5.5.12 中 VmModelMountVO 的完整定义
echo "=== V5.5.12__schema.sql (lines 104-120) ==="
sed -n '104,120p' conf/db/upgrade/V5.5.12__schema.sql
echo ""
echo "=== V5.5.16__schema.sql (lines 348-366) ==="
sed -n '348,366p' conf/db/upgrade/V5.5.16__schema.sqlRepository: MatheMatrix/zstack
Length of output: 2167
统一 VmModelMountVO 的唯一约束，避免升级路径行为漂移。
V5.5.12 中该表定义包含 uk_vm_model (vmInstanceUuid, modelUuid)（第 118 行），但在 V5.5.16 中缺失。由于中间没有迁移脚本处理此变化，这会导致不同安装/升级路径产生不同的约束：
- 从 V5.5.12 升级的系统保留
uk_vm_model - 新安装 V5.5.16 的系统缺少
uk_vm_model
若无意移除，请在此处补回 uk_vm_model；若有意移除，需要在 V5.5.13～V5.5.15 中补充显式 DROP 语句处理既有环境。
同时，createDate 字段的时间戳默认值应从 DEFAULT '0000-00-00 00:00:00' 改为 DEFAULT CURRENT_TIMESTAMP，以符合项目编码规范。
建议修复（若保留唯一性）
PRIMARY KEY (`uuid`),
UNIQUE KEY `uk_vm_mountpath` (`vmInstanceUuid`, `mountPath`(255)),
+ UNIQUE KEY `uk_vm_model` (`vmInstanceUuid`, `modelUuid`),
CONSTRAINT `fk_vm_model_mount_vm`- `createDate` TIMESTAMP NOT NULL DEFAULT '0000-00-00 00:00:00',
+ `createDate` TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP,🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@conf/db/upgrade/V5.5.16__schema.sql` around lines 347 - 366, The
VmModelMountVO table is missing the historical UNIQUE constraint uk_vm_model
(vmInstanceUuid, modelUuid) and its createDate TIMESTAMP uses DEFAULT
'0000-00-00 00:00:00'; restore the uk_vm_model unique key and change createDate
to DEFAULT CURRENT_TIMESTAMP to ensure consistent schema across
installs/upgrades: update the CREATE TABLE for VmModelMountVO to include UNIQUE
KEY `uk_vm_model` (`vmInstanceUuid`, `modelUuid`) and replace `createDate
TIMESTAMP NOT NULL DEFAULT '0000-00-00 00:00:00'` with `createDate TIMESTAMP NOT
NULL DEFAULT CURRENT_TIMESTAMP`; if the removal was intentional instead, add
explicit ALTER TABLE ... DROP KEY `uk_vm_model` in the intermediate upgrade
scripts rather than leaving behavior divergent.
Collaborator
There was a problem hiding this comment.
Comment from zhong.xian:
已经没有5.5.12版本，所以不存在这个问题
There was a problem hiding this comment.
@zstack-robot-2，感谢 zhong.xian 的说明，了解到 V5.5.12 已不存在，因此 uk_vm_model 约束漂移的问题不适用，我收回该部分建议。
不过，createDate 字段使用 DEFAULT '0000-00-00 00:00:00' 的问题仍然独立存在，违反了项目 SQL 编码规范（Do not use DEFAULT 0000-00-00 00:00:00, use DEFAULT CURRENT_TIMESTAMP instead），请修正：
- `createDate` TIMESTAMP NOT NULL DEFAULT '0000-00-00 00:00:00',
+ `createDate` TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP,✏️ Learnings added
Learnt from: zstack-robot-2
Repo: MatheMatrix/zstack PR: 3758
File: conf/db/upgrade/V5.5.16__schema.sql:347-366
Timestamp: 2026-04-15T05:55:58.590Z
Learning: In the ZStack project, the upgrade script V5.5.12__schema.sql has been removed and is no longer a valid upgrade path. Schema divergence concerns between V5.5.12 and later versions (e.g., V5.5.16) do not apply.
Note: Learnings are effective only in the context of similar code segments. To apply general coding guidelines, please configure review instructions. You can manage existing learnings in the app.
🧠 Learnings used
Learnt from: zstack-robot-1
Repo: MatheMatrix/zstack PR: 0
File: :0-0
Timestamp: 2025-08-03T04:10:21.683Z
Learning: ZStack 数据库升级脚本 V4.10.16__schema.sql 中的 UPGRADE_VM_METADATA_TABLES_DIRECT 存储过程使用直接 RENAME TABLE 操作，不具备幂等性。需要通过 information_schema 检查表和约束的存在性来确保脚本可以安全重复执行。
Learnt from: zstack-robot-1
Repo: MatheMatrix/zstack PR: 3307
File: conf/db/zsv/V5.0.0__schema.sql:38-76
Timestamp: 2026-02-10T08:53:52.891Z
Learning: 在 ZStack 项目中,对于 joined-table inheritance 模式(如 KVMHostVO→HostEO, ApplianceVmVO→VmInstanceEO),子表的 uuid 字段不添加到父表的外键约束。ZStack 依赖 Hibernate/JPA 在应用层管理继承关系和级联操作,外键约束仅在数据库层直接删除时才有效,因此不使用。
Learnt from: zstack-robot-2
Repo: MatheMatrix/zstack PR: 3416
File: conf/db/upgrade/V5.5.12__schema.sql:24-35
Timestamp: 2026-03-05T02:13:23.339Z
Learning: In ZStack, the database schema name is fixed as 'zstack'. For SQL upgrade scripts under conf/db/upgrade, continue using TABLE_SCHEMA = 'zstack' and reference tables as zstack.`UsedIpVO` (i.e., qualify with the schema). Do not replace with DATABASE() or remove the schema qualifier for portability. This pattern can be assumed across upgrade scripts in this directory.
Learnt from: ZStack-Robot
Repo: MatheMatrix/zstack PR: 3737
File: compute/src/main/java/org/zstack/compute/vm/devices/VmHostFileCascadeExtension.java:77-113
Timestamp: 2026-04-14T05:45:06.368Z
Learning: In ZStack's VmHostFileCascadeExtension (compute/src/main/java/org/zstack/compute/vm/devices/VmHostFileCascadeExtension.java), deleting ALL VmHostFileVO records for a VM during cascade deletion is correct behavior. VmHostFileVO.vmInstanceUuid has an ON DELETE CASCADE foreign key to VmInstanceEO, so VmHostFileVO records cannot exist independently of the VM's EO record. The 90-day "latest file" retention policy in VmHostFileTracker applies only while VmInstanceEO is in the soft-deleted state — there is no way to preserve a VmHostFileVO record beyond the VM's EO lifecycle. Suggesting to skip the latest record in the cascade extension is incorrect.
Learnt from: ZStack-Robot
Repo: MatheMatrix/zstack PR: 2293
File: conf/db/upgrade/V4.10.16__schema.sql:69-82
Timestamp: 2025-08-03T03:42:34.349Z
Learning: 在 ZStack 项目中进行数据库 DDL 升级时，由于 MySQL/MariaDB 中的 RENAME TABLE、ALTER TABLE 等 DDL 语句会隐式 COMMIT，因此应使用临时表 + 数据复制的方式来确保升级可逆，而不是依赖事务的 ROLLBACK 机制。
Learnt from: MatheMatrix
Repo: MatheMatrix/zstack PR: 2311
File: plugin/sdnController/src/main/java/org/zstack/sdnController/hardwareVxlan/KVMRealizeHardwareVxlanNetworkBackend.java:52-53
Timestamp: 2025-07-22T02:30:46.123Z
Learning: In ZStack, backend realization code (such as KVMRealizeHardwareVxlanNetworkBackend) can safely assume the existence of the VO for the resource being operated on (e.g., HardwareL2VxlanNetworkVO for a given L2NetworkInventory), due to system lifecycle management and strong foreign key constraints in the database schema. Explicit null checks after findByUuid are not required in these contexts.
Learnt from: zstack-robot-1
Repo: MatheMatrix/zstack PR: 0
File: :0-0
Timestamp: 2025-08-03T04:10:21.683Z
Learning: 在 ZStack 数据库升级脚本中，直接使用 RENAME TABLE 不能保证幂等性。应该通过 information_schema.tables 检查表的存在性，只在源表存在且目标表不存在时才执行重命名操作，以确保升级脚本可以安全地重复执行。
Learnt from: MatheMatrix
Repo: MatheMatrix/zstack PR: 3443
File: header/src/main/java/org/zstack/header/core/external/service/ExternalServiceConfigurationVO.java:21-24
Timestamp: 2026-03-10T04:26:24.367Z
Learning: In the ZStack project, JPA entity fields (e.g., `configuration` and `description` in `ExternalServiceConfigurationVO`) do not need explicit `Column(columnDefinition = ...)` or `Column(length = ...)` annotations to match the SQL migration scripts. The project relies on SQL migration scripts as the authoritative schema source rather than Hibernate DDL generation, so schema alignment via annotation attributes is unnecessary.
Learnt from: ZStack-Robot
Repo: MatheMatrix/zstack PR: 3716
File: header/src/main/java/org/zstack/header/keyprovider/EncryptedResourceKeyManager.java:32-35
Timestamp: 2026-04-12T05:42:20.685Z
Learning: In ZStack's KvmTpmExtensions.preReleaseVmResource (plugin/kvm/src/main/java/org/zstack/kvm/tpm/KvmTpmExtensions.java), as of PR `#3716`, the `ResourceKeyResult.refExistedBeforeCreate` field has been removed from `EncryptedResourceKeyManager.ResourceKeyResult`. Rollback behavior is now determined solely by `ResourceKeyResult.isCreatedNewKey()`: when true, the implementation deletes the materialized key-tool secret and removes the `EncryptedResourceKeyRef` row; when false, rollback is a no-op. The previously hardcoded `result.setRefExistedBeforeCreate(true)` in `preReleaseVmResource` has also been removed as part of this redesign.
Learnt from: zstack-robot-1
Repo: MatheMatrix/zstack PR: 2360
File: network/src/main/java/org/zstack/network/l3/L3BasicNetwork.java:449-490
Timestamp: 2025-08-04T04:48:19.103Z
Learning: ZStack项目在cherry-pick操作中，即使发现了性能优化机会（如IP地址批量保存的内存优化），也严格遵循不做额外修改的政策，优先保证cherry-pick的完整性和一致性。
| public static final String ORG_ZSTACK_AI_10148 = "ORG_ZSTACK_AI_10148"; | ||
| public static final String ORG_ZSTACK_AI_10149 = "ORG_ZSTACK_AI_10149"; | ||
| public static final String ORG_ZSTACK_AI_10150 = "ORG_ZSTACK_AI_10150"; | ||
| public static final String ORG_ZSTACK_AI_10157 = "ORG_ZSTACK_AI_10157"; |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# 只读核查：确认 10157 是否有完整配套（常量定义、错误消息、实际引用）
set -euo pipefail
echo "== 常量定义与相邻编号情况 =="
rg -n "ORG_ZSTACK_AI_1015[0-9]|ORG_ZSTACK_AI_1014[4-9]" -C 2
echo
echo "== 10157 在仓库中的全部引用（含配置/文档/代码） =="
rg -n "ORG_ZSTACK_AI_10157|10157" -C 2
echo
echo "== 检查是否存在该常量仅定义未使用的迹象 =="
rg -n "ORG_ZSTACK_AI_10157" -C 2Repository: MatheMatrix/zstack
Length of output: 35701
补充 ORG_ZSTACK_AI_10157 在全部i18n文件中的错误消息映射。
定义于line 14910的 ORG_ZSTACK_AI_10157 已找到定义，但经检查发现该常量在 所有i18n/globalErrorCodeMapping JSON文件中均缺少对应的错误消息映射（包括global-error-zh_CN.json、global-error-en_US.json等）。相邻的 ORG_ZSTACK_AI_10150 已在这些文件中有完整映射，而 10157 完全缺失，同时该常量在代码中也无使用点。这会导致若干来引用该常量时运行时无法获取错误描述。需补充所有语言版本的错误消息映射，并确认编号gap（10151-10156缺失）的合理性。
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In
`@utils/src/main/java/org/zstack/utils/clouderrorcode/CloudOperationsErrorCode.java`
at line 14910, The constant ORG_ZSTACK_AI_10157 is defined in
CloudOperationsErrorCode but has no corresponding entries in the global-error
JSON i18n files; add a localized error message mapping for "ORG_ZSTACK_AI_10157"
to every global-error-*.json (e.g., global-error-zh_CN.json,
global-error-en_US.json) following the same key/value pattern used by
ORG_ZSTACK_AI_10150 (use equivalent localized text for each language), and while
editing confirm and document why codes 10151–10156 are absent (either add
mappings if they should exist or leave a comment/placeholder noting intentional
gap). Ensure the key string exactly matches ORG_ZSTACK_AI_10157 and the message
formats are consistent with other ORG_ZSTACK_AI_* entries so lookups succeed at
runtime.
add errorcode ORG_ZSTACK_AI_10150; update sql of VmModelMountVO Resolves: ZSTAC-83157 Change-Id: I62696a6d667468766a6575656763707374757277
MatheMatrix
force-pushed
the
sync/zhong.xian/feat/ZSTAC-83157@@2
branch
from
93fe20f to
4394ba0
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Add virtiofs-based model mounting capability for user VMs:
Resolves: ZSTAC-83157
Change-Id: I746679736f7a7176646e646d797969766f697a76
sync from gitlab !9627