[libvirt] [PATCH] qemu: Fix connectGetType() API

This patch fixes qemuConnectGetType() API function to return KVM if appropriate, i.e. when /dev/kvm exists as the KVM module is loaded. No further check is being done so it's merely showing the possibility that KVM virtualization is available on the host however we don't have any guest information (as it's connection-only related) so we cannot sure we can use KVM. This can be useful to identify we have KVM (Virt Support) available on the host if host and guest archs are the same. Testing: Done using a simple application with C source code below. [before patch applied]$ ./test Hypervisor type: QEMU [after patch applied]$ ./test Hypervisor type: KVM $ Testing C code: int main() { virConnectPtr conn = NULL; conn = virConnectOpen("qemu:///system"); if (!conn) return 1; printf("Hypervisor type: %s\n", virConnectGetType(conn)); virConnectClose(conn); return 0; } Compiled on F-17 x86_64 host using: gcc -o test test.c -lvirt Signed-off-by: Michal Novotny <minovotn@redhat.com> --- src/qemu/qemu_driver.c | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c index 9b5d126..b770967 100644 --- a/src/qemu/qemu_driver.c +++ b/src/qemu/qemu_driver.c @@ -1132,6 +1132,16 @@ static const char *qemuConnectGetType(virConnectPtr conn ATTRIBUTE_UNUSED) { if (virConnectGetTypeEnsureACL(conn) < 0) return NULL; + /* + * If KVM is available for the host architecture then report KVM support. + * This approach merely shows it is possible to have KVM support as module is + * loaded however if you select different architecture, e.g. ARM on x86_64 host, + * the KVM option will not be available as there is no KVM virtualization + * support for ARM architecture that could be running on top of x86_64 host. + */ + if (access("/dev/kvm", F_OK) == 0) + return "KVM"; + return "QEMU"; } -- 1.7.11.7

On Tue, Sep 10, 2013 at 03:06:29PM +0200, Michal Novotny wrote:
This patch fixes qemuConnectGetType() API function to return KVM if appropriate, i.e. when /dev/kvm exists as the KVM module is loaded. No further check is being done so it's merely showing the possibility that KVM virtualization is available on the host however we don't have any guest information (as it's connection-only related) so we cannot sure we can use KVM. This can be useful to identify we have KVM (Virt Support) available on the host if host and guest archs are the same.
NACK, you are confusing two different things. virConnectGetType is intended to return the libvirt driver name. This is *always* 'QEMU'. If you want to know whether kvm virt is possible or not, then query the capabilities XML. Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|

On 09/10/2013 03:19 PM, Daniel P. Berrange wrote:
On Tue, Sep 10, 2013 at 03:06:29PM +0200, Michal Novotny wrote:
This patch fixes qemuConnectGetType() API function to return KVM if appropriate, i.e. when /dev/kvm exists as the KVM module is loaded. No further check is being done so it's merely showing the possibility that KVM virtualization is available on the host however we don't have any guest information (as it's connection-only related) so we cannot sure we can use KVM. This can be useful to identify we have KVM (Virt Support) available on the host if host and guest archs are the same. NACK, you are confusing two different things. virConnectGetType is intended to return the libvirt driver name. This is *always* 'QEMU'.
If you want to know whether kvm virt is possible or not, then query the capabilities XML.
Daniel
Ok, if this is merely returning the driver name wouldn't it be better to rename it to virConnectGetDriverName() ? According to documentation at [1] it's the name of the hypervisor so the hypervisor may be both QEMU or KVM so why to put QEMU if it's the driver name? At least fixing the documentation with information the function is returning the driver name used (and you cannot rely on it to know whether you're on KVM or QEMU) would be nice... Michal [1] http://libvirt.org/html/libvirt-libvirt.html#virConnectGetType -- Michal Novotny <minovotn@redhat.com>, RHCE, Red Hat Virtualization | libvirt-php bindings | php-virt-control.org

On 09/10/2013 07:37 AM, Michal Novotny wrote:
If you want to know whether kvm virt is possible or not, then query the capabilities XML.
Daniel
Ok, if this is merely returning the driver name wouldn't it be better to rename it to virConnectGetDriverName() ?
Unfortunately, we don't like renaming APIs if avoidable. It introduces a compat problem where new apps have to decide whether they can use the new name or the old name based on what they are targetting (the old name has to remain in the .so to avoid breaking old apps), whereas having only one name available makes it easier (use just the one name).
According to documentation at [1] it's the name of the hypervisor so the hypervisor may be both QEMU or KVM so why to put QEMU if it's the driver name? At least fixing the documentation with information the function is returning the driver name used (and you cannot rely on it to know whether you're on KVM or QEMU) would be nice...
The qemu:// URI services both qemu and kvm guests; it's up to the capabilities XML to tell you which (or both) of those types it can serve. But a doc patch is welcome, if it would help reduce your confusion. -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
participants (3)
-
Daniel P. Berrange
-
Eric Blake
-
Michal Novotny