On Thu, Feb 20, 2025 at 11:35:01AM -0000, honglei.wang@xxxxxxxxxx wrote:
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, DanielThank 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.
The first approach can be rewritten to the second one and is only an easier to write way. I would suggest we use the second one and we can add a functionality which will rewrite the first one to the second one upon definition. To make it easier to unplug we could, theoretically, see if the disk is the only namespace of the controller and unplug that, but that's just a nice-to-have, I guess.
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.
Attachment:
signature.asc
Description: PGP signature
