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

Comience en server/src/main/java/org/apache/cloudstack/vm/UnmanagedVMsManagerImpl.java e inspeccione el método de importación KVM compartido/local, especialmente el deviceId que se pasa a importKVMSharedDisk e importKVMLocalDisk. Compare las rutas de importación externa/VMware y staged, y después verifique que un volumen ROOT importado informe deviceid 0 mientras el comportamiento de importación existente permanezca sin cambios.

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.