Re: recommendations for handling Hyper-V version number
> 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.
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.
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
like to flesh out Hyper-V support within the current API before adding
new functionality.
Matt