Avoid virGetVersion failure on specific driver support configurations
virGetVersion itself doesn't take a virConnectPtr, but in order to obtain the hypervisor version against which libvirt was compiled it is used in combination with virConnectGetType like this: hvType = virConnectGetType(conn) virGetVersion(&libVer, hvType, &typeVer) When virConnectGetType is called on a remote connection then the remote driver returns the type of the underlying driver on the server side, for example QEMU. Then virGetVersion compares hvType to a set of strings that depend on configure options and returns LIBVIR_VERSION_NUMBER in most cases. Now this fails in case libvirt on the client side is just compiled with the remote driver enabled only and the server side has the actual driver such as the QEMU driver. It just happens to work when the actual driver is enabled on client and server side. But that's not always true. I noticed this on FreeBSD: freebsd# virsh -c qemu+tcp://192.168.178.22/system version Compiled against library: libvir 0.9.2 error: failed to get the library version error: this function is not supported by the connection driver: virGetVersion This is not FreeBSD specific, happens on Windows as well due to the similar driver support configuration. The problem is that virConnectGetType returns QEMU, but virGetVersion on the client side only accepts Remote as hvType due to all other drivers being disabled on the client side. Daniel P. Berrange suggested to get rid of all the conditional code in virGetVersion, ignoring the hvType and always setting typeVer to LIBVIR_VERSION_NUMBER. virConnectGetVersion is supposed to be used to obtain the hypervisor version.
Showing
想要评论请 注册 或 登录