[libvirt] How can I tell if I'm using qemu-kvm or qemu-kvm-ev from libvirt Python binding?
I'm trying to (optionally) use iothreads, which only exist on qemu-kvm-ev. I was hoping to see it in the domcapabilities, but I don't see it there. How do I know if it's supported or not? TIA, Y.
On Thu, Oct 19, 2017 at 10:34:21AM +0300, Yaniv Kaul wrote:
I'm trying to (optionally) use iothreads, which only exist on qemu-kvm-ev. I was hoping to see it in the domcapabilities, but I don't see it there. How do I know if it's supported or not?
Well, you can get the emulator binary from /domainCapabilities/path, but that's not what you should be using for any support-related decisions. I guess there is no easy way to do that, feel free to create a BZ that we add it to domcapabilities (or just capabilities maybe) and assign it to me so that we don't lose track of it. I'll post a patch for it then, it will be trivial, the only thing we need is design decision about how to name it and where to put it. HTH, Martin
TIA, Y.
-- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
On Thu, Oct 19, 2017 at 10:22:59AM +0200, Martin Kletzander wrote:
On Thu, Oct 19, 2017 at 10:34:21AM +0300, Yaniv Kaul wrote:
I'm trying to (optionally) use iothreads, which only exist on qemu-kvm-ev. I was hoping to see it in the domcapabilities, but I don't see it there. How do I know if it's supported or not?
Well, you can get the emulator binary from /domainCapabilities/path, but that's not what you should be using for any support-related decisions.
I guess there is no easy way to do that, feel free to create a BZ that we add it to domcapabilities (or just capabilities maybe) and assign it to me so that we don't lose track of it. I'll post a patch for it then, it will be trivial, the only thing we need is design decision about how to name it and where to put it.
I don't think that this is something we would like to have in upstream code. The differentiation between qemu-kvm and qemu-kvm-ev is dowsntream thing. In addition, there is no qemu-kvm in upstream, there is only QEMU. What we can add into capabilities is information whether the QEMU binary supports iothreads or not, but please, don't introduce anything that's downstream only. Pavel
On Thu, Oct 19, 2017 at 11:43:44AM +0200, Pavel Hrdina wrote:
On Thu, Oct 19, 2017 at 10:22:59AM +0200, Martin Kletzander wrote:
On Thu, Oct 19, 2017 at 10:34:21AM +0300, Yaniv Kaul wrote:
I'm trying to (optionally) use iothreads, which only exist on qemu-kvm-ev. I was hoping to see it in the domcapabilities, but I don't see it there. How do I know if it's supported or not?
Well, you can get the emulator binary from /domainCapabilities/path, but that's not what you should be using for any support-related decisions.
I guess there is no easy way to do that, feel free to create a BZ that we add it to domcapabilities (or just capabilities maybe) and assign it to me so that we don't lose track of it. I'll post a patch for it then, it will be trivial, the only thing we need is design decision about how to name it and where to put it.
I don't think that this is something we would like to have in upstream code. The differentiation between qemu-kvm and qemu-kvm-ev is dowsntream thing. In addition, there is no qemu-kvm in upstream, there is only QEMU.
What we can add into capabilities is information whether the QEMU binary supports iothreads or not, but please, don't introduce anything that's downstream only.
That's what I meant by "feel free to create a BZ that we add it to domcapabilities (or just capabilities maybe)", it was meant for the iothread support. I already have the patch for it, just need to add it to tests.
participants (3)
-
Martin Kletzander -
Pavel Hrdina -
Yaniv Kaul