recommendations for handling Hyper-V version number
jtomko at redhat.com
Thu Sep 24 08:02:08 UTC 2020
On a Wednesday in 2020, Matt Coleman wrote:
>Hyper-V version numbers are not compatible with the encoding used in
>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.
>Is the output of virParseVersionString stored on disk at any point?
>Would changing its output type from unsigned long to unsigned long long
>cause any compatibility issues? That would allow “minor” and “micro” to
>be up to 6 digits each and would be a quick, easy change.
virParseVersionString is just an internal helper, those can be changed
at will if you don't break existing users.
The problem here is the virConnectGetVersion public API - we cannot
alter its signature.
One solution would be to introduce a new API (that possibly returns a
string), but it will take time until apps start using it.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 488 bytes
Desc: not available
More information about the libvir-list