On Tue, Feb 18, 2025 at 07:45:45PM +0800,
honglei.wang(a)smartx.com
wrote:
What is the reason for wanting to have both these config
approaches ? With the first appearing to be a subset of
the second, the first seems to lack a compelling reason
to exist.
Consider if someone deployed a VM with the first config
style and then later wanted to add a 2nd namespace to the
VM. They would have to rewrite their config to the second
form anyway.
It seems like we'd be better off only supportnig the
second approach as it is more general.
With regards,
Daniel
Thank you for your thoughtful feedback.
The key difference between these two approaches lies in how libvirt perceives the disk
device. In the first approach, the disk is an NVMe device itself, while in the second
approach, the disk represents an NVMe namespace (nvme-ns) device.
A notable consequence of this distinction is that NVMe namespaces cannot be hot-plugged
now. This means that in the first approach, libvirt can hot-plug and hot-unplug the
'disk', whereas in the second approach, libvirt can only hot-plug the NVMe
controller, not the disk. The first approach offers greater flexibility in usage, similar
to a virtio disk, whereas the second approach allows more flexible namespace
configurations but restricts hot-plugging to the controller level.
If this distinction is deemed insignificant, I am happy to remove the first approach from
the patch.
Thank you again for your valuable suggestions. I look forward to your thoughts on this.