apache / apache/cloudstack

importVm (shared/local storage adoption): ROOT volume always gets deviceId 1, not 0

未关闭 适合新手
#13,771 4 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看
component:kvm component:managed-storage Severity:Minor type:bug
主要语言
Java
星标
3.1k
派生
1.4k
平均合并
6 天 19 小时
30 天内合并 PR
32

描述

## 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:

```java
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= diskpath= networkid= ...
```

Then check `listVolumes` for the resulting VM — ROOT shows `deviceid: 1`.

贡献指南

打开贡献指南

调研方向

从 server/src/main/java/org/apache/cloudstack/vm/UnmanagedVMsManagerImpl.java 开始,检查共享/本地 KVM 导入方法,尤其是传递给 importKVMSharedDisk 和 importKVMLocalDisk 的 deviceId。比较 external/VMware 和 staged 导入路径,然后验证导入的 ROOT 卷报告 deviceid 0,同时现有的导入行为保持不变。

由索引模型根据 Issue 内容生成。

评估

技术栈
java
领域
infrastructure
Issue 类型
缺陷
难度
1/5
预计耗时
1-3 小时
活跃度
活跃
描述清晰度
描述清楚
新手友好度
86/100

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。