> 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.
