mirror of https://github.com/apache/cloudstack.git
The NVMe-oF KVM adapter refused every template copy request from the adaptive storage orchestrator with UnsupportedOperationException, which made it impossible to use an NVMe-TCP pool as primary storage for a VM root disk: every deploy that landed a root volume on the pool failed as soon as CloudStack tried to lay down the template. Implement it the same way FiberChannel (SCSI) does: the storage provider creates and connects a raw namespace ahead of time, then the adapter resolves the host-side /dev/disk/by-id/nvme-eui.<NGUID> path via the existing getPhysicalDisk plumbing (which will nvme ns-rescan and wait for the symlink if the kernel has not yet picked it up) and qemu-img converts the source image into the raw block device. User-space encrypted source or destination volumes are rejected: the FlashArray already encrypts at rest and layering qemu-img LUKS on top of a hostgroup-scoped namespace shared between hosts is not a sensible layering. Source encryption would also break on migration because the passphrase does not travel. With this change a CloudStack KVM VM can have its ROOT volume on an NVMe-TCP pool (tested end-to-end on 4.23-SNAPSHOT against Purity 6.7.7: template copy, first boot, live migrate with data disk, VM snapshot with quiesce, and revert all work). Signed-off-by: Eugenio Grosso <eugenio.grosso@gmail.com> |
||
|---|---|---|
| .. | ||
| acl | ||
| affinity-group-processors | ||
| alert-handlers | ||
| api | ||
| backup | ||
| ca/root-ca | ||
| database | ||
| dedicated-resources | ||
| deployment-planners | ||
| drs/cluster | ||
| event-bus | ||
| ha-planners/skip-heurestics | ||
| host-allocators/random | ||
| hypervisors | ||
| integrations | ||
| maintenance | ||
| metrics | ||
| network-elements | ||
| outofbandmanagement-drivers | ||
| storage | ||
| storage-allocators/random | ||
| user-authenticators | ||
| user-two-factor-authenticators | ||
| pom.xml | ||