importVm (shared/local storage adoption): ROOT volume always gets deviceId 1, not 0
还没有人认领这个 Issue。
评估
- 难度
- 1/5
- 预计耗时
- 1-3 小时
- 新手友好度
- 86/100
- Issue 类型
- 缺陷
- 描述清晰度
- 描述清楚
- 活跃度
- 活跃
- 技术栈
- java
调研方向
从 server/src/main/java/org/apache/cloudstack/vm/UnmanagedVMsManagerImpl.java 开始,检查共享/本地 KVM 导入方法,尤其是传递给 importKVMSharedDisk 和 importKVMLocalDisk 的 deviceId。比较 external/VMware 和 staged 导入路径,然后验证导入的 ROOT 卷报告 deviceid 0,同时现有的导入行为保持不变。
由索引模型根据 Issue 内容生成。
描述
Description
When adopting an existing disk with importVm importsource=shared or importsource=local, the ROOT
volume ends up with deviceid=1 instead of 0. This happens no matter which storage backend is used —
I saw it with RBD, Linstor, and plain qcow2 on NFS, all the same way.
It doesn't stop the VM from working. It boots fine, the disk is correct, everything else is normal. But
deviceid=1 for a ROOT volume is unexpected, and any code (or person reading listVolumes output) that
assumes ROOT = device 0 will get confused here.
Where it comes from
server/src/main/java/org/apache/cloudstack/vm/UnmanagedVMsManagerImpl.java, in the method that handles
the shared/local KVM import:
long deviceId = 1L;
if (ImportSource.SHARED == importSource) {
diskProfileStoragePoolList.add(importKVMSharedDisk(userVm, diskOffering, Volume.Type.ROOT,
template, deviceId, poolId, diskPath, diskProfile));
} else if (ImportSource.LOCAL == importSource) {
diskProfileStoragePoolList.add(importKVMLocalDisk(userVm, diskOffering, Volume.Type.ROOT,
template, deviceId, hostId, diskPath, diskProfile));
}
deviceId = 1L is passed straight into the ROOT volume's own import call.
Compare this to the other two import paths in the same file (external/VMware import and staged import).
Both of those do it the right way: ROOT is imported with deviceId=null (which defaults to 0), and only
the loop that comes after, for data disks, starts counting at deviceId = 1L.
In the shared/local path there is no data-disk loop at all right now (data disks aren't imported this
way yet), so it looks like the 1L that was meant for "first disk after ROOT" ended up being used for
ROOT itself by mistake.
History
This is not new. git log -S "importKVMSharedDisk" traces it back to the original "KVM Ingestion -
Import Instance" PR (#7976), so it's been there since shared/local KVM import was first added.
Suggested fix
Pass null (or 0) as the deviceId for the ROOT volume in importKVMSharedDisk /
importKVMLocalDisk, the same way the external/VMware import path already does it.
Reproduce
importVm importsource=shared hypervisor=KVM storageid=<pool> diskpath=<existing file> networkid=<net> ...
Then check listVolumes for the resulting VM — ROOT shows deviceid: 1.
- 主要语言
- Java
- 星标
- 3.1k
- 派生
- 1.4k
- 平均合并
- 6 天 20 小时
- 30 天内合并 PR
- 27
贡献指南
从这里开始
- 先读完整个 Issue,再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库,在一个分支上完成修改。
- 提交 Pull Request,并在描述里引用这个 Issue 编号。
apache/cloudstack 的其他 Issue
-
bug
难度 1/5 1 小时以内 新手友好度 90/100
apache/cloudstack#14222 ·
-
bug component:kubernetes
难度 1/5 1 小时以内 新手友好度 88/100
apache/cloudstack#14180 ·
-
bug component:projects component:UI
难度 1/5 1 小时以内 新手友好度 88/100
apache/cloudstack#14070 · 5 条评论 ·
-
component:backup
难度 2/5 1-3 小时 新手友好度 76/100
apache/cloudstack#14013 ·
-
KVM agent fails to connect to Ceph RBD storage pool after upgrading Ceph client to Tentacle 20.2.4 未关闭bug component:ceph
难度 2/5 1-3 小时 新手友好度 78/100
apache/cloudstack#13989 · 3 条评论 ·
查看 apache/cloudstack 的全部 Issue
相似的 Issue
-
bug
难度 2/5 1-3 小时 新手友好度 85/100
-
bug frontend maui-pilot
难度 2/5 1-3 小时 新手友好度 72/100
-
难度 2/5 1-3 小时 新手友好度 76/100
objectionary/eo-graphs#74 ·
-
难度 2/5 1-3 小时 新手友好度 72/100
-
难度 2/5 1-3 小时 新手友好度 65/100