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@xxxxxxxxxx>, RHCE, Red Hat Virtualization | libvirt-php bindings | php-virt-control.org -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list