For example, the Windows Server 2016 Hyper-V version is 10.0.14393.0, so its “micro” is over 14 times larger than the encoding allows.
My current workaround is to truncate it to something that works (E.G. 10.0.143), but that's clearly less than ideal. The problem here is the virConnectGetVersion public API - we cannot alter its signature. I hadn’t realized this was exposed by the public API.
One solution would be to introduce a new API (that possibly returns a string), but it will take time until apps start using it. That would be necessary to be able to convey the full Hyper-V version, but I’m not sure if that’s needed anywhere at the moment. Also, I’d
Since the API can’t change, should I update my code to only output major.minor instead of truncating micro to an incorrect/misleading value? The downside of this is that Microsoft has referred to Windows 10 as “the last version of Windows” and Hyper-V versions are the same as the OS’s kernel version. So, this would result in libvirt’s Hyper-V driver reporting version 10.0 until Microsoft reconsiders that approach. like to flesh out Hyper-V support within the current API before adding new functionality. Matt